Hallo Miteinander,
ich habe KNX-BUS an FHEM mit dem TUL angebunden.
Es scheint so als würde FHEM oder das TUL Modul sich nach einem
Busspannungsabfall aufhängen, oder es braucht zumindest sehr viele
Ressourcen, so dass FHEM nicht mehr reagiert. Das OS (Debian auf Beaglebone Black)
Reagiert noch.
Aktuell muss ich den FHEM Server neu starten um das in den Griff zu bekommen.
Sieht jemand eine andere Möglichkeit?
Oder hat jemand eine Idee wie man das zumindest automatisieren könnte?
Danke & Gruss
Ekkehard
Hallo Ekkehard!
Ui, dieses Phänomen kenne ich nur zu gut!
Schau dir mal meine Beiträge dazu an:
* http://forum.fhem.de/index.php/topic,19376.0.html
* http://forum.fhem.de/index.php/topic,19524.0.html
Viele Grüße
NehCoy
Servus,
Ich glaube nicht dass es an der Spannungsversorgung liegt.
Erstens scheint der Beaglebone Black bzgl. Der Spannungsversorgung
Nicht so empfindlich zu sein, wie es der Rapi ist, und zweitens hängt der Tul
Schon an einem externen usb hub.
Wenn die Busspannung ausfaellt verschwinded das Device. Nach Busspannungswiederkehr
Kommt zwar das Device wieder. Aber Fhem scheint das nicht zu erkennen und haengt vermutlich in
Einem loop um irgendwas zu lesen oder zu schreiben.
Gruss
Ekkehard
Hallo Ekkehard,
das die (KNX-)Busspannung die Ursache für das Auffängen den TUL und somit von FHEM ist ein interessanter neuer Ansatz.
Nur erstaunlich, dass diese nicht Stabil sein soll.
Dennoch: Den Gedanken eine Funktion zu schreiben, die das "aufhängen" erkennt und den TUL reinitialisiert, hatte ich auch schon.
Nur kann ich kein Perl um FHEM um eine solche Funktion zu ergänzen.
Die Antworten auf meinen Vorschalg kannst du hier (http://forum.fhem.de/index.php/topic,19376.msg130809.html#msg130809) und hie (http://forum.fhem.de/index.php/topic,19376.msg130811.html#msg130811)r nachlesen.
Grüße
NehCoy
Also das mit der Abfallenden Busspannung ist fakt. Das passiert nur wenn ich den FI an dem der BUS
mit hängt fliegen lasse.
Der Beaglebone hängt hinter einer USV und kann das ab.
Gruss
Ekkehard
Okay. Das ist dann die harte Testvariante.
Wenn ich das auf mich widerspiegeln möchte, muss ich von einer temporären "Störung" der Busspannung ausgehen, was auch immer die Ursache dafür sein möge.
Also wenn ich Perl könnte, würde ich so vorgehen:
- FHEM-Architektur analysieren
- Identifizieren "wo" FHEM sich "wie" aufhängt.
- Main-Loop genauer anschauen
- Anhand der Erkenntnisse von "2" Timeouts oder andere zum "abfangen" des ungültigen Betriebszustandes einfügen
Ein Close auf die TTY-Schnittstelle machen. Gefolgt von einem Open mit Prüfung ob erfolgreich
- Testen und so lange optimieren bis alles geht.
- Code, um Logging Einträge /Events in FHEM zu tätigen, ergänzen
Soweit die Theorie...
Gruß
NehCoy
Ich kann zwar leidlich perl aber in anderer Leute Code rumpfuschen
ist halt doch etwas mühsam und dann muss die Änderung auch wieder vom Maintainer
des Codes berücksichtigt werden.
Ich hab mal einen Blick auf den Code geworfen und muss eingestehen, dass ich noch nicht mal kapiere
wie das event handling passiert.
Was ich vermute, das passiert, ist dass FHEM nicht mitbekommt dass das Device weg ist
und dann beim Versuch den KNX-Bus auf ankommende Daten zu überprüfen einfach hängen bleibt.
Gruss
Ekkehard
Warum werden die Daten eigentlich gepollt?
Können die nicht einfach vom TUL an den Pi weitergeleitet werden?
Das er pollt oder so ist nur eine Annahme von mir.
Aber irgendwie muss ja FHEM eventuell vom BUS kommende Daten abholen.
Das kann natuerlich auch eine Interruptsteuerung sein.
Aber genau weil ich das alles nicht weiss hatte ich gehofft dass ich hier im
Forum den Maintainer des Codes finden könnte.
Wobei ich eben nicht mal weiss wer das ist. Im Code steht Rudolf König drin
ich meine mich aberr zu erinnern, dass das EIB/KNX Modul zumindest zeitweise
von jemand Anderem betreut wurde.
Gruss
Ekkehard