Kompatibilität von Edomi mit neueren PHP Versionen

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

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

[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é,

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]

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]

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]

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.

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

[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

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

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

[jonofe]

Ja das sehe ich auch so. Ist für mich auch im Moment mehr eine technische Spielerei. Habe heute mal phpbrew ausprobiert. Damit kann man auf sehr einfache Weise verschiedene PHP Versionen installieren und parallel nutzen. Man kann sie ganz einfach umschalten und dann nutzen. Zusammen mit diesem LBS mal eine Möglichkeit etwas zu spielen.

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

[wintermute]

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

[saegefisch]

falls es jemanden interessiert

Hätte ich nur mehr Zeit...<grrr>...Wenn das Projekt beim Kunden von meinem geplanten Urlaub kommende Woche wenigstens die Hälfte übrig lässt, würde ich mal das Multicast-Thema aus dem anderen Threat mit aktuellem PHP versuchen: https://knx-user-forum.de/forum/proj...693#post996693

Andere Fragestellungen abseits des Standards hätt' ich gerade nicht. Und wo es nicht nötig ist, würde ich persönlich lieber immer beim Standard bleiben. Aber in den letzten Monaten gab es ja immer mal wieder Themen, wo dies eine Antwort sein würde; daher werden sicher andere folgen...
...wie gesagt...Schweizer Messer...hat MacGuyver es ja auch nur benutzt, wenn es nötig war. Aber dann war es nötig und war auch die Lösung...

[jonofe]

Ich habe jetzt mal den oben beschriebenen LBS hochgeladen:

External LBS Connector v0.1

External LBS Connector.png

Auf E1 gibt man dem externen LBS eine Namen. Dies wird lediglich für den Namen des Logfile verwendet.
E2 ist die Message Queue ID. Diese kann frei gewählt werden und muss vom Typ Interger sein. Diese ID muss auch im externen LBS verwendet werden, um zur Message Queue zu connecten.
E3 konfiguriert den Loglevel (0-8)
E4/E5 gibt die Anzahl der Ein-/Ausgänge an. Wenn mehr als 10 benötigt werden, einfach diese Zahl erhöhen und im LBS ###[DEF]### Source-Code einfach Ein-/Ausgänge hinzufügen. Ansonsten ist keine Anpassung im Source-Code notwendig. Auf gleiche Weise kann natürlich auch die Anzahl der Ein-/Ausgänge reduziert werden. Anzahl der Ein-/Asugänge kann unterschiedlich sein. (z.B. 10 Eingängen / 5 Ausgänge)

Ein eintreffendes Signal an E6-E15 triggert den LBS und sendet die $E[6] bis $E[15] als JSON encodeten String via Message Queue an den externen LBS (z.B. PHP7 oder JAVA Skript). Dieser muss es JSON decoden und kann die Werte entsprechend verwenden.

Der externe LBS hat nun die Möglichkeit Ausgänge des External-LBS-Connectors zu ändern. Dazu sendet er auch einen JSON encodeten String per Message Queue zurück. Hier stehen 3 Optionen zur Verfügung:

1.) Beispiel: Setzen der Ausgänge 1,3,5,10 via logic_setOutput:

    {"0":"[COLOR=#FF0000]Output[/COLOR]","1":"[COLOR=#0000CD]Value Output 1[/COLOR]","3":"[COLOR=#0000CD]Value Output 3[/COLOR]","5":"[COLOR=#0000CD]Value Output 5[/COLOR]","10":"[COLOR=#0000CD]Value Output 10[/COLOR]"}

2.) Beispiel: Setzen der Ausgänge 1,4,6,8 via logic_setOutputQueued():

    {"0":"[COLOR=#FF0000]OutputQueued[/COLOR]","1":"[COLOR=#0000CD]Value Output 1[/COLOR]","4":"[COLOR=#0000CD]Value Output 4[/COLOR]","6":"[COLOR=#0000CD]Value Output 6[/COLOR]","8":"[COLOR=#0000CD]Value Output 8[/COLOR]"}

3.) Beispiel: Senden einer Logging Nachricht (Diese wird im Custom Log File des External LBS Connector LBS geloggt):

    {"0":"[COLOR=#FF0000]Logging[/COLOR]","1":"[COLOR=#0000CD]<zu loggender Text>[/COLOR]","2":"[COLOR=#0000CD]<loglevel>[/COLOR]"}

Zur Nutzung der Message Queue sind folgende Dinge zu beachten:

1. Der externe LBS muss dieselbe Message Queue ID (E2) verwenden wie dieser External LBS Connector
2. Vom External LBS Connector zum Externen LBS wird Message Type "1" verwendet
3. Vom Externen LBS zum External LBS Connector wird Message Type "2" verwendet
4. Die Messaged (Eingänge, Ausgänge, Logging) werden JSON encoded/serialisiert und müssen nach dem Empfang entsprechen decoded werden.

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

VG
André