LBS 19000278 - UDP (Multicast)

[benji]

Mal noch eine andere Frage, du sagtest du benutzt Ekel schon in Edomi. Zerpflückst du den UDP RECV so im Logikeditor oder hast du einen LBS für ekey???

Gruß

[Winni]

Mal noch eine andere Frage, du sagtest du benutzt Ekel schon in Edomi. Zerpflückst du den UDP RECV so im Logikeditor oder hast du einen LBS für ekey???

Gruß

Eigene Bausteine waren mir zuviel Aufwand, ich nutze hier auch meinen PHP-Baustein. Ist praktisch, wenn man die Funktion nicht häufig braucht und keinen EXEC-Teil benötigt. Läßt sich auch schnell testen, weil ja direkt über KO manipulierbar.... (ja gaert, Edomi ist keine Entwicklungsumgebung..)

Ich häng mal meinen Logikseite ein, ich hoffe man kanns noch entziffern:
eKey Beispiel.jpg
KO 1071 kommt vom UDP-Baustein und enthält die Info vom eKey im home-Format.
KO 1078 bis 1082 enthalten die möglichen Codes, damit verschiedene Personen das Gleiche Steuern können. z.B. 242|452|542
Ich nutze grundsätzlich Relais 2 für die Logik, Relais 1 ist ohne Logik auf die Haustür verdrahtet (falls der Server mal steht)
Die zwei Stringverbinder generieren einmal den Code zu Auslösen der Aktionen und andererseits einen String der im Klartext ausgibt, wer mit welchem Finger am Scanner war, was ich in ein Datenarchiv wegschreibe. Bei jedem Scanvorgang löse ich auch ein Kamerabild fürs Archiv aus.

Ich hoffe ist wird ein wenig klar und hilft weiter...

Winni

[benji]

Super, danke. Ich schau es mir mal an.

Benjamin

[benji]

Hi,

habe mir den kram gestern mal noch zusammengebaut, funktioniert Super. Muss jetzt noch an der Meldung unbekannter Finger arbeiten und gut ist. Dein PHP LBS ist übrigens spitze.

Gruß Benjamin

[Winni]

Klappt alles irgendwie nicht. Auslesen müsste ich nicht, denn wenn der Prozess in der Shell läuft, dann funktioniert mein normaler Baustein einwandfrei. Aber egas was ich versuche, entweder ich kann nur einen Receive durchführen, oder gar keinen. Stabil läuft's nur wenn ich im Shell manuell sauber starte:
Einige wenige meiner Versuche:
$cmd = 'socat - udp-datagram:234.6.6.6:9050,ip-add-membership=234.6.6.6:eth0,bindtodevice=eth0';
// $ret = exec("nohup $cmd > /dev/null 2> /dev/null & echo $!");
$ret = shell_exec($cmd);
// $ret = popen($cmd, "r");

Mit shell_exec() klappts zumindest einmal......

Ich versuch's nochmal, kann mir hier jemand weiterhelfen? Der Befehl manuell in einer ssh-Session klappt, aber weder obige Versuche noch in EDOMI mit der Shell-Funktionalität kann ich das Ganze starten. Ist halt schon recht müssig das immer bei jedem Reboot neu zu machen.....

Winni

[Simone]

Winni beim programmieren kann ich dir leider nicht helfen. Ich habe aber seit letzter Woche deinen LBS für meine Türklingel am laufen, wenn ich irgendwas testen kann sag Bescheid

[mac29]

Hallo Zusammen

Ich verwende seit ein paar Tagen diesen Baustein für mein Ekey. Funktioniert soweit perfekt.
Nur nach einigen Stunden reagiert der Baustein nicht mehr. Der Ausgang A1 ist immer noch auf 1,
aber es werden keine Pakete mehr angezeigt. Wenn ich das Projekt neu starte, läuft alles wieder normal.

Hat jemand auch diese Probleme? Wie kann ich weiters was überprüfen? Den Baustein neu starten ist nicht möglich, oder?

Danke für Eure Hilfe.

Gruss Marco

[jonofe]

Ich denke es liegt daran, dass nach 8h ein Datenbank Timeout auftritt und der socket_recvfrom() Befehl blockierend verwendet wird.

Kommt nun 8h keine UDP Nachricht an, dann ist bei der nächsten UDP Nachricht die DB disconnected und das setLogicLinkAusgang() funktioniert nicht mehr und beim nächsten Durchlauf beendet sich der gesamte Prozess, da dann auch getSysInfo(1) = 0 ist.

Abhilfe: Füge nach der Zeile

socket_recvfrom($socket, $data, $v4, 0, $sendip, $sendport); 

den Befehl

sql_connect(); 

ein.

[mac29]

Danke vielmals, ich habe den SQL connect eingefügt und werde nun mal testen.....

[Simone]

danke, habe ich auch eingefügt.

[Winni]

Bitte um Rückmeldung, ob die Probleme damit behoben sind, würde dann den LBS entsprechend updaten.

[mac29]

Hallo Zusammen

Jetzt seit einem Tag getestet, so funktioniert es perfekt, alle Pakete kommen an, auch wenn mal mehrere Stunden keine Pakete versendet werden.
Aus meiner Sicht kannst du ein Update machen (und natürlich herzlichen Dank für den LBS ).

[saegefisch]

Auf der Suche nach einer Multicast-Lösung ein neuer Anlauf:
Da Multicast wegen der genutzten PHP-Version nicht möglich ist, ein Update wegen oben genannten Gründen nicht möglich ist und die socat-Lösung - so scheint es mir - nicht über den reboot verlässlich trägt (ohne es selber probiert zu haben), mag ich mal nach Alternativen Lösungen fragen - weil ich mich selber schlicht nicht genug mit den Technologin dahinter im Detail hinreichend auskenne:

Ist es denkbar, auf einem anderen linux-Server mit aktuellem PHP-Unterbau relevante Multicast-Paket abzufangen und "irgendwie" und einfach auf einen Kanal umbiegen, der mit edomi (oder sogar diesem LBS 278?) aktuell empfangbar ist? Was wären sinnvolle Eingangskanäle, auf die Nutzlast/Payload umgeleitet werden könnte? Kann man aus dem Multicast ein non-Multicast machen? Oder die Nutzlast roh auf einer Web-Adresse bereitstellen? Oder...? Oder hat doch jemand bereits eine verlässliche (soact-)Lösung mit LBS 278 doch zum Laufen gebracht?

@Christian: Oder planst Du vielleicht in absehbarer Zukunft bereits selber mit einer neueren PHP-Version für edomi? Nur um den Aufwand für eine Lösung abwägen zu können. Nicht, dass bereits zu 1.47...

[wintermute]

Kann man aus dem Multicast ein non-Multicast machen? Oder die Nutzlast roh auf einer Web-Adresse bereitstellen? Oder...?

Klar... sobald Du Multicast empfangen kannst, kannste daraus einen Unicast machen und zu Edomi schicken. Aber UDP auf UDP ist IMHO nicht so hip, ich wuerde - sofern das geht - die Nutzdaten in Edomi per HTTP-Aufruf direkt ein KO schreiben.
Oder Du machst einen auf mutig und installierst per Webtatic-Repo gleich ein PHP 5.5 oder 5.6... sind aber beides so "Loesungen" die ich vllt bei mir selbst ausprobieren, aber anderen nicht zumuten wuerde...

[saegefisch]

Michael, es ist nicht in Ordnung, dass Du so lange wach bist! Weißt Du nicht, wie wichtig der (Schönheits-)Schlaf vor 11 Uhr ist?

Danke für Deine Rückmeldung. Lass' und mal abwägen, ob das für mich lösbar ist - ich habe definitiv nicht Deine bewundernswerte Leichtigkeit und Erfahrung im Umgang bei diesen Themen. Bei mir immer auch etwas "blutige Arbeit" - aber es ist ja auch Hobby. Und eine Lösung wäre vielleicht auch für andere Fragestellungen anderer Teilnehmer hilfreich:
* PHP-Upgrade scheint mir kritisch, da ich damit den "sicheren Hafen" des Christians'schen Standards verlasse für die Haussteuerung. Mir scheint es dazu sicherer, seine Antwort abzuwarten, ob er diesbezüglich "irgendwie absehbar" einen Weg plant (dann wäre abwarten eine Option) oder derzeit nicht.
* Ich habe parallel einen Ubuntu-Server dauerhaft am laufen (u.a. tvheadend - hast Du vermutlich ja auch wegen kodi), bei dem ich alle Optionen habe. Ich könnte mir dort einen Service vorstellen, der dauerhaft die Multicasts (ca. 600Bytes 1-?x pro Minute; mir würde minütlich der letzte reichen) abfischt und edomi-gerecht aufbereitet. Mit "per HTTP-Aufruf direkt ein KO schreiben" meinst Du einen push zu edomi oder pull durch edomi? Könnte man die letzte Nutzlast nicht auf dem WebServer einfach in eine index.htm schreiben und edomi ruft die asynchron ab, wann immer ich es triggere?
* Oder könnte man per Shell-Aufruf (oder als automatisch startender Dienst) doch direkt auf dem edomi-Server ein Stück Code haben, dass die Multicast-Daten abfischt und irgendwo hinlegt und in einer Sequenz kommt danach ein LBS der diese Daten dann in ein KO schreibt? 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... Oder man setzt das shell-coding als non-php um, um das Versions-Thema zu umgehen (python,...)?

VG,
Carsten