Kompatibilität von Edomi mit neueren PHP Versionen

[jonofe]

Ich versteh den ganzen Aufwand nicht...
Seit nunmehr 7 Monaten gibt es meinen brainf*ck-Interpreter-Baustein. Damit kann man doch alles erschlagen was in PHP nicht geht

Wenn du wüsstest, wen ich damit schon so alles erschlagen habe ...

[saegefisch]

Michael, später...nach Deinem Tod, wenn die Welt die Schönheit und Funktion erst überhaupt begreift, dann wird er die Welt verändern. Es ist soooo oft bei den großen Künstlern...vielleicht wird es Jahrhunderte dauern...wenn die Welt bereit ist dafür. Um wieder einen Film zu bemühen...ohne Deinen LBS hätte O'connor den Kampf damals, in der Zukunft nie gewinnen können gegen die Maschinen...

<dafürwurdenochnichtderpassenesmileyerfunden>

Sag mal, wenn ich an E1...??!?

[wintermute]

Jaja, es ist das harte Los von uns extrovertierten Avantgardisten, dass wir sehr oft falsch oder gar nicht verstanden werden... ich kenn das ja mittlerweile

[Nanosonde]

Hallo André,
das sieht sehr gut aus.
Genauso habe ich mir den Baustein vorgestellt.

Generell würde ich aber zukünftigen Entwicklern von externen LBS dazu raten, Deinen Baustein nur als Vorlage zu nehmen und nicht GENAU diesen von Dir zu verwenden. Für schnelle Tests ok, aber für den endgültigen Release eines extern realisierten LBS sollte Dein Baustein entsprechend angepasst werden, so dass die passende Hilfe da und die richtige Anzahl an Ein- und Ausgängen mit Beschriftungen vorhanden ist.
Auf die ID der Message-Queue sollte dann auch geachtet werden, so dass sich diverse externe LBS nicht ins Gehege kommen.
Die ID aus der LBS-ID zu generieren reicht bei mehreren Instanzen ja leider nicht aus, sonst könnte man das auch evtl. verbergen. Aber wie bekommt der externe Teil das mit? Vielleicht sollte man den User dann doch soviel zutrauen.

Ich finde es auch prima, dass Du JSON verwendest und nicht die PHP-Serialisierung.

[jonofe]

Generell würde ich aber zukünftigen Entwicklern von externen LBS dazu raten, Deinen Baustein nur als Vorlage zu nehmen und nicht GENAU diesen von Dir zu verwenden. Für schnelle Tests ok, aber für den endgültigen Release eines extern realisierten LBS sollte Dein Baustein entsprechend angepasst werden, so dass die passende Hilfe da und die richtige Anzahl an Ein- und Ausgängen mit Beschriftungen vorhanden ist.

Ja genau so sehe ich das auch. Daher habe ich es auch so gemacht, dass man die Anzahl der Ein-/Ausgänge leicht anpassen kann.
Vermutlich werde ich aus den beiden Eingängen E4/E5 zwei interne Variablen machen. Dann muss man lediglich im DEF Teil des LBS die Ein/Ausgänge anpassen, die Anzahl einstellen und schon ist der Baustein individialisiert.

Auf die ID der Message-Queue sollte dann auch geachtet werden, so dass sich diverse externe LBS nicht ins Gehege kommen.
Die ID aus der LBS-ID zu generieren reicht bei mehreren Instanzen ja leider nicht aus, sonst könnte man das auch evtl. verbergen. Aber wie bekommt der externe Teil das mit? Vielleicht sollte man den User dann doch soviel zutrauen.

Vermutlich müsste man sich hier auf eine Konvention einigen. Wenn es immer nur eine Instanz eines solchen Bausteins gäbe, dann könnte man die LBS Nummer nehmen. Oder z.B. die LBS Nummer mit einer vorangestellten 2-stelligen Zahl. Bsp: Jemand entwickelt den LBS19000701, dann würde man die ID auf E2 einfach von 01 bis 99 hochzählen und die MSG Queue ID wäre: 019000701 bis 9919000701. Da die LBS Nummer eindeutig ist, würde man so eine eindeutige ID je Instanz erhalten. Der Nutzer müsste dann lediglich drauf achten, dass er denselben LBS nicht mehrfach mit derselben 2-stelligen Zahl am Eingang E2 konfiguriert.

Ich finde es auch prima, dass Du JSON verwendest und nicht die PHP-Serialisierung.

Ja, das ist der Tatsache geschuldet, dass dies aus meiner Sicht in den meisten Programmiersprachen gut unterstützt ist. Damit sollte sich dann eigentlich immer eine Lösung finden.

[saegefisch]

Hallo André, hallo allerseits,

für das Thema Multicast ist Deine Lösung ja eine Möglichkeit. Ziel ist eine elegante und verlässliche Lösung (im Rahmen dessen, dass PHP 5.3 kein Multicast selber kann).
Oder ist der LBS 19000278 mit der socat-Lösung besser (hier)?
Oder ein externes PHP5.6-Programm, dass per

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

den Multicast-Payload an edomi liefert (war ein Vorschlag hier)
Oder habe ich einen Alternative übersehen?

Sofern der LBS-Connector die beste Lösung wäre: Wie wäre das richtige Vorgehen, um auf edomi ein neueres PHP parallel zu installieren und damit zu nutzen?

Zur Installation

rpm -Uvh https://mirror.webtatic.com/yum/el6/latest.rpm
yum install php56w php56w-opcache

richtig?

Wo lege ich am besten das PHP-Programm ab, dass in der höheren Version läuft? Mir schient es zweckdienlich, es im gleichen Verzeichnis abzulegen (/usr/local/edomi/www/admin/lbs), z.B. "php5.6_read_sma_multicast.php".

Wie würde das Programm gestartet werden?
A) Wäre es sinnvoll, einen Starter-LBS zu haben, der nichts anderes tut, als das externe PHP-Program zu starten (bei E[1]==1) und dauerhaft (z.B. mit usleep=1000) am laufen hält, bis der starter-LBS selber gestoppt wird (E[1]==0)? Denn man weiß ja nicht, wann ein Multicast "vorbei kommt".
B) Oder wäre das zu viel Systembelastung und man sollte das Programm aus dem LBS Connector einmalig starten (mit E[6]==<was auch immer>) , warten auf den nächsten Multicast und den verarbeiten? Den LBS Connector würden man dann z.B. alle x Sekunden starten. Wie starte man aus dem LBS eine externes PHP-Programm (vermutlich eine doofe Frage, aber ich weiß es schlicht nicht)?

Das externe PHP-Programm muss nach dem Start auf den gewünschten Multicast lauschen und bei Empfang per JSON auf die Message Queue senden (wäre bei mir ein monolithischer 600Byte-String). Und dann - je nach obiger "Geschmacksrichtung" - so lang weiter lausche, bis es aktiv beendet wird (A) oder sich direkt beenden (B).

Ich werde mal einen Test mit einem PHP 5.6.27 basierten LBS machen und wieder berichten, falls es jemanden interessiert. Einen kurzen Test mit einem kleines JAVA und C Programm habe ich heute auch schon gemacht. Aber die Tücken liegen ja meist im Detail, wenn es dann um echte Funktionalität geht.

Wenn also Bedarf vorhanden ist, einfach mal testen ....

Du hast Recht, das multicast Thema wäre vielleicht mal ein guter PoC...

Wenn tatsächlich die beste Lösung ist, dann würd' ich dagerne mal drauf zurück kommen: Ja, interessiert! Wenn Du magst, können wir das Thema die Tage mal für einen Multicast bis zum sauberen Laufen bringen.


Viele Grüße,
Carsten

[jonofe]

Hi Carsten,

es führen natürlich viele Wege nach Rom. Wenn du nur Daten zu EDOMI senden möchtest und nichts von EDOMI zurückgesendet werden muss, dann würde vermutlich ein externes PHP5.6 Skript zusammen mit der EDOMI Remote Schnittstelle ausreichen.

Wenn man den LBS19000642 External LBS Connector verwendet, dann würde ich vermutlich den externen LBS über einen EDOMI Shell Befehl starten, den man über das EDOMI System-KO-2 (Systemstart) triggern könnte. genauso würde ich über einen Shell Befehl den externen LBS auch wieder beenden. Geht ja dann auch über das EDOMI System-KO-2. Der externe LBS sollte dann als Daemon laufen und die ankommenden Daten dann an den LBS19000642 weiterreichen.

Hast du denn das notwendige PHP Skript für php 5.6.x fertig?

[saegefisch]

Hi André,

danke für Deine Einschätzung - das scheint mir nachvollziehbar sinnvoll, da ich nur empfangen will. Was mir erst durch Deine Antwort in den Sinn kommt: Der push des Senders ist in diesem Anwendungsfall auch viel sinnvoller, also ein poll durch edomi.

Nein, wollte erste den Weg entscheiden. An das Script werde ich die Tage mal gehen - mit der Remote-Lösungsstrategie kann auch das auch gleich auf meinem anderen Server mit aktueller PHP-Umgebung machen und muss nicht auf edomi parallel PHP 5.6 installieren. Einfach ist gut. Nach vielen Wochen Pause muss ich mich erst wieder an PHP heran tasten - aber das wird schon...

Sorry, dann wird das zunächst doch kein Anwendungsfall für Deine wirklich coole Lösungsoption mit LBS 19000642 ...<schäm>

[jonofe]

wenn du das mal fertig hast, dann wird die Anpassung für den 642 LBS nur minimal sein.
kannst du mir ja dann mal schicken, dann können wir mal einen kleinen Test machen.

[saegefisch]

Hi André,
ein erster Wurf ist fertig und habe ich jetzt mal manuell per nohup im Hintergrund gestartet. Mein Smartmeter liefert mir <=1 Sekunde neue Werte, ich habe aber mal mit 3 sek angestoßen und werde den mal die Nacht durchlaufen lassen. top auf dem Server zeigt nahezu keinen Ausschlag, wenngleich ich die Lösung der Startens nicht sauber finde. Das sollte wohl mit cron gehen und am besten stellt das System, dass der Job schon läuft und nicht noch mal startet; dafür aber, wenn er abbrach oder bei neustart. Vermutlich haben erfahrene User da was im Portfolio, wie man so etwas sauber und verlässlich löst. Da will ich die Tage noch ran, wenn es inhaltlich gut läuft.

Aber die Werte kommen wunder in edomi an und das ganze ist bereits recht flexibel (Wirk, Schein, Blind, Arbeit, U, I, cos Phi, Grunddaten, Phasensummen, pro Phase). Ich bin ziemlich begeistert. Mir reicht P und U als Summe und die Phasen. Und wenn man mal bei SMA richtig schaut: Die haben das Protokoll mittlerweile in einem PDF auch offen gelegt (es war nur ein Fehler drin) und so war's doch ein schönes Stück Arbeit. Okay, wenig Schlaf die letzte Nacht...

Um auf meine Frage und Deinen Rat zurück zu kommen: Es war wohl genau der richtige Weg: Schön einfach und letztlich nicht schwer. Sicher kann man es auch schön er lösen, ich bin glücklich... Die Lösung mit Deinem LBS 642 kann nur komplizierter sein...

Werde das Skript noch ein wenig schleifen die Tage... - ich lass es Dir mal zukommen.
Letztlich würde es dann in einem anderen Threat zum Thema Multicast einstellen - die grundsätzliche Kritik (u.a. von Christian) ist ja durchaus begründet, aber es gibt Fälle, wie der des Smartmeters, wo es egal ist, ob mal ein cast nicht ankommt und auch kein Dialog erforderlich ist. Und genau für diese Fragestellungen auch anderer dürfte die Lösung chamant sein und adaptierbar.

Viele Grüße, muss jetzt mal heute früher ins Bett...
Carsten

[saegefisch]

@André: Da iss' er - der erste Wurf... Da das ganze schon recht gut lief, habe ich es mal direkt eingestellt. Ich denke, dass der gewählte Lösungsweg tatsächlich eine gute Entscheidung war. Über kritische Rückmeldungen freu' ich mich natürlich immer.

[saegefisch]

Hallo André,

wenn du das mal fertig hast, dann wird die Anpassung für den 642 LBS nur minimal sein.
kannst du mir ja dann mal schicken, dann können wir mal einen kleinen Test machen.

Mit meinem leidigen Multicast-Thema wegen der VLAN-Subnetze im MirkoTik gibt es ja auch eine Alternativ-Lösung: Da Multicast-Sender (SMA) und Ziel (edomi; non-Multicast-fähig wegen PHP-Version) im selben VLAN liegen, nur der Linux-Server mit dem Aufbereitungsscript nicht (mehr), könnte doch Dein LBS 19000642 zum Einsatz kommen.
Hast Du den selber noch im Einsatz?
Hältst Du den LBS für Fragestellungen, die mit dem PHP 5.3.3 nicht lösbar sind, weiterhin für eine sinnvolle Lösung?

Falls nein, dann wäre nur 1. und 2. nötig unten nötig: Script läuft zwar auf edomi-HW, aber ich pushe wie bisher die Daten in edomi per http-API. Ist vermutlich die schlankste Lösung.

Falls ja, vermute ich folgende Schritte für einen ersten, sehr einfachen Test, der aber in sofern vergleichbar ist, dass das ausgelagerte Script sekündlich/asynchron zum edomi-LBS arbeitet:

1. Installation per
   

   rpm -Uvh https://mirror.webtatic.com/yum/el6/latest.rpm
   	yum install mod_php71w php71w-opcache

   Das wäre dann 7.1.1 für CentOS 6.x und damit das aktuellste PHP, richtig?
2. Ein PHP 7.x-Script, dass im ersten Wurf z.B. nur sekündlich (per sleep) einen timestamp liefern kann (später: sekündlich aus Multicast aufbereitete Daten)
   • 2a. Wo legt man das am besten ab? Einfach im selben Verzeichnis, wie die anderen "echten" edomi-LBS? Oder stört das dort edomi?
   • 2b. Wie löst man es professionell, dass das Script außerhalb von edomi automatisch startet bei jedem reboot und immer läuft (Deamon). Oder kann man das von edomi aus starten/sicher stellen?
     Meine bisherige cron-Lösung hat zwar funktioniert, ist aber vermutlich eher "handwerklich grob geschnitzt" und hat außerdem "Leichen" hinterlassen...
   • 2c. Wie sage ich dem Script, dass es mit der neuen PHP-Version laufen soll?
3. ExternalLBS einrichten mit einem E für die Schlafzeit und einen A für den gelieferten timestamp. Der LBS würde z.B. 5-sekündlich getriggert (könnte z.B. temporär auf sekündlich sinken, wenn man auf einer Viso-Seite ist, in der die Energiewerte relevant sind)

Wenn das geht, werde ich in der Lage sein, die Multicast-Logik zu adaptieren und in das Script einzubauen.

[jonofe]

Ich würde ich es so wie im Spotify LBS machen, d.h. wie von wintermute vorgeschlagen, die Software Collections (SCL) zu verwenden. Das ist ein sauberer Weg und funktioniert bei mir sehr stabil:

# 1. Install a package with repository for your system:
# On CentOS, install package centos-release-scl available in CentOS repository:
$ [COLOR=#0000CD]sudo yum install centos-release-scl[/COLOR]

# On RHEL, enable RHSCL repository for you system:
$ [COLOR=#0000CD]sudo yum-config-manager --enable rhel-server-rhscl-7-rpms[/COLOR]

# 2. Install the collection:
$ [COLOR=#0000CD]sudo yum install rh-php70[/COLOR]

Andere Wege php7 zu installieren werden aber bestimmt auch funktionieren. Man muss halt immer schauen, wie der entsprechende Aufruf funktioiniert.

Wenn das Skript nur laufen muss, wenn EDOMI läuft, dann würde ich es von dort aus starten. Das Skript kann dann entweder selbst als daemon implementiert sein, dann musst du in EDOMI nur den initialen Trigger geben oder du triggerst das Skript regelmäßig, d.h. es beendet sich nach jedem Durchlauf und EDOMI übernimmt das dann, z.B. per Telegrammgenerator.

Der Start des Skripts wird bei mir wie folgt gemacht:

exec("scl enable rh-php70 'php /usr/local/edomi/www/admin/include/php/spotify/19001195_spotify.php >/dev/null 2>&1 &'");

Das beantwortet auch die Frage, wo ich die Skripts ablege:

/usr/local/edomi/www/admin/include/php/<DIR-NAME>/

Und wenn du nur eine Ausgabe des Skripts in EDOMI bringen musst, dann kann man das einfach über die HTTP API von EDOMI machen.

[saegefisch]

Vielen Dank!

Damit sollte ich schon weit kommen, Installation werde ich dann auf jeden Fall per SCL machen.
Nachtrag: Wollte gerade installieren, aber "yum-config-manager: Kommando nicht gefunden". Fehlt da sowas, wie "yum install yum-utils"?
Dank meiner Unerfahrenheit im PHP/Linux-Kontext dennoch ein paar Fragen...

Das Script sollte dauerhaft als Daemon laufen, da Listener für einen (fremdgelieferten) Multicast der wiederholte Aufruf aus edomi heraus mir nicht zweckdienlich erscheint. Reicht für einen Daemon bereits das "&" am Ende des EXEC oder gibt noch etwas zu beachten? Konkreter gefragt: Versteh ich es richtig, dass 19001195_spotify.php als Daemon konzipiert ist und vom LBS einmalig gestartet wird und dann "ewig läuft" (ich vermute, an A1 hängt System-KO 2 "Systemstart") - dann kann mir ja als Vorlage dienen. Dann würde ich einen entsprechenden LBS machen, der nichts anderes tut, als genau den daemon zu starten. Oder dient das & nur als "im Hintergrund ausführen" und wird doch regelmäßig von edomi aufgerufen?

Die gesamte Kommunikation zwischen LBS und Script erfolgt per msg_queue? Damit könnte ich auf dem Weg z.B. die Sleep-Zeit des Daemon setzen und anderes? Rückmeldung wäre auch möglich, sofern sie nicht wie die "Nutzlast" über die http-API in edomi gedrückt werden, richtig?

[jonofe]

Ja, alles korrekt. Ja kann sein, dass yum-utils fehlt. Wenn es danach funktioniert, dann wars das.
Der spotify Aufruf erfolgt als Daemon. Bei spotify ist die Besonderheit ist, dass es zwei Daemons sind. Einer im EXEC des LBS als PHP 5.3.3 daemon, der eigentlich nur die Rückmeldungen des PHP7 Daemons entgegennimmt und auf die Ausgänge gibt.
Der LBS Teil startet den EXEC Daemon und dieser dann den PHP7 daemon. Alle kommuniziert über EINE Message Queue. Über den Type einer Nachricht wird dann gesteuert, ob es vom EXEC Daemon oder vom PHP7 Daemon aus der Queue genommen und verarbeitet wird. So kann mit einer Queue die Kommunikation zwischen allen 3 Bestandteilen des LBS realisiert werden. Der LBS sendet an EXEC und an PHP7 und PHP7 sendet an EXEC.
Klingt zwar kompliziert, ist aber ganz einfach.