LBS: 19001030: Modbus TCP Master Read

[jonofe]

Ist eine virtuelle Maschine mit zwei vCPUs eines Xeon E3-1245 v6. Vielleicht geht der Unterschied in den Nachkommastellen unter.

[WagoKlemme]

Danke, schon geklärt - Champions-League.
Meine N3150-CPU ist im Vergleich eine Schülermannschaft.

[hartwigm]

jonofe - Ressourcen

Ich würde gerne zu deinem Baustein noch nachfragen.

Bei meinem Bausteinen habe ich immer einen externen Trigger und in der Regel komme ich mit dem 1/5/10/3/60min Trigger klar.

Dieser Trigger kommt ja eh von System, so dass ich bisher der Meinung war, meine Ressourcen bestens zu nutzen wenn nicht zig. Bausteine permanent am Laufen sind.

Liege ich hier falsch?

[jonofe]

Vollkommen korrekt, wenn die externen Trigger passen, ist es das Beste von der Ressourcennutzung.

Wenn natürlich extrem viele LBS vom gleichen Systemtrigger gestriggert werden, muss man nur berücksichtigen, dass die dann alle quasi gleichzeitig starten und somit zu diesen Zeitpunkten die Last des Systems etwas höher geht. Aber das ist ja nichts schlimmes, wenn es nicht zulange anhält.

[saegefisch]

Hi André,

was ist aus Deiner Sicht letztlich der eleganteste Weg für einen Prozess, der dauerhaft laufen, aber zur Last-Reduzierung nur periodisch tatsächlich etwas tut:

• logic_setState($id, 1, $E[2]['value'] * 1000, true);

• im EXEC-Teil mit usleep($E[2]['value'] * 1000);
• per externem Trigger (mit dem oben von Dir schon notierten "Nachteil")
• weitere?

Ingesamt sehe ich auch den grundsätzlichen Bedarf daran, meine Dauerprozesse fast alle mit wechselnden Frequenzen zu verwenden, und die LBS (zur Last-Reduzierung) seltener zu prozessieren, wenn die Ergebnisse derzeit nicht relevant sind. Zum Beispiel hochfrequent (500ms) Energiewert, wenn ich auf der Energie-Seite bin, sonst aber reichen mir 5.000ms. Ähnlich auch sehe ich auch für sonos (wenn keine Seite mit Sonos-Elementen/Anzeigen, dann braucht es auch keine usleep(1000000) oder stoppt ihn ganz). All' das kann man mit externen Triggern ebenso gut lösen, wie mit einem Ex-Eingang auf Schleifen-Pausen.

[saegefisch]

Also im Moment ist es ein Schrödinger LBS
Er existiert zum groß Teil in meinem Kopf und zum kleinen Teil in einem anderen LBS denn ich gerade baue...

Für das Modbus für SMA-Geräte habe ich nun einen LBS gebaut, der mir für SMA-Geräte Werte liefert. Technisch kann der LBS auf andere Quellen adaptiert werden, aber Teile sind sehr SMA-spezifisch, weil

• SMA CSV/XLS liefert für die Register mit Format-Infos, etc. Mein Ziel war es, die gwünschten Zeilen 1:1 aus der CSV oder XLS kopieren un nutzen zu können inkl. der Format-Informationen (Länge, Nachkommstellen, EIniheit, Skalierungsfaktoren,...)
• Ich mit den vorherigen Lösungen bzw. den Umrechnunegn aus dem github-Paket nie auf sinnvolle Werte kam. Daher auf das PDF von SMA aufbauend eine eigene Umrechungsmimik.

Als Eingang braucht man nur ein Feld und definiert damit den gesamten Lieferumfang (gemischt mit leerzeilen, aus CSV oder XLS problemlos), zum Beispiel:

30775    Power    S32    FIX0    W    RO
30845    Current battery state of charge    U32    FIX0    %    RO
30861    Load power    S32    FIX0    W    RO    
30849    Battery temperature    S32    TEMP    °C    RO    0.1
30783;Grid voltage phase L1;U32;FIX2;V;RO;;;
30849    Battery temperature    S32    TEMP    °C    RO    0.1
30803;Grid frequency;U32;FIX2;Hz;RO;;;

30865    Power grid reference    S32    FIX0    W    RO    
30867    Power grid feed-in    S32    FIX0    W    RO

Am Ausgang kommen die Werte in der Reihenfolge als String raus und kann da smit den String-Trennern wunderbar in KO oder Archive schreiben. Das ganze roh oder mit EInheit. So erscheint es mir einfach und sinnvoll, da hocgrdaig flexibel (ohne jSON überbau, CSV,...), sondern eben mit copy&paste aus den Originalquellen von SMA.

--> Läuft auch schon prima, weil ich von meinen WR und dem Batterie-System wunderbar Daten bekommen.
--> Läuft leider nicht gut, weil ich zwar Werte bekomme, aber auch einen ganzen Sack Fehlermeldungen vom ModBusMaster.php-include

2018-05-03 15:20:43 954221 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
2018-05-03 15:20:43 954524 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
2018-05-03 15:20:43 954642 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 8 | Zeile: 167 | Uninitialized string offset: 5 ERROR
2018-05-03 15:20:43 954782 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
2018-05-03 15:20:43 954891 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
2018-05-03 15:20:43 954993 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
2018-05-03 15:20:43 955094 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR
2018-05-03 15:20:43 955202 ? 3152 Datei: /usr/local/edomi/main/include/php/modbus_sma/ModbusMaster.php | Fehlercode: 2 | Zeile: 166 | socket_recv(): unable to read from socket [11]: Resource temporarily unavailable ERROR

Mein Log higegen liefert mir den Inhalt von MODBUS ohne Fehler:
START
Connected
Packet: 0c4600000006030378370002
Send
Wait data ...
Data received
Packet: 0c4600000007030304fffffff6
Modbus response error code: NOERROR
Disconnected
readMultipleRegisters: DONE

Dürfte wohl irgendwo in private function rec() zwischen "Wait data..." und "Data received" passieren...

Frage:Hat das schon mal jemand gehabt und gelöst? An anderen Stellen las ich im Forum zum Fehler von "vielleicht andere Clients, die zugreifen"... kann es sein, dass ich mioch selber blockiere? Ich starte den Daemon mit 1x "new ModbusMaster" und rufe dann regelmäßig und in der Schleife für jedes Register "$modbus->readMultipleRegisters"... Sollte/kann man das ModBus-Object freigeben? Wie kann man das anaylsieren? Und: Es liegt in der Natur der Saceh, dass mein SMA Homemanger die WR auch abfragt (Daten gehen in das SunnyPortal); wäre es da nicht besser, es wären Infos/Warnungen, keine Fehler? Scheint mir fast ein Implemntierungsfehler in dem Include...

Wenn das gelöst ist, kommt der LBS direkt in den Download-Bereich.

Der LBS kann über entweder einen externen Trigger regelmäßig ausgelöst werden (Delay = 0) oder als daemon (wenn Trigger =1) mit einstellbarer Periodizität (z.B. 1000ms). Es kann also jeder machen, wie er es bevorzugt. Von der Last scheint es kaum aufzutragen (NUC core i3) bei sekündlich. @André: Habe mich für usleep entschieden - das kannte ich schon und entspricht dem Dämon-Schema von Christian.

ModBus Read SMA.JPG ModBus Read SMA2.JPG

[jonofe]

was ist aus Deiner Sicht letztlich der eleganteste Weg für einen Prozess, der dauerhaft laufen, aber zur Last-Reduzierung nur periodisch tatsächlich etwas tut:

saegefisch Hi Carsten, ich präferiere eigentlich das usleep() Polling für EXEC LBS, da es dann unabhängig läuft. Jedes Triggern über einen Eingang hat mehrere DB Aufrufe zur Folge, daher versuche ich das zu vermeiden. Außerdem mache ich die Kommunikation zwischen LBS und EXEC i.d.R. via Message Queue. Hier wäre dann für jedes Triggern eine neue Message notwendig und der EXEC würde eigentlich genauso in Wartestellung verharren wie mit einem usleep().

Unterschiedliche Aktualisierungsfrequenzen kann man dann über einen entsprechenden Eingang verfügbar machen. Wichtig wäre hier natürlich für deinen Usecase, dass der LBS die Änderung im laufenden Status akzeptiert.

Zusätzlich wirkt sich natürlich ein integriertes SBC positiv auf die Prozessor/DB-Last aus, d.h. man aktualisiert die Ausgänge nicht bei jedem Pollingdurchlauf, sondern nur, wenn sich auch etwas geändert hat.

Wenn es nur um den LBS Teil geht, dann habe ich bislang nicht sonderlich darüber nachgedacht, da eigentlich die meisten meiner LBS als EXEC Daemon laufen und die anderen i.d.R. einen definierten Trigger haben, einmal ausgeführt werden und dann das Ergebnis liefern.

[saegefisch]

Hi André,
vielen Dank, gerade das Thema DB-arme Verarbeitung liegt mir auch am Herzen und da helfen mir Deine Einschätzungen. Bei meinem neuen LBS hatte ich mich heut Nachmittag schon für die uslepp-Lösung entschieden, weil ich sie bislang nutzte und auch Christians Vorlage dies vorschlägt und mir auch schön lesbar erschient - und auch, weil ich zur Laufzeit die Delay-Zeit variieren kann. Dafür muss man natürlich im EXEC-Teil auch was tun, aber das ist schlank. Daher: Prima, schön, dass unsere Präferenzen gleich sind und das untermauert ist als DB-ärmste Lösung.

Das DB-Thema mag ich noch etwas klären:
* Danke für Deine SBC-Erinnerung, daran hatte ich im neuen lBS nicht gedacht <schäm>, ist jetzt drin...
* Wird ein Ausgang auf DB verarbeitet, wenn kein Folge-LBS den Wert nutzt? Falls ja, sollte man ggf. ungenutzte Ausgänge per Eingang abschalten können.
* Wie sieht es aus, wenn danach nur eine Klemme klemmt; DB oder ohne?
* MessagQueue: Bislang habe ich eher über die V-Variablen die Daten ausgetauscht. Die Message Queue nutzt ich bislang nur 1x, da mit externem PHP7-Script nicht anders möglich. Ich fand die Benutzung nicht immer klar und hatte den EIndruck, dass die Queue auch mal etwas zäh ist/braucht. So kam ein "stop" nicht mehr an, weil ich die Queue zu schnell danach gelöscht habe; erst mit 3-5s ist es verlässlich per MQ angekommen (damit das externe Script sich auch beendet). Aber 3-5s find ich lang... Der Weg mit HTTP-Push in Ziel-KO war schneller als MQ. Oder ich habe was falsch gemacht...
* Aber: die MQ wird wohl gänzlich ohne DB auskommen; wie sieht es mit den V-Variablen aus? Sind die auch nur RAM oder DB? Letzteres wäre ein klares Pro für die MQ.

[saegefisch]

Zu meinen ModBusMaster.php-include-Fehlern im Fehler-Log (Siehe oben): Kann man die irgendwie sinnvoll abfangen und vor edomi verbergen oder zur Warnung reduzieren? Oder hat das gar jemand schon gemacht oder eine schlanke Fassung aus der Lösung geschnitzt oder das ganze non-FC3-Gedöns drumherum? Weil es kommen ja Werte, ERROR scheint mir da völlig unagmessen...

[jonofe]

Wird ein Ausgang auf DB verarbeitet, wenn kein Folge-LBS den Wert nutzt? Falls ja, sollte man ggf. ungenutzte Ausgänge per Eingang abschalten können.

Sobals du ein logic_setOutput() ausführst wird der Ausgang gesetzt und entsprechende DB Calls werden ausgeführt.

Wie sieht es aus, wenn danach nur eine Klemme klemmt; DB oder ohne?

Egal was dranhängt, das weiss dein LBS ja nicht.

MessagQueue: Bislang habe ich eher über die V-Variablen die Daten ausgetauscht. Die Message Queue nutzt ich bislang nur 1x, da mit externem PHP7-Script nicht anders möglich. Ich fand die Benutzung nicht immer klar und hatte den EIndruck, dass die Queue auch mal etwas zäh ist/braucht.

Message Queue funktioniert eigentlich instant, da es eine direkt Interprozess Kommunikation via RAM ist. Von daher ist bei einer 3-5 Sekunden Reaktionszeit irgendetwas schief gelaufen (vermutlich in der Programmierung )
Die Kommunikation über Variablen hat den Nachteil, dass du nicht wirklich sicherstellen kannst, dass du jeden Trigger vom LBS mitbekommst. Ändert sich z.B. zweimal ein Eingang, der einen Trigger an den EXEC Daemon sendet, während diese in EINEM Pollingzykus ist, dann bekommst du die erste Änderung nicht mit, da diese ja bereits beim Start des nächsten Pollingzyklus' durch die zweite Änderung überschirben wurde.
Wichtig bei Message Queues ist, dass diese erst beim Beenden von EDOMI removed werden und zwar idealerweise im EXEC Daemon. Du darfst sie also nicht nach einem Aufruf im LBS Teil Löschen.

Das Löschen macht man am Besten, nach Verlassen der WHILE Schelife im EXEC Daemon.

Aber: die MQ wird wohl gänzlich ohne DB auskommen;

Ganz genau.

wie sieht es mit den V-Variablen aus? Sind die auch nur RAM oder DB? Letzteres wäre ein klares Pro für die MQ.

Sowohl als auch, da die DB von EDOMI im RAM gehalten wird. Allerdings ist meine Erfahrung, dass DB Zugriffe, auch wenn diese im RAM sind, deutlich aufwendiger als ein Zugriff auf eine Message-Queue.

Kann man die irgendwie sinnvoll abfangen und vor edomi verbergen oder zur Warnung reduzieren?

Ja, das geht. In einigen meiner LBS mache ich das auch. Dort gibt es dann die Funktionen error_on(), error_off(). Es findet damit eine Umleitung der Fehlermeldungen ins CustomLog statt, so dass man die Meldungen nicht verliert, aber der böse rote Zähler nicht hochgezählt wird.

Hier der Code:

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
    global $id;
    logging($id, "File: $errfile | Error: $errno | Line: $errline | $errstr ");
}

function error_off()
{
    $error_handler = set_error_handler("myErrorHandler");
    error_reporting(0);
}

function error_on()
{
    restore_error_handler();
    error_reporting(E_ALL);
} 

Lediglich den Aufuf von logging() musst ggf. anpassen, falls du nicht meine Logging Funktion nutzt.

Mit error_off(); leitest du die Fehler um. Mit error_on(); landen sie wieder im EDOMI Error Logfile.

[gulp2k]

Zu meinen ModBusMaster.php-include-Fehlern im Fehler-Log (Siehe oben): Kann man die irgendwie sinnvoll abfangen und vor edomi verbergen oder zur Warnung reduzieren? Oder hat das gar jemand schon gemacht oder eine schlanke Fassung aus der Lösung geschnitzt oder das ganze non-FC3-Gedöns drumherum? Weil es kommen ja Werte, ERROR scheint mir da völlig unagmessen...

Wenn du meinen LBS als vorlage genommen hast dann sollte da schon vieles davon abgefangen werden...
Ich habe sowohl im phpmodbus.php Sachen reduziert wie auch in meiner Fehlerbehandlung im Exec Teil.

Leider gibt es immer noch ab und zu Fehler dennen ich noch nicht auf die Spur gekommen bin, deshalb war ein kompletter neubau angedacht.
Ist aber leider im Moment wegen Zeitmangels in der Prio nach hintengerutscht...

Generel finde ich das die phpmodbus ziemlich buggy ist und vieles auch unötig kompliziert macht.
Bei einem anderen LBS für die KWL habe ich es komplett selber gemacht und das geht sehr gut!

[saegefisch]

...irgendetwas schief gelaufen (vermutlich in der Programmierung )

...oh, verdammt, das musste ja irgend wann heraus kommen...

Nach Deiner Rückmeldung werde ich mich auf jeden Fall noch mal an das MQ-Thema setzen, den es erschient mir dann objektiv als die beste Lösung. Ich möchte ja "gute IT" machen - schlechte IT sehe ich privat und beruflich leider schon viel zu viel.

Das Löschen der MQ hatte ich genau dort, aber es kam dennoch zu schnell für das PHP7-Script - "bin/ps x" ist das offen-gnadenlos. Vielleicht müsste man am Ende einfach noch klarer aufräumen, also auch "kill -9" für diese Prozesse, damit es keine Restanten gibt, die als Zombie stören. Werde in anderem Thema Dich wohl noch mal fragen, hier ist es etwas OT, da ich zum EXEC keine MQ für ModBus brauchte, da reichen unidirektional die Eingänge.

Wenn du meinen LBS als vorlage genommen hast dann sollte da schon vieles davon abgefangen werden...

die Funktionen error_on(), error_off().

Meinen LBS habe ich neu begonnen aus meinem Schema (LBS-Vorlage um eigene Vorlieben ergänzt, wie log,...). Ich fange immer lieber neu an und bediene mich anderen LBS-Snippets, als zu kopieren und umzubauen. Mir erscheint es besser, da dann keine Zeile undurchdacht im neuen LBS steckt.
Dabei habe ich natürlich Eure Code-Strecken gesehen, aber da sich mir die Funktion nicht erschlossen hat, übernahm ich sie nicht. Mit Eurem Hinweis werde ich mir das noch mal anschauen; es wäre ja genau die workaround-Lösung, die schon mal hilft.

Generel finde ich das die phpmodbus ziemlich buggy ist und vieles auch unötig kompliziert macht.
Bei einem anderen LBS für die KWL habe ich es komplett selber gemacht und das geht sehr gut!

Damit wär's natülich noch schöner. Wenn Du irgendwann die Zeit findest, aus dem KWL-LBS das zu generalsieren und die Funktionen gleich heißen, wäre der spätere Umbau ja ein Klacks: Anderes Include oder einfach nur die Funktionen hinten dranhängen.

Lediglich den Aufuf von logging() musst ggf. anpassen, falls du nicht meine Logging Funktion nutzt.

Wunderbare Vorlage, prinzipiell schon, aber ich habe sie mir etwas anmeine Vorlieben angepasst..

[saegefisch]

wow, das ging ja einfach! Damit ist mein LBS-Daemon-Schema um eine weitere Komponente reicher. Seeehr cool, sehr hilfreich. Danke!

Veritable Werte via ModBus aus meinen SMA-Komponenten ganz ohne SunnyPortal in variabler Abfragefrequenz zwischen 500ms und 15s, edomi-Fehler-Log bleibt leer und das custom-log zeigt das Gedöns auch nur bei LogLevel 8. Last erträglich ab 1s und länger.
Habe noch einen "Wert-Unverträglichkeit" bei Vorzeichen. Sollte heute noch gelöst werden, LBS kommt also bald in den DL...

Wäre dann für einen kritischen Blick darauf durch Dich, André, dankbar hinsichtlich Perfomance-Fehlern (oder auch sonstigem)

[uzi10]

geht das auch für Fronius?? Rennen doch beide nach Modbus mit Sunspec Protokoll oder?

[saegefisch]

Mein LBS ist sicher/hoffentlich eine gute Ausgangsbasis für jedwede ModBus-Abfragen, aber definitiv für SMA ausgelegt hinsichtlich der Interpretation der gelesenen Daten, als auch des Eingangsparameters passend zur SMA-Struktur. AUch wenn ich ein Freund von "generisch" bin, erschien mir hier diese Lösung zweckdienlicher.

Ich nehme mal an, das Fronius eine ähnliche Doku anbietet, wie SMA. Vergleichen und anpassen, wenn der LBS da ist. Ist alles gut im Code dokumentiert, was wo und wofür passiert. Zu SunSpec kann ich nichts sagen.