Absturz von FHEM bei Disconnect zu remote eingebundenem TUL

[CQuadrat]

Hallo Zusammen,

ich bin gerade dabei, mein FHEM auf einen anderen Server zu migrieren. Dazu habe ich als erstes begonnen, die Hardware umzuziehen.

Dies beeinhaltet auch meinen TUL-Stick, mit dem ich per eibd diverse KNX-Geräte angebunden habe.

Der TUL steckte  ursprünglich am FHEM-Rechner und war mit

Code Auswählen Erweitern


define EIB_TUL TUL eibd:localhost 1.1.255

eingebunden. Auf dem FHEM-Rechner lief ebenfalls noch der eibd. Das ganze funktionierte ohne Probleme.

Nun habe ich den TUL-Stick an den zukünftigen FHEM-Rechner (192.168.2.10) angeschlossen; dort läuft nun der eibd. Der TUL ist am bisherigen FHEM nun mit

Code Auswählen Erweitern


define EIB_TUL TUL eibd:192.168.2.10 1.1.255

im FHEM eingebunden. Das ganze funktioniert nun im Prinzip auch so wie vorher.


Nur:
Fährt der Rechner 192.168.2.10 runter (bzw. verliere ich die Verbindung zu 192.168.2.10) stürzt mir mein FHEM komplett ab. Das letzte was ich im Log sehe, ist:

Code Auswählen Erweitern


2015.07.05 00:39:47.384 1: CallBlockingFn: Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt



Hat hier jemand schon mal etwas Ähnliches beobachtet oder kennt jemand eine Lösung des Problems?


Danke und Gruß

Christoph

[Andi291]

Hallo,

Jupp, hatte ich auch schon mal. Bei mir war das Problem dass zeitweise mehrere Rechner auf den EIBD zugegriffen haben - per IP geht das aber nicht. Habe dann umgestellt auf "IPT" und multicast. Seitdem läufts störungsfrei...
Was Du schreibst kann aber auch drauf hindeuten, dass der eibd noch nicht rund läuft. Wie geht's denn, wenn Du per Hand eibd und fhem startest? Oder Du ein Delay einbaust?

Grüße, Andi

P.S.: welche Zielplattform?

[smurfix]

Seit wann sollen mehrfache Verbindungen per ip: nicht funktionieren? Klar geht das.
Außerdem funktioniert bei @Cquadrat doch an sich alles, erst wenn der Daemon stoppt gibt es ein Problem im FHEM. Hat also mit der eibd-Konfiguration nix zu tun.

[Andi291]

Hallo zusammen,

ich wiederhole mich gerne - bei mir ist die Konfiguration von IP mit mehreren Teilnehmern nicht möglich gewesen. Deshalb hab ich auf IPT umgestellt. Seither ohne Probleme.

Ohne, dass ich die unteren Schichten genau kenne, scheint IPT bei Verbindungsverlusten Fehlertoleranter. Der Slave scheint nicht so empfindlich auf den Serverstatus zu reagieren. Jedenfalls kommt bei meinem System immer ein "send request", egal ob der EIBD-Server läuft, oder nicht.
Eventuell kann das bei diesem Problem ja helfen.

Dass es das nicht muss - ist mir klar.

Grüße, Andi

[CQuadrat]

Hallo Zusammen,

vielen Dank schon mal für die rege Diskussion.

@Alle: Ich kann mit mehreren Rechnen gleichzeitig ohne Probleme auf den TUL am Rechner 192.168.2.10 zugreifen. Das habe ich getestet mit einen zusätzlichen Windows-Rechner, auf dem die ETS läuft. Fazit: ETS (auf Rechner 1) und FHEM (auf Rechner 2) geht gleichzeitig ohne Probleme.

@Andi291: Was meinst du mit Umstellung auf IPT? Heißt das, dass ich auf dem FHEM-Rechner ebenfalls noch einen eibd laufen lasse, der dann per IPT auf den eipd des TUL-Servers (192.168.2.10) zugreift, um dann wiederum auf dem FHEM-Rechner auf den TUL per localhost zuzugreifen?


Viele Grüße

Christoph

[Andi291]

Hallo Christoph,

steht im Prinzip hier drin:

http://wiki.linuxmce.org/index.php/EIB/KNX_with_eibd

Hier meine Parameter:
eibd -e 1.1.241 -c -S -D -i -T -u --daemon=/var/InternerSpeicher/fhem/log/eibd.log --pid-file=/var/run/eibd.pid ip:224.0.23.12

Damit nutzt Du dann die Multicast-Adresse. In meinem System ist diese deutlich robuster...

Grüße, Andi

[CQuadrat]

Hallo Andi,

ich glaube, das wird so bei mir nicht funktionieren: ich habe ja einen TUL-Stick, der am USB-Port hängt.

Da der Server ja stabil läuft und FHEM sowieso auf diesen Server umziehen wird, werde ich wohl erstmal damit leben.

Notfalls greifen die Watchdogs. 


Danke und Gruß

Christoph

[erwin]

Hi CQuadrat,

2015.07.05 00:39:47.384 1: CallBlockingFn: Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt

ist jedenfalls verdächtig, weder das 00_TUL.pm noch das 10_EIB.pm Modul verwenden CallBlockingFn. Die Meldung könnte allerdings von einem beliebigen Modul kommen (das CallBlocking und damit einen separaten Prozess verwendet), nach dem der Haupt-FHEM prozess bereits abgestürzt ist. Was uns jetzt nicht wirklich weiter hilft.
Bevors wissenschaftlich wird: Was passiert, wenn du den EIBD prozess am remote rechner killst und nicht die ganze 192.168.2.10 Maschine?
l.g. erwin

[CQuadrat]

Was passiert, wenn du den EIBD prozess am remote rechner killst und nicht die ganze 192.168.2.10 Maschine?

Vielleicht jetzt etwas spät geantwortet: 
Das macht keinen Unterschied. In beiden Fällen stürzt FHEM ab.

[JoeALLb]

ist durch das neue Update auch behoben, oder?

[Andi291]

Nein, wahrscheinlich nicht. Der Fix aus dem anderen Thread bezieht sich nur auf das fehlende Error-Label.

[JoeALLb]

Also meiner ist heute bei einem ähnlichen test nicht hängen geblieben, wie früher schon mal. Daher kam meine Vermutung.....

[CQuadrat]

Ich kann es so richtig leider nicht mehr testen, da mein FHEM nun auch auf diesen Server umgezogen ist. (FHEM und eibd laufen jetzt wieder auf dem gleichen Rechner).

Update habe ich wegen Zeitmangel noch nicht durchgeführt. Vielleicht am nächsten Wochenende.