[wiregate] Perl Daemon schreiben ?

[JuMi2006]

Ich würde für mein aktuelles "eBus-Projekt" gern einen Perl Daemon schreiben der mir ständig und im Hintergrund die eBus-Telegramme liest, filtert und dann für das Wiregate-Plugin bereitstellt.

Hintergrund:
Die Telegramme auf dem eBus kommen im Schnitt mindestens 1-2 mal pro Sekunde. Damit ist ein normales Plugin ja dauerbesetzt. Da die Socketverbindung steht, könnte der Daemon ja darauf zugreifen. Jetzt würde ich im eigentlichen Plugin alle 5 Minuten, oder nach Anforderung, die Telegramme auswerten. Das schein mit die sauberste Lösung.

Eignet sich FIFO dafür oder gibt es einen eleganteren/einfacheren Weg?
Schön wäre es wenn man auf die gesammelten Telegramme quasi sofort aus dem Wiregate-Plugin zugreifen kann.

Das ganze eBus-Projekt würde dann im Zweifel ein Wiregate-Plugin, ein Perl-Modul und den Daemon beinhalten und so hoffentlich eine bidirektionale Verbindung von KNX und eBus ermöglichen.

Danke und Gruß Mirko

[makki]

Wenns wirklich um timing geht, ist weder Perl noch Python noch PHP eine Option..
Das ist aber meistens nicht der Fall, sowas geht mit einem Plugin (socat->UDP->Plugin) ganz wunderbar auch hier & heute. Genau dafür sind die Plugins ursprünglich gemacht worden (nicht als Logik-Engine..)

Wenns genauer sein muss, würd ich eher zu C(++) greifen

Makki

[JuMi2006]

Ich komme mit dem Plugin aber leider nicht weiter:

Liest 100 Zeichen ein, das Plugin läuft dann aber auch immer solange bis die 100 Zeichen da sind:

if ($fh) {
 my $buf;
 read($fh,$buf,100)

Liest immer nur ein paar Zeichen ein (keine 24), das Plugin läuft damit aber eben (teilweise mehrmals) jede Sekunde:

if ($fh) {
 my $buf;
 recv($fh,$buf,24,0);

Wo soll ich dem socat denn sagen dass er mir bitte immer wenigstens 1000 bytes senden soll ?

Ich würde das schon gerne nur im Plugin lösen.

[JuMi2006]

Damit kann ich schonmal "nur auf Nachfrage" empfangen ... gerade eingebaut um für das Senden auf den eBus das SYNC Zeichen abzuwarten (Also immer nur 1Byte lesen und auswerten). Jetzt wird jeder Befehl zu 99% auch von der Heizung empfangen.

my $buf;
recv($socket[$socknum],$buf,1);

Wenn ich es richtig verstanden habe dann ist read das Lesen aus dem Buffer des Sockets, geht also, sofern so viele Zeichen im Puffer vorhanden sind recht schnell.
Dagegen liest recv "heiß" vom Socket und dann eben nur so viele Zeichen wie gerade reindröseln ?

Für ein SYNC-Zeichen wäre also ein recv eher zu verwenden als ein read ?

Für das regelmäßige Auslesen (gepufferter Daten) wäre jetzt aber das read sinniger ?

Bei der Annahme dass der Buffer des Sockets auf 8kbyte (oder 4kbyte?) begrenzt ist (Stimmt das?). Wie bekommt man jetzt den Spagat hin dass:
1. Zwischen zwei Leseintervallen genug Daten vorhanden sind um ein Warten des Plugins auf neue Daten zu vermeiden.
2. Zwischen zwei (evtl. zu langen) Leseintervallen Daten aus dem Buffer geschmissen werden (max. Buffergröße).

Hab ich das jetzt halbwegs verstanden ?

Gruß Mirko

[makki]

Soweit richtig..
recv ist insofern gefährlich, weil es blockieren kann wenn nichts kommt!

Dem socat kann man das Stand heute nicht beibringen, es hilft nur

if ($fh) # Plugin wurde wegen anliegender Daten (select()) gestartet
{
# byteweise lesen
# Rest bei Telegrammende merken
# usw.
}

Was aber schon viel hilft ist die Option
,icanon=1
bei der seriellen Seite des socat, dann kommen die Daten erheblich geordneter.
Zweite Variante:
,eol=XX

sofern es einen Datensatztrenner gibt.
Da muss man aber leider immer etwas rumprobieren, bis das rund geht.

-> Ich hab vorhin nen neuen socat ins Repository geschoben (1x Update), der 1.6er hatte da wie mir gestern auffiel noch einen hässlichen Bug mit UDP-Datagram.

Makki

[JuMi2006]

o.k. das bringt Licht ins dunkel, in meinem Fall nach kurzem Test aber wohl doch unbrauchbar.

Der Datensatztrenner wird wie übergeben? 0xAA / AA / 170 ???

Würde socat bei bei einem funktionierendem EOL auch wirklich bis zum EOL warten und dann linewise senden? Oder ist das dann doch eher Glückssache?

Was kann eigentlich ein plugin_info an Daten ab ? Das würde sich ja zum merken gut eignen.

[makki]

a) 170, also dezimal angeben
b) Jein, es bleibt 50% glücks-sache (ich habe erst gestern meine AQ-computer von der toten Moxa umgestellt und geflucht wie ein Rohrspatz.. ein Serial-to-UDP Daemon liegt in der Luft, aber eigentlich keine Zeit..)
c) In Plugin_info kann man alles speichern, Zeichen auf jeden Fall, für komplexe Datentypen liegt ein Beispiel im SVN..

Makki

[JuMi2006]

Ich meinte da eher an Größe ?
rechne ich mal 500 Telegramme mit jeweils 10 Bytes sind das 5kB ... machbar?

[makki]

Kein Problem..

Makki

[JuMi2006]

Ich komme einfach auf keinen grünen Zweig mit dem Empfang vom Socket. Das Plugin ist mittlerweile so weit dass ich es gern produktiv testen würde aber das Auslesen des eBus/Socket vertrödelt entweder zu viel Zeit bzw. verliert Telegramme (read) oder blockiert quasi als Dauerschleife mit Telegrammhäppchen (read).
Mit einem if($fh) ist das Plugin auch dauerbesetzt. Zeit für Multi-Thread .
Außer einem Auslagern in ein externes Script mit minütlich aktualisierender Datendatei fällt mir grad nichts ein.

[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

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

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]

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]

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