Kompatibilität von Edomi mit neueren PHP Versionen

[saegefisch]

Bei Dir ist es das ja auch...

[saegefisch]

Hi André,

mit Deinen Infos und auf Basis Deines LBS 19001195 "Spotify Control v0.1" habe ich jetzt eine generische Multicast-Lösung gebaut, die man im Daemon (PHP7) nur für den Anwendungsfall etwas spezifizieren muss; auch das Daemon-Script ist in weiten Teilen generisch. Da ich Dein Coding zunächst komplett übernommen , dann um die nicht benötigten Teile reduziert und letztlich für den Multicast-Anwendungsfall angereichert habe, sieht das Coding stark nach Dir aus und es liegt mir daher fern, das als LBS zum Download anzubieten.

@all: Gibt es überhaupt Interesse an einem generischen Multicast Controler LBS und einer Daemon-Script-Vorlage?
@jonofe: Falls ja, dann solltest wohlmöglich Du den LBS hochladen; ich würde nur zuliefern und Du könntest prüfen/adjustieren/schön machen bei Bedarf. Aber ich mag mich eigentlich nicht mit fremden Federn schmücken. Deine Lösung hätte ich nie so elegant umzusetzen vermocht. Respekt!

Damit sollte man mit wenig Aufwand jeden Multicast abfangen, aufbereiten und edomi bereitstellen können. Der Controller hat ein paar Grund-Parameter und 5 optionale Eingänge für spezifische Bedarfe. Die Ergebniswerte kann man entweder per HTTP-API in KOs pushen oder per MessageQueue auf bis zu 5 Ausgängen am generischen Controller-LBS ausgeben. Für jeden Multicast muss man einen Controler LBS verwenden und ein angepasstes Daemon-Script. Das Daemon-Script muss nur in 2 function an die spezifischen Aufbereitungs-Anforderungen angepasst werden. Das war's.

Von der Last liege ich bei 5-sekündlich bei kaum messbar, mit 1-sekündlich habe ich 0,5-1% zusätzliche Last. Die Lesefrequenz kann dynamisch über den generischen Controler-LBS adjustiert werden, z.B. länger im Default und nur, wenn jemand auf einer Visu-Seite ist, die die Werte nutzt, dann kürzer.

Auf jeden Fall ist für mich damit mein leidiges Multicast-Thema auf dem MikroTik erst einmal entschärft - auch wenn ich das mit PIM weiterhin gerne verstehen und auch lösen möchte, warum _dieser_ Multicast nicht in andere Subnetze gelangte. Aber es ist nicht mehr wichtig - Danke, André!

GenControlerLBS.JPG

PS@wintermute: Die Installation von PHP7 per SCL kam irgendwann mal von Dir, oder? Sehr cool, ging sehr geschmeidig in Sekunden. Danke auch Dir! Damit kann man jetzt jede Schweinerei mit neuerem PHP auf der edomi-Kiste vollbringen...

[coliflower]

@all: Gibt es überhaupt Interesse an einem generischen Multicast Controler LBS und einer Daemon-Script-Vorlage?

Kann, sein ... Das weiß ich vielleicht noch nicht ;-)

Was ich aber seit MikroTik erkenne ist, dass in der ETS5 die Schnttstellen nicht mehr automatisch erkannt werden :-( Ich vermute, dass das auch etwas mit Multicast zu tun hat ... Klaus Gütter kannst Du das so bestätigen oder mit einem Hinweis zum Sympton aushelfen ? Danke !

[Klaus Gütter]

Hallo Dariusz,

auch in der ETS5 werden die Schnittstellen normalerweise automatisch erkannt.
Zumindest wenn Multicast nicht geblockt ist.

Gruß, Klaus

[coliflower]

Danke !

[jonofe]

Was ich aber seit MikroTik erkenne ist, dass in der ETS5 die Schnttstellen nicht mehr automatisch erkannt werden

Das liegt aber vermutlich daran, dass ETS5 und KNX-Interface nicht in einem VLAN sind und das Interface somit basierend auf der Mikrotik Default-Config per Multicast Discovery nicht erkannt wird. Dazu brauchst du dann Multicast Proxy oder PIM

[coliflower]

Das liegt aber vermutlich daran, dass ETS5 und KNX-Interface nicht in einem VLAN sind

Das ist richtig.
Die ETS5 hängt im VLAN50 und KNX in VLAN10. Beide VLANs können heute vollumfänlgich auf einander zugreifen. Die FW-Regel (pfSense) lautet in beiden Richtungen PASS IPv4 any SOURCE to any DESTINATION.

das Interface somit basierend auf der Mikrotik Default-Config per Multicast Discovery nicht erkannt wird.

Du meinst mit "Schnittstelle und dem oben genannten "Scheunentor" in der FW wird mein Gira KNXnet/IP-Router im VLAN10 durch die ETS5 in VLAN50 nicht erkannt ?

[vento66]

Habt ihr nicht euren Mikrotik Thread dafür?

[coliflower]

Ja Papa, war oben eine Frage bzgl. Multicast ... ;-)
Hier geht es weiter ... https://knx-user-forum.de/forum/projektforen/edomi/1135824-mikrotik-über-lbs-steuern-edomi?p=1182928#post1182928

[saegefisch]

Generic Control LBS + PHP7-Daemon: läuft jetzt seit 5h fehlerfrei im Sekundentakt... ich bin recht zuversichtlich mit der Lösung...

[jonofe]

@jonofe: Falls ja, dann solltest wohlmöglich Du den LBS hochladen; ich würde nur zuliefern und Du könntest prüfen/adjustieren/schön machen bei Bedarf. Aber ich mag mich eigentlich nicht mit fremden Federn schmücken. Deine Lösung hätte ich nie so elegant umzusetzen vermocht. Respekt!

Hi Carsten,
für mich ist das vollkommen okay, wenn du den LBS bereit stellst. Es ist ja schließlich eine komplett neue Funktionalität, und keine Kopie mit gleicher Funktion und kleinen Anpassungen. Und da du sicher mehr Insights im Thema Multicast hast, macht das auch sicher mehr Sinn, wenn du ihn hochlädst und ggf. weiterentwickelst. Stehe natürlich gerne beratend zur Verfügung.

Also aus meiner Sicht: Feuer frei

[saegefisch]

Okay, dann werd' ich das mal die Tage die incode-Kommentare noch schöner machen und es einstellen.

Noch eine Frage: Durch die eindeutigen MessageQueueID sollte es doch problemlos sein, das selben Daemon-Script mehrfach aufzurufen, oder?
HIntergrund wäre: Ich möchte - wenn möglich - aus einem Multicast-Strom einen Werte (=1KO) in hoher Frequenz, aber andere reichen mir alle 15 Sek. Dann könnte man ja den Control-LBS mit dem selben Daemon-Script zwei mal starten mit unterschiedlichen Paramtern und Frequenzen.

[jonofe]

Ja das sollte funktionieren.

Ein bischen tricky ist immer das Löschen der Message Queue beim Beenden von EDOMI. Das funktioniert auch in einigen meiner LBS noch nicht korrekt.

Wenn der LBS explizit gestoppt wird (z.B. über einen Eingang), dann beende ich den EXEC Daemon mit posix_kill() und lösche die Message Queue im LBS Bereich. Das ist okay.

Wenn aber EDOMI beendet wird (z.B. per Admin Interface), dann bekommt der LBS-Teil das nicht mit und kann auch dem EXEC das nicht mitteilen.
Allerdings wenn der EXEC Daemon in einer while (getSysInfo(1)) Schleife läuft, dann wird die Schleife beim Beenden von EDOMI verlassen und man kann danach explizit die Message Queue löschen. Auch ok!

Problemfall: Läuft allerdings die Message Queue im EXEC Daemon im Blocking Modus, dann funktioniert auch dieser Ansatz nicht. Blocking heisst hier, dass das msg_receive() solange blockiert ist, bis eine neue Message vom LBS Bereich kommt. In diesem Fall bleibt die Message Queue nach dem Beenden von EDOMI bestehen, und zwar bis zum nächsten Reboot des EDOMI Servers oder bis man sie per "ipcrm" löscht.

Da es aber nur wenige Bytes sind, die in einer solchen Message Queue "hängenbleiben" ist das unkritisch.

[saegefisch]

jonofe Hi André,

das Thema MessageQueue (MQ) und Dein Script-Schema - da habe ich nun doch noch Fragen, ich strauchle noch bei der Adaption für "siehe oben". Der MultiCast gehört zum SMA-Themenkomplex aus dem anderen Thema (ModBus) - es wird also demnächst zwei LBS von mir geben: Ein generischer MultiCast (auch nutzbar für SMA EnergyMeter) und ein fast generischer, aber für SMA angepasster ModBus-LBS. Die Sinnhaftigkeit/Nutzen der MQ-Lösung ist mir mittlerweile klar und möchte ich daher begreifen und selber richtig nutzen.

Zur Info/Rückmeldung:

• Für das Logging im externen Scripten habe ich mich von Deiner Datei-Lösung gelöst und finde es hilfreicher, die LOG-Infos einfach per MQ zum EXEC-deamon zurück zu senden und dort in das reguläre Custom-Log notieren zu lassen = direkt in edomi an einer Stelle sichtbar. Das klappt an sich gut (meine MQ-Probleme liegen woanders; siehe Frage).
• Die von mir erwähnte Zähigkeit mit der MQ habe ich nun ergründet - und ist ganz natürlich: Im externen Script habe ich natürlich auch ein usleep (mit Zeiten bis 15s) und in dieser Zeit wird natürlich kein "stop" oder anderes verarbeitet. Schön Last-schlank, aber doof... Das externe Script muss aber nix aufräumen und werde ich per kill beenden, wenn es nach 500ms nicht reagiert hat (also vermutlich meist).
• Insgesamt kommt die empfundenen Zähigkeit mit der MQ aus den usleep-Zeiten... vielleicht muss man zwei usleep-Schleifen schachteln, die Innere bleibt für die Logik mit ggf. erheblich längeren Pausen und eine Äußere eher hochfrequente (z.B: 500ms) für das Lauschen auf der MQ und eben die Innere.

Fragen:

• In "function LB_LBSID_exec($id, $action = false)" beendest Du den EXEC-Teil per kill. Das heiißt doch aber, dass die übliche Code-Strecke nach dem Main-Loop zum sauberen EXEC-Abwickeln inkl. "sql_disconnect" nicht durchlaufen wird, richtig?
• Welchen Grund gibt es dafür, es nicht im deamon-Schema von Christian (mit usleep) zu lösen? Ich bin mir sicher, Dein Beweggrund ist wie immer wohl bedacht...
• MQ: Irgendwie löse ich es wohl gerade falsch beim start: Wenn ich dem externen Script 7 Werte übergeben will, tröpfeln die nur ein und mach' da wohl noch was falsch (abgesehen vom usleep-Thema; siehe oben).
  Mache ich das in 7 msg_send-Zeilen mit dem selben msgtype (z.B. "1") oder mit 1-7 oder "irgendwie" in einem msg_send? Auf dem Rückweg der Ergebnisse stellt sich die selbe Frage für mich. Letztlich will ich per MQ übertragen:
  - bis zu 7 Parameter EXE -> extern versenden,
  - bis zu 5 Ergebniswerte extern -> EXE,
  - LOG-Rückmeldungen extern -> EXE (2 verschiedene Log-Level).
  Derzeit nutze ich msgtype=1 für Parameter, 10 für Ergebnisse und 11 und 12 für die LOG-Rückmeldungen. Ist das sinnvoll oder habe ich das Prinzip der MQ-Verwendung noch nicht sauber verstanden? der msgtype ist doch gewisserweise ein "Kanal" in einer MQ, richtig?

Danke und viele Grüße,
Carsten

[jonofe]

Hi Carsten,

zu Frage 1: Richtig.

zu Frage 2: Das habe ich mal für einen LBS entwickelt, der eine blockierende Message Queue im EXEC Bereich verwendet. Man kann es genauso über eine Stop Message per msg_send machen. Sauberste Variante ist Start/Stop via Message ubd im EXEC eine nicht blockierende Message Queue mit usleep, wo dann beim Beenden von Edom aufgeräumt wird.

zu Frage 3:
der Message Type wird verwendet, damit mehr als 2 Prozesse bzw. mehr als 2 msg_receive Statements selektiv Messages aus der Queue entnehmen können. Wenn du z.B. Messages vom LBS zum EXEC ubd auch zu einem PHP7 Script senden möchtest, dann verwendest du z.B. Type 1 für EXEC und Type 2 für PHP. De entsrechenden Receive Statements entnehmen dann nur Messages, die auch für sie bestimmt sind.
Außerdem ann man damit auch Messages priorisieren. Dazu müsste ich jetzt aber selbst noch mal in der Online Hilfe nachschauen.