FHEM Absturz bei instabiler Verbindung?

[unimatrix]

Hi,

habe seitdem ich nun seit einer guten Woche den RFXTRX433 habe doch noch ein anderes Problem mit meiner FHEM Installation. Ich habe den Rfx nicht direkt an dem Rechner per USB, auf dem FHEM läuft (denn das ist mein Server im Dachgeschoss, und das wäre sehr schlecht wegen der Funkreichweite. Ich habe ihn an einem Raspberri Pi (habe auch schon eine Dockstar ausprobiert, gleiches Problem) im Erdgeschoss laufen, und dort nutze ich dann ser2net um die serielle Verbindung über TCP/IP auf den Server zu bringen (das Define sieht dann so aus: "define MyTRX TRX myPi:12345".

Funktioniert auch soweit. Aber: Sobald ich den RFXTRX433 abziehe, stürzt FHEM entweder ganz ab (Task stirbt) oder friert ein und ist nicht mehr ansprechbar (auch keine Logeinträge mehr). Natürlich ziehe ich ihn normalerweise nicht ab, aber es kommt bei mir offenbar ca. einmal täglich vor, dass es auch so zu einem sehr kurzen Verbindungsabbruch kommt (liegt möglicherweise am ser2net) und auch dann ist morgens mein FHEM immer nicht mehr da. (was natürlich katastrophale Auswirkungen auf mein Eheleben hat wenn das Badezimmer kalt bleibt...)

Den CUL betreibe ich an einem anderen Raum an einer Dockstar nach dem gleichen Prinzip und da gibt es dieses Problem nicht. Im Log kommt es schonmal zu einem Disconnect und sofort wieder zu einem Reconnect aber es bleibt alles stabil.

Daher vermute ich dass das RFX Modul irgendwie mit diesem Problem nicht richtig umgeht. Es wäre wünschenswert, wenn das TRX-Modul dann einfach in einen Status "disconnected" oder so gehen könnte und regelmäßig versuchen würde, die Verbindung wieder herzustellen. K.a. ob es das eigentlich auch versucht, aber bei mir klappt das nicht.

Bin ich der einzige?

Danke und VG!

[unimatrix]

Hi,

hab jetzt mal manuell nachgeholfen. Also 3 Versuche, Abziehen vom RFX, und jedesmal stürzt FHEM komplett ab.

Habe mal FHEM direkt gestertet so dass ich stderr auf dem Bildschirm sehe. Das hier scheint die Ursache zu sein:

Can't call method "status" on an undefined value at /usr/share/fhem/FHEM/45_TRX.pm line 400.

Die letzte Logmeldung (verbose 5) ist

2013.10.05 14:57:56 1: pi1:27073 disconnected, waiting to reappear
2013.10.05 14:57:56 5: Triggering MyTRX (1 changes)
2013.10.05 14:57:56 5: Notify loop for MyTRX DISCONNECTED
2013.10.05 14:57:56 1: pi1:27073 reappeared (MyTRX)

[Willi]

Ich habe keinerlei Probleme beim Abziehen des RFXtrx433, wenn RFXtrx433 direkt angeschlossen ist und auch nicht per FHEM2FHEM raw verbunden. Per TCP setze ich die Module nicht ein.

Die Anbindung per TCP hat vermutlich außer Dir niemand im Einsatz, da es den RFXtrx433 nicht mit Ethernet-Schnittstelle gibt. TCP ist also ungetestet.

Da ich es nicht testen kann, haben wir jetzt zwei Möglichkeiten. Du probiert verschiedene Patches bis wir erfolgreich sind. Oder ich dokumentiere in commandref, dass die Module kein TCP unterstützen ;-)

Bei Gelegenheit werde ich mal vergleichen, wo bei der Ansteuerung mittels TCP die Unterschiede zwischen 00_CUL.pm und meinem 45_TRX.pm sind. Zur Zeit ist leider meine Zeit sehr beschränkt.

Auf Basis Deiner Fehlermeldung, könntest Du folgendes probieren.

Versuche die in 45_TRX.pm (ab Zeile 391 ) das Unterprogramm TRX_Ready( gegen folgendes zu ersetzen (analog zu CUL) und berichte, ob dies etwas bringt:

Code Auswählen Erweitern

TRX_Ready($)
{
  my ($hash) = @_;

  return DevIo_OpenDev($hash, 1, "TRX_DoInit")
                if($hash->{STATE} eq "disconnected");

  # This is relevant for windows/USB only
  my $po = $hash->{USBDev};
  my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags);
  if($po) {
    ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
  }
  return ($InBytes>0);
}


Wenn es nicht funktioniert, bitte mitteilen, was im Log angezeigt wird.

MfG Willi

[unimatrix]

Hallo Willy,

ich erwarte nicht, dass du nur für mich irgendwas reparierst. Ich werde sonst auch eine andere Lösung finden, z.B. fhem2fhem (nie mit beschäftigt). Wollte aber auf einen möglichen Bug hinweisen. Um genau zu sein erwarte ich gar nix :) ich freue mich dass sich so viele Leute hier einbringen in Ihrer Freizeit usw...ich weiß das sehr zu schätzen!


Gerne helfe ich beim testen (bin heute tagsüber allerdings unterwegs).

Deine Änderung führt dazu dass FHEM nun nicht mehr abstürzt (sich also der Task beendet wegen dem Fehler) sondern dass es einfriert und nicht mehr ansprechbar ist und keine Meldungen mehr ins Log schreibt. Das Ende vom Log sieht dann so aus:

Code Auswählen Erweitern


2013.10.06 08:22:24 1: pi1:27073 disconnected, waiting to reappear
2013.10.06 08:22:24 5: Triggering MyTRX (1 changes)
2013.10.06 08:22:24 5: Notify loop for MyTRX DISCONNECTED
2013.10.06 08:22:24 1: pi1:27073 reappeared (MyTRX)
2013.10.06 08:22:24 5: SW:


Wenn ich heute Abend vll mehr Zeit habe kann ich auch versuchen das iwie zu debuggen aber bisher habe ich mich in die Funktionsweise des Moduls noch nicht eingearbeitet.

Bis nachher vll!

[unimatrix]

kleines Update: Seit Sonntagmorgen kam kein weiterer Absturz. Kann im Moment nicht nachvollziehen ob FHEM zwischendrin mal für ein paar Minuten "einfriert" und sich dann irgendiwie wieder davon befreit. Bin gerade im Ausland, aber ich kann mich noch auf FHEM verbinden und auch Daten von Thermostaten usw. sind in die Logfiles geschrieben worden.

Also vll ja doch gelöst! ich werde weiter beobachten

vg

[unimatrix]

nach wie vor kein Absturz und ich kann auch keine Aussetzer mehr erkennen.

@Willy - du hast es gelöst!

Danke

[Willi]

@unimatrix: Danke. Dann werde ich den Patch weiter testen und dann einchecken. Bei mir scheint das Reconnect damit nicht mehr zu funktionieren.

Ich werde in den nächsten Tagen das Forum nicht mehr täglich lesen. Leider funktioniert RSS bei mir nicht mehr wie vorher. Schriftgröße/Schrifttyp und Hintergrundfarbe machen es für mich schwer die Beiträge zu lesen.

Daher bitte ab sofort wichtige Anfragen und Kommentare per PM.

-- Willi