SMA Energy Meter (SMA EM) auslesen per Multicast und Lieferung an edomi

[saegefisch]

Status: LBS steht technisch, ist wohl strukturiert, liefert wunderbar und umfänglich Daten als Liste (wie bisher) und alle wichtigen Einzeldaten.

Es fehlt noch Doku, ein wenig mehr Logging und vor allem noch das Handling, um die Abfrage-Zeit im laufenden Daemon zu ändern; derzeit will if ($E=logic_getInputsQueued($id)) nicht so, wie ich will und reagiert nur auf E1, nicht aber auf z.B. E7 und auch bei E1 nur auf alle Werte ungleich 0.

Sollte hoffentlich morgen Abend oder spätestens übermorgen zum DL bereit stehen.

@all: Hat jemand bereits ähnliche Erfahrungen mit der edomi-Queue via $E=logic_getInputsQueued($id) mit daemons gemacht?

[jonofe]

Machst du denn im LBS Teil bei allen Events ein logic_set InputsQueued($id,$E) ?

[saegefisch]

Nein, im LBS-Teil habe ich es fast exakt so wie letzten Beispiel in der Hilfe von Christian, also nur 1x.

im EXEC-Teil habe ich auch nur 1x if-Abfrage-Block wie im Beispiel gemacht. Darin hatte ich dann mit Mehrere Eingänge mal mit refresh und Mal mit value versucht, zu differenzieren. Aber oft reagierte das Ergebnis gar nicht (weitere Eingänge) oder nur sporadisch/bestimmte (am E1) auf E-Änderungen. da liegt also wohl möglich der Fehler... guter Hinweis, André.

Da werde ich mal forschen - beim genauen Blick auf's Coding mit Deiner Frage im Hinterkopf - ist es eigentlich klar die Ursache...

Oder hast du schon einen LBS mit edomi-Queue gebaut? Hatte geschaut, aber Ich hatte nur welche mit deiner eigenen Message-Queues gefunden...

[saegefisch]

Nachtrag: Argh! Das war's - ich hatte den Fehler die ganze Zeit nur im EXEC-Teil gesucht... Jetzt geht jede Änderung wie gewünscht. Danke für die richtige Frage!

Dann kommt der fertige LBS sehr bald mit Tendenz heute Abend...

[jonofe]

Oder hast du schon einen LBS mit edomi-Queue gebaut? Hatte geschaut, aber Ich hatte nur welche mit deiner eigenen Message-Queues gefunden

Ja, hab schon einige. Manche alte m.W. auch schon umgebaut.
Das coole daran ist, man kann einen absolut minimalen LBS Teil generisch immer wieder verwenden, der einfach nur alle Events an den EXEC Teil weiterleitet und die gesamte Logik wird dann im EXEC Teil gemacht. Ich schau mal kurz ...

[jonofe]

Das ist ein generischer LBS Teil für einen LBS, den man über E1 mit 1 aktiviert und mit 0 deaktiviert.
In diesem Beispiel läuft der EXEC zwar bei E1=0 weiter, aber er bekommt keinen Input mehr.
Durch den dritten Parameter "false" bei logic_callExec() wird auch sichergestellt, dass nur eine Instanz des Daemons läuft.

function LB_LBSID($id)
{
   if ($E = logic_getInputs($id)) {
      // start EXEC daemon if E1 is set to 1
      if ($E[1]['value'] == 1) {
         logic_setInputsQueued($id, $E); // send inputs to queue for processing in EXEC part
         logic_callExec(LBSID, $id, false);// only one instance of EXEC daemon
      }
   }
} 

Die absolute Minimalversion eines LBS Skripts für einen Daemon LBS wäre vermutlich

function LB_LBSID($id)
{
   if ($E = logic_getInputs($id)) {
         logic_setInputsQueued($id, $E); // send inputs to queue for processing in EXEC part
         logic_callExec(LBSID, $id, false);// only one instance of EXEC daemon
   }
} 

Der würde halt immer laufen (ab dem ersten Trigger), könnte sicher aber natürlich auch basierend auf ankommen Triggern selbst beenden.

[saegefisch]

Ja, das Konstrukt von Christian finde ich auch sehr charmant und schlank gelöst. Allerdings habe ich noch zu kompliziert gedacht (und gestern in nächtlicher geistiger Umnachtung besonders...)

Nach Änderung heute morgen:

if ($E[1]['value']!=0 && ($E[1]['refresh'] == 1)) {

if (logic_getStateExec($id)==0) { //EXEC-Script läuft noch nicht
  logic_setInputsQueued($id,$E); //Eingangsdaten $E in der Queue speichern
  logic_callExec(LBSID,$id); //Exec-Script starten

} else { //EXEC-Script wird bereits ausgeführt
  logic_setInputsQueued($id,$E); //Eingangsdaten $E in der Queue speichern
}

LB_LBSID_logging($id, 'LBS SMA-EM Multicast ended');

}

// Alle jederzeit änderbaren Variablen: E1==0 | E7 | ...
if (($E[1]['value']==0 && ($E[1]['refresh'] == 1)) ||
  $E[7]['refresh'] == 1) {
  logic_setInputsQueued($id,$E); //Eingangsdaten $E in der Queue speichern
} 

Tatsächlich kann der Daemon mit E1 = 0 sich selber im EXEC-Teil beenden. Ich finde - gerade bei Fehlersuche oder Last-Themen - es unglücklich, wenn man etwas nicht stoppen kann. Und so mache ich ohenhin schon alles im EXEC-Teil. Daher ist Dein 2. Vorschlag noch besser, weil ich damit im LBS-Teil alles immer durchreiche - alle Macht dem Daemon!

Ich werde den LBS-Teil daher noch verschlanken - der Code dort schafft für diesen Fall schlicht keinen Mehrwert.

Noch mal lieben Dank, André.

[saegefisch]

benji Der LBS 19005181 ist in v0.1 verfügbar...

Ich hoffe, er funktioniert bei Dir ebenso stabil wie bei mir seit heute morgen und freue mich auf Deine Rückmeldung. Habe gegenüber meinem damaligen Ansatz einiges dem aktuellen Stand in eodmi angepasst (daemon, loging) und auch etwas umstrukturiert.

Siehst Du die Lieferung eines timestamps als wichtig an? Ich fand's nicht so wichtig und ließ es erst mal weg (weil z.B. Watchdog geht mit jedem Feld).
Wenn jemand Vierbesserungspotential sieht (technisch, inhaltlich, etc) - nur her damit!

Ich werde dahinter - wie bei allen remote-Quellen - noch einen Watchdog an ein beliebiges Feld hängen, der mir eine Mail sendet: nach 10 min eine Warnung, nach 1h eine Fehlermeldung

[benji]

Hi,

ich werde später mal testen. Im übrigen funktioniert er nicht nur am SMA-EM. Der LBS, welcher ich dir hab zukommen lassen, läuft bei mir an einem Sund Home Manager 2.0. Dies sollte der neue aber auch.

Gruß Benjamin

[saegefisch]

Ich habe nur den alten HM mit dem einzelnen EM, hoffte/dachte mir aber schon, dass SMA beim HM2.0 mit dem integrierten EM das Protokoll/Paketaufbau ohne Not nicht ändern.

Sollte es irgendwann ergänzt oder verändert werden, kann man nun leichten Fußes weitere OBIS-Parameter notieren und über E8 unterscheiden, z.B. "SMA_EM3", wenn es mal eine Version 3 gibt. Ich habe zwar mein Coding auf meinem alten Krams aufgebaut und adjustiert, aber auch mit Deinem abgeglichen; sollte also alles passen

Danke Deines Hinweises kann ich nun aber auch in er Hilfe notieren, das Gerät E8 = "SMA_EM" kompatibel ist EM 1.0 und HM2.0 (mit integr. EM)

[benji]

Hi,

bin erst eben zum Testen deines LBS gekommen. Läuft aber wie erwartet ohne Probleme mit dem SHM 2.0. Dann stampfe ich meinen LBS mal wieder ein.


Danke Gruß Benjamin

[saegefisch]

Hi,

hatte ja keine Eile...danke für Deine Rückmeldung; freut mich, dass alles läuft.

Irgendwelche Änderungswünsche? Ich habe bereits eine v0.2 fertig mit diversen kl. Änderungen, besserer Doku und Code-Hygiene aus eigenem Antrieb, wollte aber warten ob Du/jemand anderes noch Wünsche hat oder Fehler findet. Die lasse ich gerne noch einfließen und liefere dann gelegentlich aus. Hat meinerseits aber keine Eile.

VG,
Carsten

[r3dbull]

Ich bin leider noch nicht auf CentOS 7 umgestiegen.
Sobald ich dazu gekommen bin habe ich aber auch großes Interesse an eurem Baustein.
Werde ihn dann sicherlich auch einsetzen.

Gruß
Chris

[saegefisch]

Hi Chris,

gerne!

Als Tipp für ein mögliches Vorgehen: ich bin (wegen Zeitmangel leider seit vielen, vielen Monaten) auch noch im Umzug. Produktiv ist 1.64 auf dedizierter HW, in den letzten Tagen bin ich aber erheblich weiter gekommen, paralleles Zielsystem ist 2.02 (als LXC-Container auf Proxmox) komplett von Null neu aufzubauen (um Altlasten zu vermeiden - es hat sich seit 1.06 bis 2.xx viel getan...) und damit Stück für Stück umzuziehen und im 1.64 sukzessive zu deaktivieren. Das geht wunderbar gleitend. Wenn der Umzug fertig ist, werde ich das Produktiv-System auf CentOS7/edomi 2.02 neu installieren und das Backup aus der VM einspielen. Das sollte es dann gewesen sein. Die VM ist dann für mich "nur noch" Fallback, falls die HW mal aussteigt. Für eigene LBS-Entwicklungen empfehle ich eine weiteren LXC-Container nur für DEV mit Aktivierungszeiten von <5sek.

[saegefisch]

Update des LBS auf V0.3 --> Bugfix