Perl Daemon schreiben ?

[JuMi2006]

Gemischt hab ich schon nicht ... ich teste das ganze nochmal mit select, den hatte ich noch nicht

Socket ist auch unsubscribed ... Ich hab das momentan auch in zwei Plugins ... das eine sendet nur auf den Socket, nutzt für ein SYNC-Zeichen allerdings kurzfristig recv ... ich weiß ja jetzt ... subotimal

Das lesen mach ich in einem zweiten ... oder eben dann separat ... die Idee mit dem zweiten Socket für einen daemon ist ja nicht so übel

Danke erstmal ... ich teste mal weiter

[netsrac]

Ich habe mir jetzt mal so ein eBus Interface bestellt. Sollte ich irgendwas brauchbares von meiner Therme bekommen, dann setzte ich mich gerne mit Dir zusammen hin und schaue mal, wie man so einen Daemon vernünftig aufbauen kann.

Habe schon einige Daemons laufen (inklusive failsafe Funktionen) und sehe da - im Moment - nicht unbedingt ein Problem...allerdings tendiere ich dazu, hier ein stand-alone-daemon zu bauen, da ich selbst das Wiregate direkt nicht einsetze....

[JuMi2006]

Ich hab auch nix gegen einen Standalone-Daemon ... der muss dann aber "mehrfach bidirektional" werden ... socket oder was auch immer.

Ich hab jetzt nochmal nen Schritt gemacht und einen Fehler in meiner Socket-Kommunikation gefunden ... vielleicht geht es doch noch etwas einfacher mit dem WG ...

Mitstreiter sind also gern willkommen

[netsrac]

Ich hab auch nix gegen einen Standalone-Daemon ... der muss dann aber "mehrfach bidirektional" werden ... socket oder was auch immer.

Was meinst Du mir "mehrfach bidirektional"?!

[JuMi2006]

War klar das die Frage kommt

Naja für einfache Statusmeldungen vom eBus reicht es aus sich Telegramme sammeln zu lassen und diese (per udp) an ein Plugin senden zu lassen.
Wenn man senden will ist es allerdings sinnvoll im Plugin live vom eBus zu lesen und auf das SYNC Zeichen (0xAA) zu warten und dann den Befehl zu senden. Das erhöht die Trefferquote. Der eBus liefert leider keine anständigen Datenpakete sondern die müssen selbst zusammengeschraubt werden.

Andererseits könnte man evtl. auch dem Daemon die komplette Kommunikation überhelfen aber da fehlt mir das KnowHow.

Weitere Idee wäre für jedes eBus-Gerät die Datenverarbeitung, ähnlich der config bei den Plugins, wieder in den Daemon zu laden. Das ganze ist ziemlich verhext .. ich bekomme z.Zt. auch kein Plugin ans laufen das mit zwei Sockets gleichzeitig umgehen kann. Nach neuesten Erkenntnissen und meinem Bug in der Socket-Kommunikation probiere ich das aber nochmal. Nen memleak habe ich auf jeden Fall damit schonmal beseitigt und vielleicht war der Bug auch der Grund für das fehlerhafte Handling mit den Sockets. Das muss ich aber erst noch testen.
Da meine Testumgebung auch ein Communitygate (auf nem Alix1D) ist kann es evtl. auch daran liegen. Da gibt es ein paar Kleinigkeiten die sich vom original unterscheiden und unter Umständen (sofern man nicht weiß wie es sein sollte) zu rätselhaften Phänomenen führen. Ich will das aber erst wenn es richtig läuft auf das Original umsetzen um keinen Krieg mit der Regierung anzuzetteln.

[netsrac]

Naja für einfache Statusmeldungen vom eBus reicht es aus sich Telegramme sammeln zu lassen und diese (per udp) an ein Plugin senden zu lassen.
Wenn man senden will ist es allerdings sinnvoll im Plugin live vom eBus zu lesen und auf das SYNC Zeichen (0xAA) zu warten und dann den Befehl zu senden. Das erhöht die Trefferquote.

Ohne mich jetzt mit der Thematik näher beschäftigt zu haben, aber ich würde mir schon vorstellen, dass der Daemon sowohl sendet, als auch empfängt. So kannst Du die Befehle zum richtigen Moment raussenden.

Aber wie gesagt...muss erstmal das Interface bekommen und irgendwie an unsere Therme anschließen....dann kann ich auch mitreden...

[JuMi2006]

So..um das mal kurz zu ergänzen ... Der Bug in meinem Daemon hat nun scheinbar auch das Handling mit 2 Sockets gelöst.
Nun muss ich noch die Henne/Ei-Frage klären und gucken wer zuerst da war: Daemon, Plugin, Socket ...

@makki:
Kurze generelle Frage zu den Sockets die mich ein wenig verwundert. Ich baue sowohl im Plugin als auch im Daemon eine Socketverbindung auf ohne jedoch eine Instanz von Socat gestartet zu haben und das funktioniert !? Auch im Prozessmanager ist keine entsprechende socat-Instanz zu finden. Gibt es dafür eine Erklärung?


Plugin:

IO::Socket::INET->new(
	Proto => "udp",
	LocalAddr => $daemon_recv_ip,
	LocalPort => $daemon_recv_port,
	reuseaddr => 1)

Daemon:

IO::Socket::INET->new(
	Proto => "udp",
	PeerPort  => $plugin_send_port,
	PeerAddr => $plugin_send_ip,
	ReuseAddr => 1
    )

Gruß Mirko

P.S.: Wer kennt sich mit Perl-Modulen und deren Erstellung aus ?
Ich würde gern einige De-/Encodierungen von eBus-Daten in das eBus.pm-Modul auslagern bzw. diese dort ersetzten.

Gruß Mirko

[makki]

@makki:
Kurze generelle Frage zu den Sockets die mich ein wenig verwundert. Ich baue sowohl im Plugin als auch im Daemon eine Socketverbindung auf ohne jedoch eine Instanz von Socat gestartet zu haben und das funktioniert !?

Ich kenne ja weder das Protokoll noch die SW im Detail, aber der Bauch sagt nein..
Also entweder direkt auf den seriellen Port (natürlich nur mit einem, Perl-Daemon, socat, oder..) -> UDP etc.

Nochmal etwas deutlicher: das kann man sicher mit Perl machen - irgendwie - gemacht ist es dafür aus high-level-sicht nicht; nicht alles was technisch möglich ist, ist auch sinnvoll.. Der socat macht da meistens die gute Fee, die das kaschiert aber timing-kritisch und Perl (unabhängig vom ganzen WG) versteht sich nicht wirklich..

Makki

P.S.: Es wird nen Grund haben warum ich ohne jegliches C-Know-How das mit der russsound in C geschrieben habe nachdem ich mit Python(HS) und Perl schlicht auf die Fresse gefallen bin..
Man muss dazu aber auch immer berücksichtigen, ob 2sek eine Rolle spielen; bei Heizungswerten sicher nicht, wenn man auf "+" drückt und es wird nicht binnen 300ms lauter schon..

[JuMi2006]

Also die Kernfrage war eher: Warum kann ich zwischen Daemon und Plugin über IO::Socket::Inet Daten verschicken ohne eine entsprechende socat-Instanz gestartet zu haben? Oder ist das normal dass das geht? Port und IP sind in beiden Fällen gleich eingetragen.

Auf dem seriellen Port sitzt natürlich nur ein (anderer) Socket (udp datagram).

Wie würde bei Dir ein Socket zwischen einem Daemon und einem Plugin aussehen? Unidirektional sollte ja so gehen?
socat udp-sendto:localhost:50001 udp-recv:localhost:5001,reuseadr
Wie würde ein Datagram aussehen?

Gruß

P.S.: Warnung vor Perl verstanden aber ich habe Angst vor den ganzen Subroutinen und Bitschubsereien in C. Das hab ich in Perl schon nicht gerafft.

[makki]

Geheimtipp : lsof
Sagt wer wo horcht.. Auf einem UDP-Port z.b. (augenommen Broad-/Multicast) horcht sicher immer nur einer.. der letzte..

Du willst dgram, nicht socket, so hats mir der Author von socat mal geschrieben..

Es kommt immer drauf an, blutsuppe ist es so oder so, ich bin zu dem Schluss gekommen das es in manchen Einzelfällen einfacher ist sich diese in C anzutun statt Tage&Wochen in Scriptsprachen zu verweilen - nach vielen Jahren.. Geschmackssache - und vor allem was man kennt und welche Ressourcen man hat..

Makki