Hallo,
ich habe ein Problem mit FHEM2FHEM.
Die Alarmanlage am Hauptserver aktiviert unter bestimmten Umständen (wenn Vorarlam ausgelöst wurde) einen Dummy (mit dam Namen "Testsound" - hab ich seit dem Testen wohl nicht umbenannt) um einen Ton auf einem RaspberryPi an dem Lautsprecher hängen, abzuspielen.
Das hat jetzt 2-3 Jahre bestens funktioniert, aber plötzlich geht es nicht mehr. Natürlich hat es irgendeine Ursache, ich weiß aber nicht welche.
Aktiviere ich "Testsound" am Hauptserver, so sehe ich das im Event monitor:
2017-06-05 14:31:56 dummy Testsound on
Auf beiden Seiten, Hauptserver und Raspberry finden sich Dummys mit dem gleichen Namen.
Am Raspberry findet sich im Logfile oder im Event monitor nichts und der Ton wird auch nicht abgespielt, wenn am Hauptserver der gleiche Dummy getriggert wird. Das ganze funktioniert nicht nur bei "Testsound" nicht sondern auch nicht bei allen anderen Dummys, die irgendwelche Soundfiles triggern sollten.
Aktiviere ich den Dummy "Testsound" am Raspberry, dann wird der Ton ordnungsgemäß abgespielt (auch alle anderen Dummys und Soundfiles funktionieren, wenn sie lokal aktiviert werden).
Die Konnektivität zwischen den FHEMs dürfte gegeben sein - Auch das Text-To-Speech kann vom Hauptserver am Raspberry getriggert werden, aber das läuft auch nicht über FHEM2FHEM. Zeigt nur, dass es kein Netzwerkproblem ist.
Am Raspberry ist FHEM2FHEM wie folgt konfiguriert:
define Hauptserver FHEM2FHEM 192.168.0.1:7072 LOG:.* <passwort>
Am Hauptserver ist telnet konfiguriert:
define allowed_telnetPort allowed
attr allowed_telnetPort password <passwort>
attr allowed_telnetPort validFor telnetPort
define telnetPort telnet 7072 global
Und die Verbindung funktioniert auch:
2017.06.05 14:37:05 3: FHEM2FHEM opening Hauptserver at 192.168.0.1:7072
2017.06.05 14:37:05 4: HttpUtils url=http://192.168.0.1:7072/
2017.06.05 14:37:06 3: FHEM2FHEM device opened (Hauptserver)
Im Logfile finden sich auch keine außergewöhnlichen Verbindungsabbrüche, nur bei Restarts. Beide FHEM-Instanzen (Hauptserver und Raspberry) sind mit Stand heute aktuell und neu gestartet.
Hat hier jemand eine Idee? Ich kann gerne noch mehr Logs liefern. Ich habe aber an dieser Verbindung, den Dummys oder den Soundfiles seit Monaten nichts geändert und jetzt seit ein paar Tagen funktioniert es nicht mehr, deswegen weiß ich auch nicht, wo ich suchen könnte.
Bitte auf dem Raspberry "attr Hauptserver verbose 4" setzen, ein Probelauf durchfuehren, und das FHEM-Log hier anhaengen. Weiterhin bitte die Definition+Attributliste der beiden Testsound dummys zeigen (gerne mit "Raw definition").
Seit ca 5 Monaten aktualisiert FHEM2FHEM selbststaendig die Readings von lokalen Geraeten, falls sie den gleichen Namen haben, wie ein Remote-Geraet. Vorher war fuer sowas ein notify oder ein cloneDummy notwendig.
Raspberry FHEM2FHEM "Hauptserver" mit Verbose 4 (keine Änderung zu vorher, wenn ich den Dummy Testound am Hauptserver schalte, bekomme ich am Raspberry keinen Log-Eintrag):
2017.06.07 08:24:42 3: FHEM2FHEM opening Hauptserver at 192.168.0.1:7072
2017.06.07 08:24:42 4: HttpUtils url=http://192.168.0.1:7072/
2017.06.07 08:24:42 3: FHEM2FHEM device opened (Hauptserver)
Testsound am Hauptserver:
Internals:
NAME Testsound
NR 123
STATE on
TYPE dummy
Readings:
2017-06-07 08:25:40 state on
Attributes:
room Alarmanlage
webCmd on:off
Testsound am Raspberry:
Internals:
CFGFN
NAME Testsound
NR 85
STATE off
TYPE dummy
Readings:
2017-06-05 12:06:34 state off
Attributes:
webCmd on:off
Für mich nicht sehr aussagekräfig.
CloneDummy oder notfiy habe ich nicht verwendet und die Alarmanlage gibt es in dieser Konfiguration sicher schon länger als 5 Monate, inkl. der "Testsound" Dummys, die dann den Ton ausgelöst haben.
Zitatdefine Hauptserver FHEM2FHEM 192.168.0.1:7072 LOG:.* <passwort>
...
Zitat2017.06.07 08:24:42 3: FHEM2FHEM opening Hauptserver at 10.0.0.11:7072
Bin verwirrt. 10.* oder 192.* ?
Mit "attr global verbose 4" sollte FHEM2FHEM im Log-Mode alle Meldungen protokollieren, und bei .* sollte das eine Menge sein.
Kannst du bitte "attr global verbose 4" auch auf dem Hauptserver setzen, und ein paar Events generieren? Die auf dem Hauptserver gezeigten Events muessten im Raspberry Log auftauchen (wenn die FHEM2FHEM Instanz noch mit verbose 4 laeuft).
Zitat von: rudolfkoenig am 07 Juni 2017, 09:02:23
...Bin verwirrt. 10.* oder 192.* ?
Das kommt davon, wenn du deine interne IP verstecken willst und es dann beim zweiten Post vergisst zu ändern. Sorry. Die IP stimmt auf jeden Fall überein...
Zitat von: rudolfkoenig am 07 Juni 2017, 09:02:23
Mit "attr global verbose 4" sollte FHEM2FHEM im Log-Mode alle Meldungen protokollieren, und bei .* sollte das eine Menge sein.
Kannst du bitte "attr global verbose 4" auch auf dem Hauptserver setzen, und ein paar Events generieren? Die auf dem Hauptserver gezeigten Events muessten im Raspberry Log auftauchen (wenn die FHEM2FHEM Instanz noch mit verbose 4 laeuft).
Klingt absolut schlüssig, aber es kommt am Raspberry nichts an. Die FHEM Instanz am Hauptserver läuft jetzt mit dem von dir vorgeschlagnen Verbose 4 und erzeugt jede Menge Logs, natürlich habe ich auch den Testsound Dummy probiert und der scheint in den Logs auf (auch der ist mittlerweile mit Verbose 4 ausgestattet).
FHEM2FHEM läuft auch auf Verbose 4, aber in den Logs findet sich nur die erfolgreiche Meldung über den Verbindungsaufbau.
Hier noch ein list Hauptserver vom Raspberry FHEM:
Internals:
CFGFN
DEF 192.168.0.1:7072 LOG:.* <passwort>
FD 4
Host 192.168.0.1:7072
NAME Hauptserver
NR 160
PARTIAL
STATE connected
TYPE FHEM2FHEM
informType LOG
portpassword <passwort>
regexp .*
Attributes:
verbose 4
Hi,
also dann evtl. unser neues und gutes Sicherheitsfeature. Trag doch mal ein
attr WEB allowfrom <ip-des-fhem1>|<ip-des-fhem2>
ein.
Edit: Natürlich nicht auf WEB sondern den TelnetPort (Du nutzt ja 7072)
Zur Not zu Testzwecken .*
Wenn das nicht hilft wieder löschen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi shady88,
ich lese nur mit...
Interne IPs "verstecken" hilft maximal demjenigen, der Dir helfen will, vollends zu verwirren und ist ziemlich Sinnfrei.
Sehr oft sind einfache Tippfehler das Problem, die kann ein andere häufig besser sehen als Du selbst. Wenn dann Tippfehler mit Tippfehlern "korrigiert" werden fühlt sich der Helfer veräppelt.
Logs erzeugen und Events generieren sind zwei völlig getrennte "Latschen" Schaust Du auf dem raspberry auch in den Eventmonitor?
Gruß Otto
Zitat von: RaspiLED am 07 Juni 2017, 09:53:47
Hi,
also dann evtl. unser neues und gutes Sicherheitsfeature. Trag doch mal ein
attr WEB allowfrom <ip-des-fhem1>|<ip-des-fhem2>
ein.
Edit: Natürlich nicht auf WEB sondern den TelnetPort (Du nutzt ja 7072)
Zur Not zu Testzwecken .*
Wenn das nicht hilft wieder löschen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Am Hauptserver:
define telnetPort telnet 7072 global
attr telnetPort allowfrom 192.168.1.50
define allowed_telnetPort allowed
attr allowed_telnetPort password <passwort>
attr allowed_telnetPort validFor telnetPort
Bringt leider auch nichts, auch nicht mit .*
Aber wenn "allowfrom" nicht gesetzt ist, dann sollten die lokalen Verbindungen ja trotzdem zugelassen werden, wenn ich die CommandRef richtig interpretiere.
Firewall ist keine dazwischen, nur zur Info.
Zitat von: Otto123 am 07 Juni 2017, 10:00:22
Logs erzeugen und Events generieren sind zwei völlig getrennte "Latschen" Schaust Du auf dem raspberry auch in den Eventmonitor?
Am Event Monitor schau ich auch mit, allerdings finden sich auch dort keine Eintragungen am Remote-Raspberry, wenn ich am Hauptserver Events generiere.
in deinem list steht STATE connected
Wenn da nicht alles nur ein fake ist geht die F2F Telnet Verbindung.
Siehst Du denn im Eventmonitor vom Hauptserver Events?
Hast Du eventuell das Problem, dass Deine Eventmonitor im Browser einfach nichts anzeigt? (Virenscanner etc)
Was passiert wenn Du eine Telnet Verbindung zum Hauptserver bzw zum Raspberry machst telnet <IP> 7072 und dann inform on eingibst?
Gruß Otto
Zitat von: Otto123 am 07 Juni 2017, 11:23:59
in deinem list steht STATE connected
Wenn da nicht alles nur ein fake ist geht die F2F Telnet Verbindung.
Siehst Du denn im Eventmonitor vom Hauptserver Events?
Ist kein Fake...
Ja, am Event Monitor vom Hauptserver sehe ich quasi im Sekundentakt (Presence, PV-Anlage, Receiver,... erzeugen einiges) neue Events
Zitat von: Otto123 am 07 Juni 2017, 11:23:59
Hast Du eventuell das Problem, dass Deine Eventmonitor im Browser einfach nichts anzeigt? (Virenscanner etc)
Nein, hier gibt es kein Problem. Events werden sowohl vom FHEM am Hauptserver, als auch am Raspberry angezeigt.
Zitat von: Otto123 am 07 Juni 2017, 11:23:59
Was passiert wenn Du eine Telnet Verbindung zum Hauptserver bzw zum Raspberry machst telnet <IP> 7072 und dann inform on eingibst?
Ich nehme an, du meinst auf der Commandline.
Vom Hauptserver zum Raspberry wird die Verbindung zwar aufgebaut, aber sofort wieder geschlossen.
telnet 192.168.1.50 7072
Trying 192.168.1.50...
Connected to 192.168.1.50.
Escape character is '^]'.
Connection closed by foreign host.
Vom Raspberry zum Hauptserver wird die Verbindung aufgebaut, ich kann Befehle absetzen, aber danach wird die Verbindung sofort geschlossen.
telnet 192.168.1.1 7072
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
inform on
Connection closed by foreign host.
Die Verbindung klappt aber die Kommunikation nicht? Sehr merkwürdig...
Aber genau dort wird das Problem sein...
Geht das lokal? Also im Terminal/Commandline auf dem gleichen Host?
Gruß Otto
Ok, Telnet läuft jetzt. Aufgrund der "allowfrom" lief das nicht wirklich, obwohl die IPs eigentlich übereingestimmt haben. Ich habe allowfrom rausgenommen, jetzt kann ich mich lokal auch ohne Problem verbinden.
Nach "inform on" sehe ich alle möglichen Events, ich nehme an, dass die mit dem Event Monitor übereinstimmen. Am Hauptserver sind das sehr viele, am Raspberry eher wenig (dort passiert nicht sehr viel) und nur das, was dort passiert.
FHEM2FHEM am Raspberry steht immer noch auf connected, auch nach einem Reopen.
Anscheinend ist es aber so, dass vom Hauptserver nichts am Raspberry ankommt, obwohl die Verbindung besteht.
Und der Test mit dem Telnet klappt auch vom Raspberry(Terminal) zum Hauptserver?
Ein LOG:.* muss Dir alle Events vom Hauptserver liefern (was praktisch sinnlos und eventuell gefährlich ist)
Ansonsten weiß ich nicht, ich bin aber der Meinung, die Telnet Kommunikation über Port 7072 ist die Basis. Wenn die geht, geht auch F2F. Alles weitere kann nur Rudi sagen :)
Gruß Otto
irgendein Update vom System gemacht?
Schein einmal das System neu gebootet?
Nachdem ich jetzt einige in Aufregung versetzt habe, habe ich die Lösung gefunden. FHEM ist nicht dran Schuld.
Beim Herumspielen mit Telnet ist mir aufgefallen, dass die Verbindung vom Raspberry zum Hauptserver manchmal etwas länger braucht. Ein paar Netzwerkmessungen haben dann gezeigt, dass es manchmal wirklich etwas länger dauert und es auch zu Paketverlusten kommt, obwohl der Raspberry genau neben einem Repeater steht (und das auch schon seit mehreren Jahren). Tja, wie soll ich sagen. Meine Freundin hat vor ein paar Tagen diesen Repeater vom Strom ausgesteckt und vergessen wieder einzustecken. Die Verbindung war dementsprechend schlecht (aber dennoch vorhanden) und anscheinend ist FHEM2FHEM nicht fehlertolerant und hat deswegen nicht mehr funktioniert. (meine subjektive Vermutung)
FHEM2FHEM war aber die ganze Zeit auf Connected und hat keinen Verbindungsabbruch in den Logs angezeigt.
Noch bevor ich diesen Fehler entdeckt habe, habe ich ein Update (apt-get) durchgeführt was mit ca. 500 kB/s noch akzeptabel schnell war. Ich denke nicht, dass FHEM2FHEM eine solch hohe Datenrate braucht, aber irgendwas passte dem Modul trotzdem nicht.
Seitdem der Repeater wieder im Betrieb ist, sehe ich alle möglichen Logs (da LOG .*) am Raspberry im Event Monitor ankommen und die Soundfiles werden wieder abgespielt.
Sorry für die Verwirrung, aber da die Netzwerkverbindung ja funktioniert hat, habe ich daran nicht gedacht. Erst als ich die von Otto vorgeschlagene Verbindung geprüft habe, ist es mir aufgefallen.
Danke an alle Beteiligten - Wenn ich FHEM2FHEM in dieser Konfiguration (ohne Repeater) testen soll, stelle ich mich natürlich gerne zur Verfügung.