guter Beitrag, das sind die Infos die wir brauchen und uns beim Design von UI und Leistungsmerkmalen weiterhelfen.
Ja!! Dieses Thema macht uns am meisten Kopfzerbrechen.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.
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
- 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)
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.
Ja, so etwas habe ich befürchtet. Wir kennen das von den Plugins her schon.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.
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.
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,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
mfg
Stefan Werner