TUL reinitialisieren nach Busspannungsausfall

Begonnen von eburkon, 28 April 2014, 08:16:09

Vorheriges Thema - Nächstes Thema

eburkon

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
FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT

NehCoy

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

eburkon

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
FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT

NehCoy

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 und hier nachlesen.

Grüße
NehCoy

eburkon

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
FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT

NehCoy

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

eburkon

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




FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT

NehCoy

Warum werden die Daten eigentlich gepollt?
Können die nicht einfach vom TUL an den Pi weitergeleitet werden?


eburkon

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
FHEM auf Rpi48G, KNX via knxd und IP Interface, Hue, FS20, und ein paare externe Sachen via MQTT