LBS: 19001030: Modbus TCP Master Read

[kobza]

Sorry Wechselrichter ist der STP 8000TL-20 ...
Logview wie oben schon beobachtet Daily Yeld passt so 0x674A (gelesen mit Windows Modbus Master) -> 26442Wh (passt so auch im Sunny Portal)

Wie oben geschrieben 2 Probleme: Low Byte ist 0x00 sollte aber 0x4A sein. Und mit 0x00 scheint die Umrechnung nicht zu klappen

EXE19001580 [v0.1]: SPT8000TL20 | 30535 | U32 | FIX0 | | [0,0,103,0] | HEX: 00670 | RAW: 1648 | Daily yield ==> 1648 | 1648Wh (81)

[saegefisch]

In meiner SMA ModBus-Doku findet sich keine STL-Serie... passt die Bezeichnung und hast Du einen Link zur ModBus-Doku des WR? Passt das Register zu Deinem WR?

Passt die IP-Adresse?

Schalte doch mal - geht auch im LiveView - auf LogLevel 8. Dann kann man genau sehen, was ausgelesen und wie es interpretiert wurde. Bei einem WR macht das um diese Zeit natürlich weniger Sinn, als bei eine SunnyIsland. Aber zumindest eine sicher Null sollte kommen. Bei mir kommt jetzt z.B. vom 7000er das an:
LBS19001580 [v0.1]: WR-7000 | 30775 | S32 | FIX0 | | [0,0,0,0] | HEX: 0000 | RAW: 0 | Power ==> 0 | 0W

Was liefert Deiner? Und vor allem, was liefert Deiner Morgen, wenn der WR produziert? Und am besten auch den Erwartungswert, damit ich eine Abweichung verstehen kann. Den Erwartungswert nach Möglichkeit nicht nur aus einem ModBus-Programm, sondern unbedingt zeitnah auch aus SMA-Quelle (Portal, App,...), damit wir von der Größenordnung keinen Geist jagen.

Es sollte z.B. etwas wie dies kommen:
S32 | FIX0 | | [0,0,3,200] | HEX: 003c8 | RAW: 968 | Power ==> 968 | 968W

[kobza]

Hi saegefisch,

danke für Dein SMA LBS, habe es heute ausprobiert, leider kriege ich keine vernünftigen Werte mit meinem STL 8000TL-20 Wechselrichter.


LBS.JPG

Die Liste besteht im Moment aus einem Eintrag: 30775;Power;S32;FIX0;W;RO;;
Ich habe auch andere Register probiert, leider sind die Werte immer falsch (und viel zu klein...)
Mit einem Modbus Master Windows Programm kann ich die richtigen Werte lesen...

Update:
Hier Auszug aus dem Logfile (für Daily yield)
EXE19001580 [v0.1]: SPT8000TL20 | 30535 | U32 | FIX0 | | [0,0,103,0] | HEX: 00670 | RAW: 1648 | Daily yield ==> 1648 | 1648Wh (81)
Erstens anscheinend wir der Hex Wert falsch berechnet 0x0670 statt 0x6700
Und dann ist der Low Byte 0 (wenn ich diesen Register aber mit dem Windows Programm auslese bekomme ich 0x674A)

Grüße
Thomas

[saegefisch]

kannst Doku zuliefern?
* Also Input (Register + Format + Datentyp) für einen/Deinen WR.
* Ausgabe, also die dazugehröigen Infos, die ich in der Hilfe auch notiert habe, Länge, Nachkommastellen,..., um damit die Logik anzupassen.

Wenn Du das halbwegs mundgerecht aufbereitest, schau ich mal... Vielleicht ist ja auch vieles ähnlcih und es ergäbe mehr Sinn, nur den Input vorab in Excel von Fronius -> SMA umzusetzen. Dann wäre es doch gänzlich generisch...

Also: Schau Dir mal die Beispiel-Input-Zeilen in der Hilfe an und suche mal bei Fronius das Gegenstück.

-----
Nachtrag: Hier scheint doch alles notwendige zu stehen:
http://www.fronius.com/~/downloads/S...410%2C2049.pdf

Zu den Datentypen steht was auf Seite 17.
Und aus dieser Zeile auf Seite 30:
40092 40093 2 R 0x03 W float32 W AC Power value

würde ich mal den Aufruf mit meinem LBS zu Deinem Fronius WR an E9 mit dieser einen Zeile versuchen:
40092;AC Power value;S32;FIX0;W;RO

Vielleicht kommt schon was und im besten Fall sogar das richtige...

Bitte gib' mir dann mal Rückmeldung. Wenn es am Ende nur eine etwas geänderte Eingangsstruktur und vielleicht etwas andere Zahlenformate/Datentypen sind...Am Ende könnte man noch einen EIngang E11 für den Hersteller ergänzen und vielleicht SMA, Fronius und andere damit abdecken. Denk' ich dann mal drüber nach, wenn wir die Unterschiede abschätzen können...

[uzi10]

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.

Wäre toll, wenn noch jemand einen Fronius Wechselrichter hätte und dazu das LBS umschreiben könnte

[saegefisch]

So, LBS steht bereit in V0.1... hier

[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.

[uzi10]

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

[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)

[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..

[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!

[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.

[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...

[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.

[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.