Problem bei Verbindung zweier Instanzen mittels FHEM2FHEM

[duke-f]

Mir fällt kein wirklich passender Titel ein, um mein Problem passen zu beschreiben. Vielleicht hat aber trotzdem einen Tipp.

Seit langem habe ich mehrere Rasperry Pi mit je einer Minimalversion von FHEM laufen. Die Hauptinstanz läuft auf einem Cubietruck. An einem der Raspi hangt ein IguanaWork IR-Tranceiver zur Ansteuerung der Hifi- und Videoanlage. Die Verbindung läuft über FHEM2FHEM, die abgesetzten Befehle sind als Systemkommandos über LIRC formuliert und werden auf dem entsprechenden FHEM-Client ausgeführt. Funktioniert seit Jahren praktisch einwandfrei. Jetzt hatte ich aber vor mehreren Wochen das erste Mal und dann diese Woche bereits zweimal das Phänomen, dass das Kommando an das System des Raspi nicht ankam oder nicht weitergegeben wurde. Normalerweise habe ich am Raspi einen Eintrag im Log, dieser fehlte dann jedoch in diesen Fällen. Es gibt absolut keine Anzeichen, dass irgendetwas nicht richtig funktioniert.

In diesen Fällen hatte ich jeweils einfach nur FHEM auf dem Raspi neu gestartet. Danach hat wieder alles funktioniert. Da das ganze nur selten auftritt, kann ich auch nicht viel probieren. Nächstes Mal werde ich versuchen, statt FHEM komplett neu zu starten, nur die FHEM2FHEM-Verbindung mittels reopen neu zu öffnen.

Unten füge ich die betreffenden Teile aus der Definition und dem Logging (in dem Fall, dass es funktioniert - sonst gibt es da einfach nichts) an. Vielleicht hat jemand einen Tipp, oder jemand hat ein ähnliches Problem.

Definition im Raspi

Code Auswählen Erweitern


define amerikaner FHEM2FHEM ip.des.cubie:7072 LOG:panacinema
define DI_Pana DOIF ([panacinema] eq "aus_ein")({system ("irsend send_once Panasonic KEY_POWER")}) \
DOELSEIF ([panacinema] eq "fm")({system ("irsend send_once Panasonic KEY_RADIO KEY_RADIO")}) \
....


Log-Auszug

Code Auswählen Erweitern


2017.09.29 06:57:11 2: DI_Pana: {system ("irsend send_once Panasonic KEY_POWER")}: -1
2017.09.29 06:57:22 2: DI_Pana: {system ("irsend send_once Panasonic KEY_RADIO KEY_RADIO")}: -1


[duke-f]

Nächstes Mal werde ich versuchen, statt FHEM komplett neu zu starten, nur die FHEM2FHEM-Verbindung mittels reopen neu zu öffnen.

Heute hatte ich das "Glück", das probieren zu können. Und tatsächlich hat es gereicht, mittels reopen die Verbindung neu zu öffnen. Da es offensichtlich sonst niemand mit dem Problem gibt bzw. niemand eine Lösung weiß, versuche ich es mal mit einem alltäglichen reopen von FHEM2FHEM per at morgens um 5:00 Uhr auf dem Raspberry.

[Grinsekatze]

Auch ohne Dein eigentliches Problem lösen zu können, kannst du einen Notify bauen, der prüft, ob die gewünschten Vorgänge tatsächlich auch umgesetzt wurden / eine Fehlermeldung produziert wurde. Wenn ja, dann wird ein reopen ausgeführt. Oder, wie Du schon angemerkt hast einen At, der täglich schaltet. ... zumindest ein Workaround.

[Otto123]

Hi,

es gab da schon mal was ähnliches, am Ende war das Netzwerk das Problem
https://forum.fhem.de/index.php?topic=72823.0

Gruß Otto

[duke-f]

Besten Dank.

Beide Ansätze werde ich mal verfolgen. Das Netzwerk hatte ich spontan zwar eher ausgeschlossen, da der Raspberry ja auch per ser2net angebunden ist und diese Verbindung steht. Aber wie gesagt, nachgehen werde ich dem Tipp auf jeden Fall.

Das mit dem notify klingt als bessere Lösung gegenüber dem reopen. Allerdings muss ich mir da dann auch überlegen, wie ich das umsetze. Bisher läuft bei mir FHEM2FHEM in diesem Fall ausschließlich als Einbahnstraße.

[Otto123]

Normalerweise macht FHEM2FHEM das völlig selbstständig. Ich habe mehrere F2F am laufen und hatte bei neustart und Phasen der Trennung der beiden noch nie Probleme. Der reconnect klappt normalerweise immer automatisch.
Schließt nicht aus, dass es doch einmal eine faule Situation gibt...

Wenn das jetzt wiederholt nicht geht, dann ist irgendetwas faul. Da würde ich nicht nach einem Workaround sondern nach dem Fehler suchen. Der Begriff Netzwerk ist auch weit fassbar, das kann sonstwas sein. Dabei geht alles andere. Manche Systeme kommen mit Fehlern zurecht, manche nicht.
Viel Erfolg bei der Suche

Gruß Otto

[duke-f]

Da stimme ich Dir absolut zu. Nur ist es eben so, dass der Fehler nun nach monate- oder jahrelangem problemlosem Betrieb ohne großartige Änderung am Rechner mit FHEM2FHEM in den letzten Wochen mittlerweile gerade 4 Mal dieses Phänomen hatte. Trennungen des Netzes oder Neustart des Raspies haben bisher nie Probleme gemacht, die Verbindung wurde immer wieder neu automatisch aufgebaut. Ist damit etwas schwer zu fassen. Mit verbose 5 jetzt die Log aufzublasen halte ich für wenig sinnvoll. Andere Hinweise in den syslogs, die auf Netzprobleme schließen ließen, finde ich auch nicht.

[Prof. Dr. Peter Henning]

Zwischen 3 verschiedenen FHE-Instanzen habe ich 6 FHEM2FHEM-Verbindungen (jeder mit jedem). Und zwar direkt, ohne LIRC oder so etwas. Nachdem ich die Kurzschlüsse beseitigt habe, problemlos.

LG

pah

[R1F800]

Hallo,
ich habe verucht mir eine Variable von einem entfernten fhem System zu holen.

Zielsystem:
define ESPEasy_Gartenhaus_Aussentemp dummy
define TAussen FHEM2FHEM 192.168.0.11:7072 LOG:ESPEasy_Gartenhaus_Aussentemp

Soweit so gut.
Seitdem ist die FHEM Instanz gähnend lahm und auch der Wert des entfernten Temperaturfühlers wird nicht übertragen.
Habt ihr eine Idee?


Im eventmonitor  erscheint immer connected .... disconnected

[Otto123]

Hi,

mach mal bitte auf der Quellinstanz

Code Auswählen Erweitern

list telnetPort

Gruß Otto

[CoolTux]

Hallo Otto,

Sollte nicht der Telnet auf der Zielinstanz laufen. Immerhin initialisierst Du ja einen telnet Client auf den QuellFHEM und willst Dich auf den ZielFHEM auf Telnet Port verbinden.
Oder meintest Du was anderes?

Grße

[Otto123]

Nein es ist doch so: Auf der Quelle läuft telnetPort und auf dem Ziel verbindet sich die F2F Instanz zu der Quelle.
Die Daten werden von Quelle nach Ziel übertragen.
FHEM2FHEM ist doch der Telnet Client?

Also zumindest ist es bei mir so: schließe ich auf der Quelle den telnetPort ist F2F auf dem Ziel anschließend disconnected.

Ergo will ich prüfen, ob auf der Quelle wirklich telnetPort definiert ist. Ist ja bei neuen System erstmal nicht mehr.

[CoolTux]

Ich glaube wir haben beide Recht. Wir denken Seitenverkehrt.


Die Quelle ist für mich das wo der Telnetprozess initialisiert wird, also am Ende wo ich die Daten haben will. Das Ziel ist von wo ich mir die Daten hole.

Am Ende stimmt beides. Also schau auf das System nach dem Telnet Device wo nicht FHEM2FHEM drauf läuft 

[Otto123]

Naja und Ingo hatte meine Gedankenrichtung ja so angenommen  Er hat auf dem "Ziel" FHEM2FHEM

[duke-f]

Für uns Dummies: Die Telnet-Sichtweise ist also entgegen der Datenrichtung ?!

Vielleicht noch ein Tipp: In solchen Fällen kann schon mal Freezemon der Suche nach Ursache hilfreich sein.