Kompatibilität von Edomi mit neueren PHP Versionen

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

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

[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

[vento66]

Habt ihr nicht euren Mikrotik Thread dafür?

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

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

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]

@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 !

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

[saegefisch]

Bei Dir ist es das ja auch...

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

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

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]

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.