LBS 19000278 - UDP (Multicast)

[jonofe]

Könnte man eine aktuelle PHP-Version parallel auf dm System installieren und edomi nutzt die bisherige und das zu entwickelnde Coding die neue PHP-Version? Falls das ginge, wäre die Frage ob man nicht dem EXEC-Teil eines LBS die höhere PHP-Version andienen könnte... das würde sicher einige Fragen hier im Forum lösen...

Das geht leider nicht. Hatte ich auch schon mal vor einiger Zeit dran gedacht. Allerdings sind die Systemfunktionen, die du im EXEC Teil benötigst

require(dirname(__FILE__)."/../../../../main/include/php/incl_lbsexec.php"); 

mit bcompiler compiliert. Und bcompiler ist m.W. die wesentliche Komponente warum man an PHP 5.3.3 gebunden ist, denn bcompiler wurde nicht mehr auf PHP 5.4 portiert.

Parallel kann man natürlich eine andere PHP Version installieren und mit einem kleinen Skript und der Remote API von EDOMI entsprechende Multicast Daten in KO's pushen.

Ich hoffe ja auch immer noch, dass EDOMI mittelfristig höhere PHP Versionen zulässt. Ich hätte z.B. gerne eine google-calendar API eingesetzt. Aber alle neueren Projekte setzten PHP 5.4-5.6 voraus.

Mal sehn was die Zukunft so bringt...

[saegefisch]

Danke André für Deine Einschätzung. Auch für Deine Leichtigkeit und Erfahrung mit diesen Dingen...

Ich nehme daraus mit: Andere PHP-Version zu installieren ist möglich und erlaubt und unkritisch (damit ist es nicht nötig, derlei Dinge auf einen anderen Server auslagern zu müssen).
Ein darauf basierendes PHP-Script auf dem Edomi-Server ist denkbar, der Multicast abfischt und in ein KO pusht. Auslöser könnte der automatisch startende Dienst selber sein oder ein shell-Aufruf des Scrpts aus edomi heraus getriggert.
Der Aufwand könnte sich lohnen, wenn ein PHP-Upgrade aus genannten Gründen nicht absehbar zu erwarten ist.
Richtig?

Nachtrag: Kann man im EXEC-Teil nicht ein "außerhalb" liegende und damit in höherer PHP-Version agierendes Codestrecke ausführen - gewissermaßen als Include?

[jonofe]

Danke André für Deine Einschätzung. Auch für Deine Leichtigkeit und Erfahrung mit diesen Dingen...

Ich nehme daraus mit: Andere PHP-Version zu installieren ist möglich und erlaubt und unkritisch (damit ist es nicht nötig, derlei Dinge auf einen anderen Server auslagern zu müssen).
Ein darauf basierendes PHP-Script auf dem Edomi-Server ist denkbar, der Multicast abfischt und in ein KO pusht. Auslöser könnte der automatisch startende Dienst selber sein oder ein shell-Aufruf des Scrpts aus edomi heraus getriggert.
Der Aufwand könnte sich lohnen, wenn ein PHP-Upgrade aus genannten Gründen nicht absehbar zu erwarten ist.
Richtig?

Richtig!

Nachtrag: Kann man im EXEC-Teil nicht ein "außerhalb" liegende und damit in höherer PHP-Version agierendes Codestrecke ausführen - gewissermaßen als Include?

Du kannst aus einem LBS ein anderes PHP Skript starten, welches dann eine höhere PHP Version einsetzt. Ein include läuft allerdings immer im selben Kontext wie das Skript, dass das include enthält. Also im EXEC Kontext wäre dies PHP 5.3.

[saegefisch]

okay, dann würde ich - in Deinen Worten - sagen "Mal sehn was die Zukunft so bringt..." und auf Christians Rückmeldung warten. Ich gehe allerdings derzeit nicht von Bewegung dazu aus, denn irgendwann will er (und wir) ja auch mal seine Visu sehen - und man kann sich halt nicht teilen.

Und in Abhängigkeit davon wäre abwarten oder der nächste Schritt: aktuelle PHP zusätzlich installieren, PHP-Script außerhalb von Edomi erstellen.

Konkret zum Austausch zu edomi: Würdest Du/Ihr die Multicast-Daten irgendwo im Filesystem ablegen und dann mit LBS aus edomi heraus abholen? Oder direkt in ein edomi-Datenarchiv schreiben (Risiko?)? Oder in ein KO pushen? Da steh' ich gerade auf dem Schlauch: wie kann ich pushen? Stichwort reicht.

Danke!

[jonofe]

Hängt davon ab, was das für Daten sind und wo der Bedarf getriggert wird.
Tendenziell würde ich zu einem Listener als php Skript tendieren, der dann über die EDOMI Remote API direkt die empfangenen Daten in ein KO schreibt. Dazu könnte dann ein EDOMI-LBS der Empfänger sein, der dann die Daten aufbereitet, sofern dies notwendig ist.

Remote API funktioniert durch einen URL Aufruf der Form

http://<edomi-IP>/remote/?login=<user>&pass=<password>&koid=<edomi_KO_ID>&kovalue=<value>

Diese KO könnte dann einen LBS triggern, der die Daten aufbereitet und an entsprechenden Ausgängen bereitstellt.

Welches Device kommuniziert bei Dir eigentlich per Multicast?

[gaert]

Nix für ungut, aber ich halte ohnehin nicht viel von UDP-Multicast. UDP ist als solches schon unzuverlässig genug - wenn nun auch noch Multicast ins Spiel kommt, sieht's schnell finster aus. Die Pakete müssen ja u.U. diverse Switches, Router etc. passieren (am besten noch per WLAN) - wenn auch nur 1 Paket von 100 mal auf der Strecke bleibt, ist irgendwie nix gewonnen. Ich würde jedenfalls wenig Wert darauf legen schon auf "Layer 1" mit Unzuverlässigkeiten rechnen zu müssen.

[saegefisch]

SMA Energy Meter: Schönes Stück Technik, liefert mir (dann) sehr fundierte Leistungs- und Arbeitswerte (sprich: Zählerstände) in ca. 600Bytes. Nachgelagert werde ich dann einen LBS bauen, der die 600 Bytes aufbereitet und wohl rund 20 Werte pro Phase und gesamt auswerfen kann. Derzeit komme ich nur indirekt und stark reduziert auf die Daten durch das SMA-Cloud (mein LBS 19000110). Aber ich möchte die vollen roh-Daten bereit stellen.

Das dürfte auch alle anderen SMA-Betreiber hier im Forum interessieren. Das Teil ist nur optional, aber erforderlich, wenn man eine Batterielösung hinter der PV betreibt, da mit den Daten des EM der Batterie-WR agiert. Dafür braucht es Daten in hoher Qualität und Frequenz. Mir reicht eine geringere Frequenz für Leistungsdaten, für die Arbeitsdaten würde auch täglich reichen.

Nachtrag: Multicast ist (leider) die einzige Lösung, die mir den Zugriff erlaubt. Das gute ist - und dürfte für viele Multicast-Fragestellung (sicher aber nicht alle) zutreffen: Es ist nicht so schlimm, wenn man welche verpasst. Daher: Multicast ist völlig ok, wenn es denn zur Anforderung passt. Das ist hier der Fall - zumal LAN. Verlassen würde ich mich darauf auch nicht wollen und zeitkritisch dürfte es schon mal lange nicht sein.
Wenn Muticast bei einem nicht durchkommt, ist es natürlich keine Option, aber das kann man ja ändern. Bei mir kommt das hinreichen verlässlich durch (LAN und WLAN)

Darf ich noch mal nach Deinem Stand der Dinge zu "neue PHP-Version" fragen? Du hattest mal angedeutet, dass Du das erwägst. Nur um mir eine Abwägung zu erlauben (Warten lohnt oder nicht) wär's prima...

[woda]

Wär schon nicht schlecht, da hier mein Philips-TV per Multicast/UPnP verkündet wenn er eingeschaltet/ausgeschaltet wird. Im Homeserver lässt sich das schön auswerten und verarbeiten. Dies funktioniert schon seit Jahren problemlos. In EDOMI konnte ich dies bisher noch nicht lösen.

[gaert]

Gibt's nicht irgendein kleines Shell-Programm, das UDP-Multicast empfängt und per Socket oder ähnlichem weiterreicht? Die LBS sind ja prinzipiell nicht auf PHP beschränkt - man könnte durchaus ein Shell-Programm im Hintergrund starten lassen... (oder schon gleich beim Hochfahren des Servers).

[Winni]

Gibt's nicht irgendein kleines Shell-Programm, das UDP-Multicast empfängt und per Socket oder ähnlichem weiterreicht? Die LBS sind ja prinzipiell nicht auf PHP beschränkt - man könnte durchaus ein Shell-Programm im Hintergrund starten lassen... (oder schon gleich beim Hochfahren des Servers).

Letztendlich muss man sich nur in die Multicastgruppe mit einklinken, was mit

socat - udp-datagram:234.6.6.6:9050,ip-add-membership=234.6.6.6:eth0,bindtodevice=eth0

möglich wäre.

Ich kriegs aber nicht hin das im Hintergrund aus dem Baustein laufen zu lassen.
Deshalb auch meine Anfrage, ob man sich nicht irgendwo beim Reboot des Servers mit einklinken kann. Manuell iin der shell klappt's ja.
Meine Versuche (siehe alte Mails) sind zumindest damals gescheitert.....
Bin halt leider Linux und php Laie.

[jonofe]

Ich kriegs aber nicht hin das im Hintergrund aus dem Baustein laufen zu lassen.

Ich hab da was für dich ...

Trag doch mal folgendes in deine /etc/rc.local rein

/usr/bin/socat UDP4-RECVFROM:9050,reuseaddr,fork,ip-add-membership=234.6.6.6:eth0 udp-sendto:localhost:12345 >/dev/null 2>&1 &

und zwar vor die Zeile

sh /usr/local/edomi/main/start.sh

EDIT: Nach der Änderung EDOMI via Admin Seite rebooten.


Danach den UDP Listener LBS mit Port 12345 und IP 127.0.0.1 konfigurieren.
Danach solltest du auf Ausgang E2 "Ausgabewert IP1" alle Daten vom UDP Multicast Stream bekommen.

Habe es mit einem kleinen UDP Multicast Tool kurz getestet, welches auf einem anderen Rechner in meinem Netz lief und mir sekündlich die Uhrzeit per Multicast geschickt hat. Hat problemlos funktioniert. Der Ausgang A2 hat immer fleißig die Uhrzeit bekommen.

Den "socat" Aufruf könnte man vermutlich auch aus dem UDP Listener LBS heraus machen, dann müsste man nichts in der rc.local ändern.

Viel Spaß (hoffe ich)

André

[Winni]

jonofe
André, danke für die Mühen, leider bringt es mich nicht wirklich weiter.
Mit deiner Lösung verliere ich meiner Meinung nach die Ursprungs-IP. Da ich 3 Receiver im Netz habe könnte ich die nicht unterscheiden.
Die Option fork gibt es wohl bei meiner SOCAT-Parameter-Struktur nicht und folgendes in rc.local greift leider auch nicht:
socat.png
Klar würde ich den Aufruf am liebsten aus dem LBS heraus machen, dann könnte ich auch flexibel die Parameter versorgen.
Will aber irgendwie nicht klappen.

[jonofe]

jonofe
André, danke für die Mühen, leider bringt es mich nicht wirklich weiter.
Mit deiner Lösung verliere ich meiner Meinung nach die Ursprungs-IP. Da ich 3 Receiver im Netz habe könnte ich die nicht unterscheiden.
Die Option fork gibt es wohl bei meiner SOCAT-Parameter-Struktur nicht und folgendes in rc.local greift leider auch nicht:
{"data-align":"none","data-size":"custom","height":"133","title":"socat.png", "width":"1884","data-attachmentid":997089}
Klar würde ich den Aufruf am liebsten aus dem LBS heraus machen, dann könnte ich auch flexibel die Parameter versorgen.
Will aber irgendwie nicht klappen.

Es funktioniert auch nur, wenn der Parameter fork funktioniert. Ansonsten beendet sich socat nach dem ersten Empfang wieder.

Hier das RPM für CentOS 6.x:

https://forensics.cert.org/centos/ce...el6.x86_64.rpm

Wo kommt denn normalerweise sonst die Quelladresse her?

Kann man denn sie Multicast Adresse nicht konfigurieren? Dann nimmst du drei verschiedene, drei socats und drei lokale Ports und drei UDP Listener. Hast du mal geprüft, ob du die Quelle nicht anhand der Nutzdaten identifizieren kannst?

[Winni]

Es funktioniert auch nur, wenn der Parameter fork funktioniert. Ansonsten beendet sich socat nach dem ersten Empfang wieder.

Hier das RPM für CentOS 6.x:

Wo kommt denn normalerweise sonst die Quelladresse her?

Kann man denn sie Multicast Adresse nicht konfigurieren? Dann nimmst du drei verschiedene, drei socats und drei lokale Ports und drei UDP Listener. Hast du mal geprüft, ob du die Quelle nicht anhand der Nutzdaten identifizieren kannst?

Was ich nicht verstehe, dass es in der Shell problemlos funktioniert, einfach & hintendran und es wird ein Prozess eröffnet, der nicht nach dem ersten Eintrag wieder beendet wird

Was kann ich mit dem RPM anfangen? (sorry, aber ich kann damit nicht anfangen?!?!)

Nein, alle Receiver verwenden die gleiche Adresse. In den Nutzdaten ist kein Unterschied zu erkennen, von welchem Receivier die Daten kommen.

[jonofe]

Was ich nicht verstehe, dass es in der Shell problemlos funktioniert, einfach & hintendran und es wird ein Prozess eröffnet, der nicht nach dem ersten Eintrag wieder beendet wird

Ich habe es so bei mir ausprobiert und es funktioniert. Seltsam.

Was kann ich mit dem RPM anfangen? (sorry, aber ich kann damit nicht anfangen?!?!)

Downloaden und installieren:

rpm -Uvh socat-1.7.3.0-1.el6.x86_64.rpm

Nein, alle Receiver verwenden die gleiche Adresse. In den Nutzdaten ist kein Unterschied zu erkennen, von welchem Receivier die Daten kommen.

Dann wirds natürlich schwierig. Wie bekommst du denn bei deinem socat Befehl die Quelle heraus?