Perl Daemon schreiben ?

[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

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

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

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

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

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]

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]

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

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

[makki]

Für read ist im Plugin ebenfalls keine Zeit und kein Platz (höchstens select - siehe wiregated.pl - wenns echt schnell ist), weil das überschneidet sich sonst..
Weil der Witz ist ja, das das Plugin nur anrennt wenn Daten da sind.

Entweder
- Plugin, $fh
- Plugin - Rest komplett selber (select, read/recv, ..)
ohne plugin_socket_subscribe
- komplett separat
Mischen macht wenig Sinn, weil da komm ich auch gedanklich in den Wald, wer wo jetzt welche Daten bekommt wird dann zum Zufall..

Makki

[JuMi2006]

Das mit recv ist mir schon klar...hab ich nach langem Rätseln warum plötzlich nichts mehr geht auch verstanden
Socket tot = alles tot

Eigentlich meinte ich ein read($socket,$buf,gib mir alles was du hast) mit einem kombinierten jetzt mach den Buffer leer.

[makki]

Nochmal: recv ist der falsche Weg!
Die verfügbaren Daten stehen beim Aufruf (durch socket_subscribe) bereits in $fh, recv empfängt neue Daten, also solche die nach $fh empfangen wurden..

1) /tmp ist ein guter Ort (Ramdisk), aber wenn willste einen Socket, keine Datei glaube ich..

2) nein/jein. Mal flapsig: er sendet was er hat, wenn er dazu lustig ist. Den Rest muss man hintendran zusammensortieren.

Makki

[JuMi2006]

1. Bevor ich noch Jahre damit verbummele würde ich das mal mit ner temporären Datei angehen. Nach /tmp legen ?

2.Oder anders, gibt es eine Möglichkeit den ganzen Buffer des socat auf einmal auszulesen, also ohne eine Anzahl von Zeichen vorzugeben?

3.Woran liegt es dass bei einem recv($socket,$buf,256,0) gar nicht auf 256 Zeichen gewartet wird sonder schon nach 2-8 Zeichen, manchmal mehr, das Plugin weiter abgearbeitet wird.

[makki]

Zeit für Multi-Thread .

Kommt Zeit kommt Rat, ich bin im dritten Anlauf guter Dinge
Ich darf verraten: Es wurde darüber eine Diplomarbeit geschrieben, aber da fehlen noch ein paar Sachen bis das 100% Ersatz ist.

Außer einem Auslagern in ein externes Script mit minütlich aktualisierender Datendatei fällt mir grad nichts ein.

Nun, das ist eine erlaubte (und manchmal einfach sinnvollere) Lösung. Bei manchem, denke grade an die Russound - da hab ich zwei Jahre am HS-Baustein rumgefrickelt, war immer zu langsam (wenn man auf der FB auf + drückt muss es einfach in <300ms lauter werden..), dann als Perl (Plugin wäre eh zu langsam, vorher klar) und dann halt mal auf den Hosenboden gesetzt und neu in C geschrieben, weil das Thema zu zeitkritisch ist..

Ich darf zu meiner Verteidigung anführen das das Designziel der WG-Plugins initial in etwa war:
- PI-RTR für Chris
- bisschen WP, Lüfter und so abfragen..

Direktes fummeln am seriellen Port, Timingkritisch, ... = Problem..

Makki