[Gelöst] FHEM2FHEM stockt nach shutdown

[manne44]

Hallo,
ich habe mir eine super funktionierende Presence-Anwendung mit einem Gtag über Bluetooth gebaut, die auch zuverlässig funktioniert. Handy-Ping ging gar nicht, GPS-Lokalisation war nicht immer zuverlässig.
Für die Bluetooth-Überwachung habe ich einen alten Raspberry mit Bluetooth-Stick an eine Garagenwand angebracht und der Gtag liegt im Auto. Nur wenn ich mit dem Auto weg bin (anders kommt man hier auch nicht weg) sollen dann alle away-Aktionen ablaufen. Funktioniert sehr gut.
Problematisch ist aber die Verbindung zum BananaPI, auf dem das eigentliche FHEM usw. läuft. Funktioniert im Normalfall auch, aber wenn der Raspberry einen Reboot macht, dann ist erst einmal für eine gewisse Zeit die Verbindung unterbrochen, was mir nicht gefällt.

Hauptrechner BPI:

Code Auswählen Erweitern


define HomePresence dummy
attr HomePresence event-on-change-reading state.*
attr HomePresence room System

define remoteRPI FHEM2FHEM 192.168.178.45:7072 LOG:.*
attr remoteRPI room System

define tagLocAuto dummy
attr tagLocAuto room System

#define n_tagLocAuto notify tagLocAuto {fhem "$EVENT"}

define di_remoteRPI DOIF ( ... ) DOELSE ( ... )



Remote-Rechner RPI:

Code Auswählen Erweitern


define tagLocAuto dummy
attr tagLocAuto room Home

define tagPresenceAuto PRESENCE shellscript "sudo /opt/fhem/vdp/lescan.sh 7C:XX: XX:XX:XX:XX" 30 30
attr tagPresenceAuto absenceThreshold 1
attr tagPresenceAuto event-min-interval 300
attr tagPresenceAuto event-on-change-reading state,presence
attr tagPresenceAuto presenceThreshold 2
attr tagPresenceAuto room Home

define di_tagPresenceAuto DOIF ([tagPresenceAuto:presence] =~ "present") (set tagLocAuto present) DOELSE (set tagLocAuto absent)


Fragen:

Was macht beim Hauptrechner das

Code Auswählen Erweitern

define n_tagLocAuto notify tagLocAuto {fhem "$EVENT"}
Das soll man nach der Beschreibung auch so machen, aber dann gibt es gar keine Kommunikation zwischen den Rechnern. Obwohl es mir mit dem Notify richtig erscheint, mußte ich das weglassen. Ist das richtig oder mache ich da was falsch?


Wie kann ich es hinkriegen, daß nach einem Restart des Remote-RPI die Kommunikation zwischen den beiden Rechnern sofort wieder beginnt?

Vielen Dank für Eure Geduld, vielleicht kann mir da jemand helfen.

[Otto123]

Hi,

ich versuche es mal. Ich würde folgendes ändern:

Code Auswählen Erweitern

define remoteRPI FHEM2FHEM 192.168.178.45:7072 LOG:tagLocAuto

Damit hast Du den dummy sowohl im Remote FHEM als auch im Haupt FHEM und hast FHEM2FHEM auf diese Kommunikation eingeschränkt.

Das notify brauchst Du nicht, du kannst so einfach mit dem dummy arbeiten. Das notify macht im Zweifelsfall Unsinn, ich denke das ist ein historisches Rudiment und wird so nicht benötigt.
Jede Änderung des remote dummy sollte sofort im Hauptfehm ankommen.

ich habe solche Konstruktion genauso laufen.

Gruß Otto

[binford6000]

Hallo,
hab genauso was am Start. Bei mir ist nach einem Reboot vom 2. Raspi die Verbindung sofort wieder da.
Wie so oft gibt es mehrere Wege zum Ziel. Meiner sieht so aus:

gtag auf dem Zweit-Raspi:

Code Auswählen Erweitern

defmod gtag1.PRE PRESENCE function {`sudo /opt/fhem/scripts/lescan.sh 7C:2F:80:98:AC:0F`} 30 60
Auf dem Haupt-Raspi mit fhem2fhem eine Verbindung herstellen:

Code Auswählen Erweitern

defmod fhem2 FHEM2FHEM 10.3.3.41:7072 LOG:BWM.*|gtag1.PRE.*
Hier wird u.a. der gtag übergeben. State und Readings werden automatisch befüllt wenn sich hier ein gleichnamiges device befindet:

Code Auswählen Erweitern

defmod gtag1.PRE dummy
Um im Haupt-Raspi auch ein Presence-Device zu haben, kann man dann noch sowas machen:

Code Auswählen Erweitern

defmod Sebastian.gtag1.PRE PRESENCE event gtag1.PRE:absent gtag1.PRE:present
Funktioniert alles ohne notify und ohne doif und ohne Verzögerung 
Vg Sebastian

[rudolfkoenig]

Das notify macht im Zweifelsfall Unsinn, ich denke das ist ein historisches Rudiment

Ich kann mich nicht daran erinnern, sowas jemals propagiert zu haben.
Ich meine aber beim Professor sowas gesehen zu haben.

Die FHEM2FHEM Definition ist ein TCP/IP Client, und wenn der Server (hier RPi) "unsanft" rebootet, dann kriegt FHEM2FHEM das Problem erst nach 2 Stunden mit (default TCP/IP keepalive). Ein modify mit den gleichen Parametern baut die Verbindung neu auf, evtl. kann man das regelmaessig durchfuehren, oder beim Start vin FHEM@RPi es auf dem BananaPi ausfuehren lassen:

Code Auswählen Erweitern

define n notify global:INITIALIZED "perl fhem.pl bananaPi:7072 'modify remoteRPI 192.168.178.45:7072 LOG:tagLocAuto'"

(ungetestet)

[Otto123]

Rudiment

Ich wollte da gar keine persönlichen Bezug aufbauen 
Ich hatte ganz an meinem Anfang mit FHEM (2014) mal so ein Konstrukt aus einem anderen Blog, da wurde der set Befehl für den Haupt-FHEM in einen Dummy geschrieben und dann über so ein notify im Hauptfhem ausgeführt. Das war ziemlich kompliziert und vom Anfänger kaum zu verstehen. Das hat quasi einen clonedummy oder "automatisch kopierte" dummy gleichen Namens in beiden Systemen, wie es heute (oder schon damals) geht, nachgestellt.
-> Braucht man nicht.

Bei mir funktioniert der Verbindungsaufbau von FHEM2FHEM immer sofort wieder nach dem Neustart.

Edit: Sorry den Vorschlag von Rudi hatte ich nicht ganz durchschaut und damit falsch verstanden
Wobei der Vorschlag von Rudi ja beim Neustart vom Haupt FHEM durchgeführt wird, da wird doch FHEM2FHEM sowieso neu gestartet   
Das müsste könnte man eher mit einem presence device für den Remote-Pi koppeln. In der Art

Code Auswählen Erweitern

define raspi2 PRESENCE lan-ping 192.168.178.45 10 30
attr raspi2 event-on-change-reading state
define n notify raspi2:present modify remoteRPI 192.168.178.45:7072 LOG:tagLocAuto

Gruß Otto

[rudolfkoenig]

Das von mir erwaehnte notify muesste auf dem RPi definiert werden.

[Grinsekatze]

Ich denke, manne44 hatte hier, genau wie ich auch zu Beginn, das Problem, dass der Wiki-Eintrag zu F2F mal überarbeitet werden sollte.

Dort wird erklärt, dass man auf dem eigentlichen FHEM-System ein Dummy anlegen soll (in den Beispielen mit einem anderen Namen). Dieser wird dann mit einem Notify gefüllt, wobei STATE selbst zusammen gebaut werden muss.

Das dieser Notify nicht benötigt wird, wenn der Dummy den gleichen Namen hat, wie das zu spiegelnde Device (da er dann automatisch gefüllt wird) wird nicht erwähnt - ich habe es nur hier im Forum gefunden.

Auch möchte ich Otto zustimmen, dass Du die F2F-Definition einschränken solltest, auf die tatsächlich zu loggenden Devices.

Ich finde das Konstrukt F2F auch jedes mal wieder kompliziert: Häufig baue ich mir da dann endlosschleifen ein, wenn ich auf Events reagieren will.

Zum eigentlichen Problem:
Baue Dir doch einen Watchdog, der auslöst (den von Rudi erwähnten modify), wenn das System nicht verfügbar ist (bzw. wenn es wieder da ist) um den keepalive "zu umgehen".

[CoolTux]

Davon mal ganz ab.
Wieso wird hier nicht mit einer vorhandenen funktionierenden Lösung gearbeitet.
lepresenced auf dem Pi in der Garage installieren und presence für bluetooth Netzwerk einrichten.

[manne44]

Vielen Dank erst einmal für die vielen sachkundigen Antworten.
@CoolTux: Das scheint wirklich ein guter Vorschlag zu sein, aber erst einmal möchte ich das, was ich bisher habe, zum Laufen bringen. Denn das muß ja auch gehen. Im zweiten Schritt werde ich mich dann damit befassen, aber dann hätte ich mal eine funktionierende Rückfallebene, auf die ich zurück greifen kann, falls ich damit nicht klar komme.

Einschränkung auf die LOG-Einträge hat keine Verbesserung gebracht. Für die Kommunikationskontrolle habe ich ein blaue Quasi-LED, die blinkend  rot wird wenn keine Kommunikation mehr stattfindet:
Auf dem RPI wird neben present/absent auch pControl on/off gebildet und zum BPI übertragen:

Code Auswählen Erweitern


define pControl dummy
define di_pControl DOIF ([pControl] eq "on") (defmod myAt_on at +00:00:02 set pControl off) DOELSE (defmod myAt_off at +00:00:02 set pControl on)


Auf dem BPI dann die Neuerung mit den LOGs:

Code Auswählen Erweitern


define HomePresence dummy
attr HomePresence event-on-change-reading state.*
attr HomePresence room System

#define remoteRPI FHEM2FHEM 192.168.178.45:7072 LOG:.*
define remoteRPI FHEM2FHEM 192.168.178.45:7072 LOG:tagLocAuto.*|pControl.*


Wenn ich den RPI durch

Code Auswählen Erweitern


shutdown -r now
resette, dann stockt die Kommunikation, was ich am pControl sehen kann, was nicht mehr wechselt. Also das scheint hier nicht die Lösung zu sein. Warum geht es woanders?
Aber ich habe "defmod" gelernt, dank an binford6000, der das wohl standardmäßig statt define einsetzt. Aber in allen at-defines verhindert es mögliche Fehlermeldungen durch ggf. Überschneidungen. Habe ich im gesamten fhem.cfg bei at-defines geändert.
Den Lösungsansetz von rudolfkoenig habe ich noch nicht so richtig verstanden. Aber ich bleibe dran.

[manne44]

Jetzt scheint es zu funktionieren.
Ich habe mal die LOGs auf dem BPI geklammert:

Code Auswählen Erweitern

defmod remoteRPI FHEM2FHEM 192.168.178.45:7072 LOG:(tagLocAuto.*|pControl.*)

und bekomme nach

Code Auswählen Erweitern

shutdown -r now
des RPI folgenden Log-Eintrag:

Code Auswählen Erweitern

2017.08.18 15:15:34 1: 192.168.178.45:7072 disconnected, waiting to reappear
2017.08.18 15:15:40 1: FHEM2FHEM 192.168.178.45:7072 reappeared (remoteRPI)

Offenbar hat

Code Auswählen Erweitern

define n notify global:INITIALIZED "perl fhem.pl 192.168.178.40:7072 'modify remoteRPI 192.168.178.45:7072 LOG:(tagLocAuto|pControl)'"
auf dem RPI geholfen.
Ob es nun die LOG-Klammer sind? Oder das zusätzliche Notify?

Vielen Dank, ich habe einiges gelernt und bin offenbar weiter gekommen.

[Otto123]

Hi,

die Klammern brauchst Du in dem Fall eigentlich nicht, sie schaden aber auch nicht. Ich verwende sei bei mir auch manchmal so um das etwas eindeutiger zu kennzeichnen. Ich habe hier ne ganz gute Zusammenfassung und Erklärung gefunden:  http://regexp-evaluator.de/tutorial/metazeichen/

Ich habe gerade mal bei den Restart des entfernten Pis untersucht, ich war mir nicht sicher ob es wirklich sauber bei mir funktioniert  oder ob ich ein Problem damit noch nie bemerkt habe. Dazu habe ich folgenden "Blinker" mit DOIF verwendet:

Code Auswählen Erweitern

define di_blink DOIF ([+00:00:04]) (set Lamp on;;set wert 10)(set Lamp off;;set wert 15)
attr di_blink do always
attr di_blink room Test
attr di_blink wait 0,2
Im Haupt FHEM einfach dummy wert und Lamp angelegt und F2F mit LOG:Lamp|wert definiert.

Zumindest einem sauberen "reboot" des kompletten entfernen Raspberry überlebt dieses Konstrukt einwandfrei. Der Blinker funktioniert im Hauptsystem sofort nach dem Erscheinen der Weboberfläche von FHEM wieder sauber.

Das notify von Rudi wird bei Dir geholfen haben, offenbar verhält sich jede Umgebung etwas anders.

Gruß Otto

[manne44]

Hallo Otto, vielen Dank für die Mitteilung. Habe Deinen Blinker ausprobiert, ist eleganter als meiner, werde ich in Zukunft auch so machen. Habe ich wieder was gelernt. Zum RPI, er funktioniert, RPI-Reboot ist nun einwandfrei, offenbar durch Notify ... modify ..., was das bewirkt, obwohl ich das nicht ganz verstanden habe, aber sei es drum.
Gruß Manne

[Otto123]

was das bewirkt, obwohl ich das nicht ganz verstanden habe

Hallo Manne,

ich versuche mal eine Erklärung.
Das notify wird vom FHEM Systemstart Event getriggert -> global:INITIALIZED
Es geht auf Betriebssystemebene und startet eine FHEM remote Clientsitzung per Kommandzeile und Telnet
-> perl fhem.pl 192.168.178.40:7072
Er macht ein modify ohne die DEF wirklich zu ändern. Allerdings startet das modify das definierte Modul neu (um die "geänderte" DEF neu zu laden) damit wird die TCP Verbindung zum Remote Client neu initiiert.

Gruß Otto

[manne44]

Hallo Otto,
vielleicht ein Grund, daß sich der Restart des RPI bei mir anders verhält, könnte vielleicht auch an den verschiedenen OS-Versionen liegen.
Auf dem BananaPI läuft folgendes:

Code Auswählen Erweitern


pi@bpi ~ $ cat /proc/version                                           
Linux version 3.4.111-bananian (root@bananian-build) (gcc version 4.9.2 (Debian 4.9.2-10) ) #5 SMP PREEMPT Fri Mar 25 17:24:42 UTC 2016
pi@bpi ~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"

und auf dem remoteRPI

Code Auswählen Erweitern



pi@rpi ~ $ cat /proc/version                                             
Linux version 4.9.39+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1021 Mon Jul 24 11:27:49 BST 2017
pi@rpi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"


Das mit dem "modify" und dem Start leuchtet mir ein. Vielen Dank.
Gruß
Manne