Phänomen verzögerter Datenbereitstellung IR mit RS232-USB(Prolific)

[KölnSolar]

ich versuche ja derzeit 2 Devices zu synchronisieren. Details dazu hier:
https://forum.fhem.de/index.php/topic,50661.0.html

Nun habe ich festgestellt, dass eins der Devices irgendwo in den Tiefen des Systems seine Daten puffert und nicht zeitnah zur Verfügung stellt.

Es handelt sich um einen Infrarotlesekopf mit  RS232-Schnittstelle, der an einem RS232-USB-Adapter mit ftdisioProlific-Chip  und über einen passiven USB-Hub an einem RPi2 angeschlossen ist. Daten werden unaufhörlich gepushed. Das funktioniert nach einem Start/Restart von fhem auch prima.

Nach einiger Zeit kommen die Daten aber nur noch zeitverzögert im XX_Read des Moduls an. Und nicht, dass jemand denkt die Daten wären irgendwie verloren gegangen, nein sie sind tatsächlich einfach nur um mehrere min. zeitverzögert.

Mit einem Restart/Start des Systems oder Modify des device werden scheinbar die gepufferten Daten verworfen und alles funktioniert bestens, bis irgendwann.....

Der Hub ist unverdächtig, weil das 2. zu synchronisierende device ebenfalls angeschlossen ist, per polling selten angefragt wird und zeitnah Daten liefert. Das fhem-Modul konnte ich als Verdächtigen ebenfalls schon ausschließen. Aber wo haben sich die Daten versteckt bzw. was schläft denn da? RS232-USB ? Rpi ? fhem.pl ?

Vielleicht hat ja jemand ne Idee.

Grüße
Markus

[rudolfkoenig]

Nach einiger Zeit kommen die Daten aber nur noch zeitverzögert im XX_Read des Moduls an

Ueblicherweise ist XX_Read das ReadFn des Moduls, was per select benachtichtigt wird. Select sollte sich melden, wenn an dem spezifizierten Filedescriptor Daten bereitstehen. Unter Windows funktioniert select nur fuer Netzwerkverbindungen, deswegen pollt FHEM unter Windows die USB bzw. Serielle schnittstellen. Aber hier reden wir ja von einem RPi, vermutlich mit Linux, also select mit sofortiger Benachrichtigung.

Falls irgendein Modul FHEM blockiert, dann kann das erwaehnte Verhalten auftreten. Das kann man z.Bsp. mit einem at, was alle X Sekunden eine Zeile ins Log schreibt, testen. X sollte deutlich kleiner sein, als die beobachtete Verzoegerung.

[KölnSolar]

Danke für die Rückmeldung. Blockiert ist ja eben nichts in fhem. Sehe ich ja auch im Event-Monitor.

Mal eine Grafik anbei: das "Problemdevice" in blau und das device 2 in pink. Der Zeitverzug Delta t und nach dem modify der def des "Problemdevices" laufen die Daten wieder synchron, bis irgendwann.....

Grüße
Markus

[rudolfkoenig]

modify oeffnet das Geraet neu, und initialisiert es.
Ich vermute weiterhin das Problem im Geraet, und nicht in FHEM. Schau mal mit

Code Auswählen Erweitern

{ join("\n",keys %selectlist) }

ob dein Geraet noch in die Select-Liste eingetragen ist.

[KölnSolar]

ich kann mir auch nicht vorstellen, dass es an fhem liegt, nachdem ich ja das Modul als Übeltäter ausschließen konnte.

Das device ist in der selectlist vorhanden. ich hatte aber auch gerade erst wieder ein modify  gemacht.

Wenn das device nicht mehr in der seleclist wäre, würde XX_Read doch gar nicht mehr aufgerufen, oder ?

Durch das Auflisten der Devices ist mir aufgefallen, dass es kein FTDI-Chip, sondern ein Prolific im RS232-USB-Adapter ist 

Wenn ich mal wieder das Delta feststelle, mache ich noch mal die Auflistung der selectlist und melde mich.

Grüße
Markus

[KölnSolar]

bis dato ist der Zeitverzug nicht wieder aufgetreten
Grüße
Markus

[Icinger]

@rudolf:
Für Markus habe ich extra einen pollingModus eingebaut, da ihm die 5-6% Prozessorleistung, die beim ständigen select()->readIO->verwerfen auftreten, zuviel waren.

Daher hat er automatisch ein paar Sekunden Verzögerung, wenn eben

1) <interval> abgelaufen, also wieder einen Datensatz gelesen werden soll
2) dann erst das nächste polling irgendwann (max. 5 Sekunden später??) auftritt

Zwischen den Intervallen werden die Daten (egal ob per select() oder polling) einfach eingelesen und sofort verworfen.

lg, Stefan

[Muschelpuster]

Ich habe hier gerade Prolific in der Überschrift gesehen und das Thema interessiert gelesen. Ich kann da nicht direkt was beisteuern - aber vielleicht indirekt: Wir arbeiten in der Firma viel mit RS232 (Programmierung diverser Geräte). Im laufe der Zeit haben wir wohl schon endlose Stunden in Prolifc-Fehlersuche investiert. Zwar alles unter Windows, aber die merkwürdigsten Phänomene. An einem System funktioniert die RS232, am Nächsten nicht / gestern ging es, heute nicht etc..
Wir haben auch schon Adapter diverser Hersteller bestellt, aber in den Meisten ist dann wieder Prolific drin. Es gibt aber 2 Chipsets, der teurer ist durchaus besser. Ich glaube, wenn man die Dinger von Lindy kauft darf man nicht die mit dem braunen Stecker für etwas über 10-€ kaufen sondern muss die Roten für über 20,-€ nehmen.
Inzwischen habe ich eine PCIexpress-Karte mit RS232 in meinem Notebook und keine Probleme mehr. Dumm nur, dass die inzwischen auch nicht mehr hergestellt wird und so keine Lösung für alle Kollegen ist.

leidgeprüfte Grüße
Niels

[KölnSolar]

@Stefan: es geht hier aber um Minuten und nicht evtl. die paar modulbedingten Sekunden. Das Verhalten ist tatsächlich so, dass ich Daten zeitnah von OBIS bereitgestellt bekomme. Die sind aber leider schon min. alt. Ich hatte ja sogar extra den Buffer von OBIS gelogged und konnte somit das Modul als Ursache ausschließen.

@Niels: Danke für die Info. Das bekräftigt doch zumindest die Theorie, dass die Ursache USB-Hardwarebedingt und fern des fhem's sein könnte.

ich halte es im Auge und werde berichten

Grüße
Markus

[Icinger]

Markus, das war mir schon klar, dass du von Minuten gesprochen hattest.

Wollte das nur nochmal erwähnen, da Rudi ja von Pi und somit automatisch von select() ausging.

[KölnSolar]

wollte nur vermeiden, dass jemand, der nicht so tief in der Thematik versunken ist, das Problem als mit Deiner Aussage gelöst ansieht. 

Ich hab jetzt nochmal extra nachgeguckt. Das Bild/Plot aus meinem Post #2 zeigt einen Versatz von NEUN min. Das ist doch irre. Fehlende oder falsche Daten würd ich ja noch verstehen, aber so einen zeitlichen Versatz ?

Grüße
Markus