UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Implemented] Stromzähler mit Modbus-Schnittstelle

Hier bitte Eure Diskussionen und Feature Requests zu neuen Logikmodulen und Funktionen des Logik-Editors

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#21

Beitrag von StefanW »

Hallo Andi,

guter Beitrag, das sind die Infos die wir brauchen und uns beim Design von UI und Leistungsmerkmalen weiterhelfen.
tger977 hat geschrieben: Fr Jun 14, 2019 9:59 pm- Schön wäre wenn man die Sunspec Registernummer als fertigen "Baustein" der Community zur Verfügung stellen könnte und nicht jeder sich mit den Registernummern "40069" und der entsprechenden Herstellerspec herumschlagen muss sondern z.B. in einem fertigen Sunspec Logikbaustein direkt den Klarnamen (z.B. "Momentanleistung") angezeigt bekommt.
Ja!! Dieses Thema macht uns am meisten Kopfzerbrechen.

Wie bekommen wir das einfach realisierbar hin, dass es "Modbus-Gerätebeschreibungen" gibt, in denen es für alle im Umlauf befindlichen ModBus-Geräte eine Art Repository gibt (zu dem dann die Community beitragen kann) dass diese Definitionen der Register enthält. Also die "Applikation" eines jeden Gerätes. So wie man bei der ETS die Applikation der Hersteller lädt, wäre es toll, wenn man im Timberwolf Server einfach solche "Applikation" der Modbus Geräte laden könnte und dann entstehen damit Objekte die sich dann beliebig verknüpfen lassen.

Die Betonung liegt auf "einfach realisierbar". Weil wie man das Komplex machen kann, das sieht man am 1-Wire Geräte Editor. Dort gibt es auch ein Repository aller Sensortypen mit den jeweiligen Fähigkeiten und man klickt dann nur noch an was man davon wie in welchem Intervall braucht. Nur hat die Realisierung von Front- und Backend für das 1-Wire Thema alleine drei Jahre gekostet. Mit ModBus wollen wir da schneller an das Ziel kommen.

Im ersten Schritt könnten wir das so realisieren
  • eine Liste aller Aufgaben (also was von allen ModBus Geräten in welchem Intervall zu pollen und auf welche Objekte das zu leiten ist).
  • Zur einfachen Wiederverwendbarkeit kann man dort Modbus-Gerätedefinitionen laden.
  • Diese ModBus Gerätedefinitionen sind eine einfache Json-Struktur die man Importieren kann.
  • Auf diese Weise wird die Liste der Aufgaben um die Fähigkeiten der jeweiligen Geräte erweitert. Unbenutztes kann man ausblenden.
  • Eine solche Liste sähe ähnlich wie die Objektverwaltung aus inkl. aller Filter und Suchen (nebst Sortierung)
  • Hier kann man auch den jeweils letzten Wert inkl. Uhrzeit sehen. Selbstverständlich kann man von allem auch Zeitserie schreiben
In späteren Schritten kann man dann:
  • Ein Repository anbinden, zu dem man eigene Definition hochladen und runterladen kann. Hier ist das Hauptproblem, wie man Ordnung und Qualität schafft. Womöglich braucht es dann noch ein Bewertungssystem damit man gute von schlechten Definitionen aus der Community unterscheiden kann.
  • Einen schöneren Editor machen wie beispielsweise beim 1-Wire Geräte-Editor
  • Auch eine Realisierung als zusätzlichen ModBus Slave wäre denkbar (in einem Universum ein Master, in einem anderen ein Slave)
==> Was denkt Ihr darüber?

tger977 hat geschrieben: Fr Jun 14, 2019 9:59 pmIn EDOMI sieht der fertige Baustein für Sunspec so aus und dieser passt dann universell für sehr viele Wechselrichter da die Adressen im sunspec Protokoll für alle gleich definiert sind und ist dann echt plug&play für user:
Merci für das Bild. Schön gemacht.

Meine Gedanken dazu:
  • In Grafisch sieht sowas zwar schick aus, ist aber für größere Anwendungen dann schon eher unhandlich.
  • Wir haben auch industrielle Kunden. Wenn da nun jemand 50 im Werk verteilte ModBus-Sensoren abfragen will, weil er die auf eine Zeitserie schreiben will, dann sind solche Bausteine mit all den Linien und der sonstigen Malerei schnell unübersichtlich. Da halte ich unsere filterbaren Listen für wesentlich effektiver.
  • Es wird auch ModBus Geräte geben, die haben 30, 50 oder mehr Register. Im Bausteinformat wird das dann immer dargestellt, auch wenn nur ein einziger Parameter davon gebraucht wird. Mit unseren filterbaren Listen würde man nur die benutzten Register anzeigen, das ist sehr viel kompakter und passt auch auf einen Smartphone Bildschirm.
tger977 hat geschrieben: Fr Jun 14, 2019 9:59 pmProbleme jedoch damit:
- ich muss pro Modbus Gerät / Adresse einen dieser LBS laufen lassen und das sorgt wohl für Performanceverschlechterung. Ich habe es bisher nicht geschafft die 2 Wechselrichter in einem Ausleseintervall < 10s auszulesen ohne dass es immer wieder Fehler hagelt.
Ja, so etwas habe ich befürchtet. Wir kennen das von den Plugins her schon.

Hier eine kurze Erläuterung, warum wir das anders machen:

Wenn man in eine Logik "asynchrone Bausteine" einfügt, also alles was nach extern kommuniziert, dann besteht die Gefahr von Hängern und vor allem von Performance-Verschlechterungen der zentralen Engine. Das ist ein prinzip-bedingtes Problem aller Engines, die es erlauben, dass darin weiterer Code ausgeführt wird. Wenn dieser schlecht geschrieben ist oder die Kommunikation mit dem externen Gerät einfach dauert, dann wird der Rest ausgebremst. Das tritt auch insbesondere dort auf, wo es nur einen Prozessorkern gibt, weil die vielen Kontextwechsel (insbesondere wenn auf interpretierbare Sprachen umgeschaltet wird) dann auch noch die Rechenleistung ruinieren.

Wie unsere Kunden wissen, achten wir bei allen Echtzeitaufgaben am Timberwolf-Server auf maximale Performance und auf Echtzeitverhalten, darum haben wir auch bis zu acht Prozessoren in einem Gerät. Und darum sind solche - zwar flexiblen aber die Leistung zerstörenden - Konzepte von frei hinzufügbaren, in einer Scriptsprache geschriebenen Bausteinen die im Kontext der Logikengine laufen auch absolut tabu.

Das Konzept beim Timberwolf Server entspricht dem von Linux: Einzelne kleine schlagkräftige Programme, jedes für sich mit einer konkreten Aufgabe die über einen schnellen Software-Bus miteinander kommunizieren. Das war zwar sehr viel aufwändiger als ein Monolith, aber deutlich skalierbarer und weniger anfällig gegenüber bremsenden Elementen.

Gerade mit Bussystemen die gepollt werden müssen wie bei 1-Wire und ModBus kann es schnell Verzögerungen geben, etwa weil die Abfrageschlange voll ist, ein Gerät nicht antwortet usw. Darum läuft das auf dem Timberwolf Server in jeweils separaten Prozessen die dann die Ergebnisse als "spontanes Ereignis" (wie KNX und andere) dem Verteiler zur Verfügung stellen.

Und damit auch nicht alles und jedes über die Logik muss haben wir den Verteiler als zentrales Modul. Denn damit muss über die Logik nur noch dass, was berechnet werden muss und das läuft dann auch höchst effizient mit zehntausend Ereignissen pro Sekunde durch.

Der besondere Vorteil unseres Konzeptes ist auch, dass sich mehrere Logikengines parallel starten lassen würden. Entweder zur Skalierung oder weil man spezifische Logikengines hätte. Zum Beispiel die jetzige für alle Logik-Aufgaben und eine zweite die für Ablaufsteuerungen zuständig ist und denkbar ist auch eine dritte für komplexe Zeitschaltuhren.

Darum soll der Kunde seine selbstgeschriebenen Bausteine in seiner Lieblingssprache in einem Docker-Container laufen lassen. Da stört es nicht den Rest des Systems. Für die Kommunikation wird man dann MQTT (je nach Lizenz) oder ähnliches verwenden.

tger977 hat geschrieben: Fr Jun 14, 2019 9:59 pm- ich bekomme immer wieder mal zusätzliche sporadische timeouts/Errors/Verbindungsabbrüche (auffällig ist daß das v.a. passiert wenn hohe Auslastung des Systems auftritt). Prinzipiell sind diese Probleme nicht schlimm da nur alle paar Tage mal was auftritt, es wird mir nur unnötig das errorlog vollgeschrieben und ich bekomme diese Errors dann in der Visu immer angezeigt und man kann dann von richtigen wichtigen Errors nicht mehr unterscheiden ohne jedesmal das Errorlog manuell durchzusehen
Ja, verstehe, das muss man schon vermeiden. Es kann bei solchen Fehlern aber auch am externen Gerät liegen. Es ist immer auch eine kleine Herausforderung, wenn man zwei Geräte von zwei Herstellern miteinander verbindet, insbesondere wenn es dort keine Zertifizierungen gibt,

mfg

Stefan Werner
Zuletzt geändert von StefanW am Sa Jun 15, 2019 12:38 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

tger977
Reactions:
Beiträge: 740
Registriert: So Aug 12, 2018 9:25 am
Hat sich bedankt: 205 Mal
Danksagung erhalten: 274 Mal

#22

Beitrag von tger977 »

StefanW hat geschrieben: Sa Jun 15, 2019 12:38 pm Im ersten Schritt könnten wir das so realisieren

==> Was denkt Ihr darüber?
Ich finde das einen guten Ansatz! Die Listen haben schon auch Ihre Vorteile, gerade hier sehe ich das genauso wie Du!
Gruß
Andi

TW2500 #440 (ex Timberwolf 2400 #111) mit PBM #124, Support VPN nur auf Anfrage, Reboot bitte nur nach Absprache

bikefish
Reactions:
Beiträge: 18
Registriert: Sa Aug 11, 2018 11:22 pm
Hat sich bedankt: 107 Mal
Danksagung erhalten: 6 Mal

#23

Beitrag von bikefish »

Finde das auch einen guten Ansatz. Die Listen werden einmalig pro Modbus Gerät definiert und dann nicht mehr geändert, dafür ist es ausreichend.

Gruß Klaus
TWS 950Q #309, VPN aktiv, reboot nach Rücksprache, wiregate1141,

Ersteller
gospelrock
Reactions:
Beiträge: 193
Registriert: Mo Sep 24, 2018 3:40 pm
Wohnort: Wildau
Hat sich bedankt: 34 Mal
Danksagung erhalten: 64 Mal

#24

Beitrag von gospelrock »

Das klingt für mich schlüssig. :handgestures-thumbsup:

Wird es dann auch irgendwie noch die Möglichkeit geben die passende Schnittstelle (RS485 oder Ethernet) auszuwählen?
Die Stromzähler verwenden die Zweileiter-Variante und die Wechselrichter meines Wissens ausschließlich die Ethernet-Variante (bei SMA: "Speedwire"; TCP Port 502).

Grüße,
Peter
Wiregate1784, Timberwolf 950Q #265, PBM 3x40 Slaves
Wartungs VPN offen; Restart jederzeit möglich

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#25

Beitrag von StefanW »

Hallo Peter,
gospelrock hat geschrieben: Mo Jun 17, 2019 8:18 amWird es dann auch irgendwie noch die Möglichkeit geben die passende Schnittstelle (RS485 oder Ethernet) auszuwählen?
ja, klar. Es ist geplant, das man die Modbus Universen zuvor definiert. Beipiel:
  • Modbus Subsystem 1 ist via RS485 vom Typ Master
  • Modbus Subsysttem 2 ist via Ethernet vom Typ Master
Anschließend legt man dann die GEräte an und in den Geräten die Register

lg

Stefan
Zuletzt geändert von StefanW am Mo Jun 17, 2019 9:13 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Benutzeravatar

gurumeditation
Reactions:
Beiträge: 408
Registriert: Mo Aug 13, 2018 10:51 am
Wohnort: Hannover
Hat sich bedankt: 187 Mal
Danksagung erhalten: 272 Mal

#26

Beitrag von gurumeditation »

StefanW hat geschrieben: Sa Jun 15, 2019 12:38 pm Wie bekommen wir das einfach realisierbar hin, dass es "Modbus-Gerätebeschreibungen" gibt, in denen es für alle im Umlauf befindlichen ModBus-Geräte eine Art Repository gibt (zu dem dann die Community beitragen kann) dass diese Definitionen der Register enthält. Also die "Applikation" eines jeden Gerätes. So wie man bei der ETS die Applikation der Hersteller lädt, wäre es toll, wenn man im Timberwolf Server einfach solche "Applikation" der Modbus Geräte laden könnte und dann entstehen damit Objekte die sich dann beliebig verknüpfen lassen.
[..]
In späteren Schritten kann man dann:
  • Ein Repository anbinden, zu dem man eigene Definition hochladen und runterladen kann. Hier ist das Hauptproblem, wie man Ordnung und Qualität schafft. Womöglich braucht es dann noch ein Bewertungssystem damit man gute von schlechten Definitionen aus der Community unterscheiden kann.
  • Einen schöneren Editor machen wie beispielsweise beim 1-Wire Geräte-Editor
  • Auch eine Realisierung als zusätzlichen ModBus Slave wäre denkbar (in einem Universum ein Master, in einem anderen ein Slave)
==> Was denkt Ihr darüber?
Hallo Stefan,

vielleicht wäre ein Weg ähnlich der Gerätedatenbank der Logitech Harmony sinnvoll...

Auch wenn ich zunächst vom Online-Zwang der Konfigurationssoftware (nur zum Konfigurieren, nicht zum Betrieb!) überhaupt nicht angetan war, wäre ohne diesen niemals die Datenbank aus zigtausend IR-gesteuerten Geräten entstanden. Wie der Hersteller dort hinter den Kulissen moderiert und konsolidiert, kann ich nicht beurteilen, da ich es nicht sehe und es keine Doku dazu gibt. Das Ergebnis sehe ich sehr wohl: Zu fast jedem Gerät gibt es bereits einen Eintrag mit den IR-Befehlen - selbst ein importierter Video-Switch für Komponentensignale aus Hongkong war bereits vorhanden. Beliebte bzw. verbreitete Geräte findet man auch nicht 100 Mal in der Datenbank, sondern nur 1 Mal. Es muss also eine Konsolidierung geben.

Wenn ich das Vorhaben richtig verstanden habe, gibt es auch bei Modbus keine bessere oder schlechtere "Applikation", sondern höchstens eine vollständigere. Teile können natürlich auch korrekt oder inkorrekt sein, wie bei IR-Codes auch.

Ich denke, das Thema bietet neben den technischen Aspekten auch emotional und politisch reichlich Zündstoff für Diskussionen. Gerade die unbedingte Übertragung von Schnittstellendaten angeschlossener Geräte wird nicht jedermanns Zustimmung finden.
--
TWS 2500 (ID=137), PBM, Wartungs-VPN=ON, Reboot bitte nur nach Absprache

miesi
Reactions:
Beiträge: 5
Registriert: Mi Jun 12, 2019 11:21 am
Danksagung erhalten: 8 Mal

#27

Beitrag von miesi »

Wenn du "viele" Wechselrichter monitoren willst/mußt, mußt du eventuell zu einer spezialisierten Lösung wie http://www.limes-sys.de/index.php?optio ... icle&id=61 greifen. Da sind 400+ Wechselrichter kein Problem.

Aber Konkurrenz belebt ja das Geschäft...
(noch) kein TWS

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#28

Beitrag von StefanW »

Hallo Miesi, danke für den Link

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Bancoras
Reactions:
Beiträge: 33
Registriert: So Sep 29, 2019 12:53 pm
Hat sich bedankt: 11 Mal
Danksagung erhalten: 6 Mal

#29

Beitrag von Bancoras »

Ich hole den Thread mal wieder hervor, ist ja schon wieder ein Jahr vergangen...

Ich bin gerade dabei eine PV-Anlage für unser Heim zu erstellen/organisieren und hänge etwas beim Thema Wechselrichter und Stromspeicher.
Ich habe KNX und 1-Wire im Haus, wollte eigentlich die Anlage direkt am KNX integriert haben, mir sind allerdings die Lösungen von E3DC oder die 'Sonnen'batterie zu teuer.

Daher spiele ich mit dem Gedanken nen SolarEdge WR, genauer gesagt den StorEdge SE5K mit LG Batterie zu nehmen.
Der StorEdge hat ja ne RS485 Schnittstelle zum Anschließen externer Geräte.
Der RS485-Anschluss kann auch als Schnittstelle für externe Geräte
verwendet werden, die nicht von SolarEdge stammen, zum Beispiel für Messgeräte und Datenlogger von Drittanbietern.

https://www.solaredge.com/sites/default ... ide-de.pdf <-- Kapitel 7, bzw. Seite 62

Es gibt auch einen technischen Hinweis zum Sunspec-Protokoll
https://www.solaredge.com/sites/default ... ote-de.pdf


Nun zu meiner Frage, wie weit die Implementierung des Modbus im Timberwolfserver ist?
Und des Weiteren: Ich besitze ja 'nur' den 350Q, müsste als via Upgrade den RS-485 Anschluss aktivieren... Ist da auch schon was in Arbeit?


Sonnige Grüße
Marcel
Timberwolf 350Q
timberwolf409, VPN offen, Reboot jederzeit

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#30

Beitrag von Sun1453 »

@Bancoras

Hallo Marcel,

also die Modbus Funktionalität wird in Etappen mit der IP 1 bis IPX der Version 2.0 eingeführt. Diese wird bald veröffnetlicht wenn die V1.6 als Final ausgerollt ist. Nach letzten Stand soll nur noch eine RC4 kommen und dann die Final 1.6. Also kannst du dich auf erste Funktionen September / Oktober einstellen, wenn du in den Insider Channel mit deinem Server Wechselst.

Bitte diese Informationen im extra Modbus Bereich posten, damit wir eine eindeutige Zuordnung haben. An alte Themen anhängen bringt nur Unordnung und fehlende Zusammenhänge. Also bitte ein neues Thema hier anlegen.

Im Titel bitte "SolarEdge WR - StorEdge SE5K" erwähnen. Danke dir.
Zuletzt geändert von Sun1453 am Do Aug 13, 2020 2:19 pm, insgesamt 1-mal geändert.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Logik (Module & Editor)“