...ich verwende zwei fhem Installationen. Die Master Instanz ist auf der FritzBox (7390) und die Slave Instanz auf nem RPi.
Um Daten zwischen den beiden austauschen zu können, hatte ich in der Vergangenheit einfach Kommandos per NC den jeweiligen Telnet Port der anderen Instanz gesendet. Dies führte immer wieder mal zu Problemen (Shells wurden nicht geschlossen).
Letzte Woche hab ich dann mal aufgeräumt und FHEM2FHEM im LOG Mode für jeweils eine Variable auf beiden Instanzen installiert.
Funktioniert prächtig!!
Nur ein Problem: zeitgleich hab ich auch ein fhem Update gemacht, und seit dem macht meine FB gelegentlich nachts einen reboot.
Da ich keinen Anhaltspunkt habe warum und wieso, muss ich da noch weiter forschen.
Was mir aber aufgefallen ist: hat die FB einen Reboot hingelegt, bekommt FHEM2FHEM auf dem RPi nichts mehr mit. Ich muss fhem auf dem RPi erst neu starten, dann funktioniert es wieder.
Eigentlich würde ich erwarten, das im Log des RPi eine Meldung "disconnected/reappeared" auftaucht (denn das sehe ich im Log der FB, wenn ich fhem auf dem RPi neu starte), daher meine Vermutung, das hier etwas klemmt.
Der Status von fhem2fhem wird mit "connected" reported, aber das ist offensichtlich nicht korrekt.
Hat sonst noch jemand das Problem??
VG
Ralf
Falls die FB stromlos gemacht wird, dann hat sie keine Chance dem RPi zu sagen, dass sie weg ist. TCP/IP Keep-Alive Pakete werden erst nach 2 Stunden gesendet (http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html) danach muesste ein disconnected kommen. Diesen Intervall kannst du auf dem RPi-FHEM auch mit einem watchdog verkuerzen.
Danke für die prompte Antwort, Rudi! Das mit keepalive sieht interessant aus, ist aber eventuell keine Lösung für mich.
Nur um das Problem noch mal etwas deutlicher zu beschreiben:
In den letzten Tagen ist meine FB zwei mal nachts ausgestiegen. Heute war es um 02:04 soweit.
Nach dem starten läuft die FB dann wieder normal weiter, aber die FHEM2FHEM Verbindung vom RPi zur FB ist "taub".
Alles sieht so aus, als würde es normal arbeiten, aber wenn ich einen Event an der FB generiere, sieht ihn der RPi erst wieder, wenn ich manuell fhem neu starte. Der RPi scheint die FHEM2FHEM Verbindung nicht mehr zu sehen.
Ich meine das Problem verstanden zu heban, und verstehe noch nicht wieso Du der Ansicht bist, dass meine Theorie nicht zutrifft.
...du schriebest, das ein disconnect spätestens nach zwei Stunden kommen müsse. Das passiert aber nicht.
Auch 5 Stunden nach dem reboot der FB steht im FHEM2FHEM Status des RPi "connected", aber es kommt nichts mehr an.
VG
Ralf
Sorry, du hast recht. Im verlinkten Dokument steht ja auch:
ZitatPrograms must request keepalive control for their sockets using the setsockopt interface.
Und das habe ich nicht gemacht...
Waere das eine Loesung fuer dich, oder moechtest du es lieber in FHEM via watchdog steuern?
Danke abermals Rudi!
Mir würde eine Lösung in fhem völlig reichen (fände ich eigentlich sogar charmant). Aber ich habe keine genaue Vorstellung, wie ich mit watchdog FHEM2FHEM überwachen könnte.
Vielleicht kannst du mir noch mit nem Tipp auf die Sprünge helfen?
Auf der FritzBox sieht die Definition so aus:
define fhem_Backup FHEM2FHEM 192.168.1.18:7072 LOG:Heizung_Current_Mode.*|vc_Brauchwassertemp.*
Und auf dem RPi so:
define fhem_Master FHEM2FHEM 192.168.1.1:7072 LOG:Heizung_Set_Mode.*
...die beteiligten Variablen sind vom Typ Dummy und werden nur in sehr unregelmässigen Abständen upgedated.
FHEM2FHEM auf der FB sollte ja keine Probleme haben.
Zitat...die beteiligten Variablen sind vom Typ Dummy und werden nur in sehr unregelmässigen Abständen upgedated.
Das ist ein Problem fuer den Watchdog, d.h. ich wuerde auf der FB ein zweites dummy regelmaessig updaten (per at):
define dummyNeu dummy
define dummyNeu_at at +*00:03 set dummy aktuell
und dessen Zustand mit der gleichen FHEM2FHEM auch zum RPi uebertragen. Auf der RPi kommt dann noch der watchdog:
define fhem_Master FHEM2FHEM 192.168.1.1:7072 LOG:(Heizung_Set_Mode|dummyNeu).*
define wd_f2f watchdog dummyNeu 00:05 SAME modify fhem_Master 192.168.1.1:7072 LOG:(Heizung_Set_Mode|dummyNeu).*;; trigger wd_f2f .modfiy loest beim FHEM2FHEM ein reconnect aus.
Sauber! Vielen Dank für deine Mühe, Rudi. Hab ich genau so implementiert. :-)
VG
Ralf
Moin,
da ich im Grunde exakt das gleiche Problem habe (FHEM2FHEM via OpenVPN und einer rel. instabilen Mobilfunkstrecke), suche ich hier auch schon seit einiger Zeit nach einer Lösung.
Auf "modify" bin ich nicht gekommen. Vlt. ließe sich für FHEM2FHEM ein "reconnect" implementieren?
In meiner Verzweilung hatte ich manuell ein "rereadcfg" ausgeführt. Das half auch ;)
Jetzt noch zwei Fragen:
Ließe sich statt des dummys nicht auch ein anderes Device per watchdog überwachen, dessen Daten eh schon über FHEM2FHEM übertragen werden?
Was geschieht, wenn sich der Status des Dummy-Devices mal ändert? Also statt "aktuell", warum auch immer mal ein andere Wert gesetzt ist? (Ich glaube ich brauche watchdog-Nachhilfe)
Den zusätzlichen Dummy hat Rudi nur vorgeschlagen, da meine bislang übertragenen Daten nur sehr unregelmässig upgedated werden.
Daher sollte es auch mit deinen vorhandenen gehen, wenn die in passenden Abständen ein update erfahren.
VG
Ralf