Sonoff kommunizieren nicht mehr mit MQTT2

[Henrik.A]

Hallo,

ich hab schon eine ganze Weile rufgesucht, doch den Effekt den ich hier gerade erlebe scheint so noch keiner gehabt zu haben 
Darum schildere ich das Problem mal hier, vielleicht habt ihr einen Tipp wie ich es in den Griff bekomme.

Seit einigen Tagen lassen sich meine Sonoff-Module nicht mehr mit FHEM steuern. Alle sind mit TASMOTA 6.3.0.12 geflachst.
Auffällig ist, dass ich auch das Webinterface nicht mehr erreichen kann sobald er Kontakt mit MQTT aufnimmt. Ein Ping auf die IP-Adresse geht in unregelmäßigen Abständen für zehn oder mehr Sekunden scheint's in Leere. Dann Antwortet das Device wieder auf den Ping. Stoppe ich FHEM und damit MQTT2 entspannt sich das ganze und das Webinterface ist wieder erreichbar. Der Sonoff scheint für mich normal zu arbeiten, was mich vermuten "lastet" irgendwie lastet ihn MQTT2 aus.

MQTT2 zeigt im VerboseMode 5 dass der Keepalive Check in den Bach geht. Ich hab mal alle Devices auf FHEM entfernt und exemplarisch nur einem Sonoff (Subwoofer) angelegt und seine Logausgabe rausgezogen (der Ablauf wäre bei allen andern aber völlig gleich):

Code Auswählen Erweitern

2019.05.18 20:37:40 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Offline
2019.05.18 20:37:47 4: Connection accepted from MQTT2_FHEM_Server_10.3.1.27_3564
2019.05.18 20:37:47 5: CONNECT: (16)V(0)(4)MQTT(4)(238)(0)(10)(0)(16)sonoff-subwoofer(0)(25)tele/sonoff-subwoofer/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2019.05.18 20:37:47 4: MQTT2_FHEM_Server_10.3.1.27_3564 sonoff-subwoofer CONNECT V:4 keepAlive:10 LWT:tele/sonoff-subwoofer/LWT:Offline usr:DVES_USER
2019.05.18 20:37:47 5: PUBLISH: 1!(0)(25)tele/sonoff-subwoofer/LWTOnline
2019.05.18 20:37:47 4: MQTT2_FHEM_Server_10.3.1.27_3564 sonoff-subwoofer PUBLISH tele/sonoff-subwoofer/LWT:Online
2019.05.18 20:37:47 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Online
2019.05.18 20:38:10 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_10.3.1.27_3564/sonoff-subwoofer left us (keepalive check)


Hab' auch schon an den Einstellungen des Keepalive Checks gedreht, doch das hat die Stabilität nicht erhöht. Das Device lässt sich weder von FHEM aus steuern noch aktualisiert es seinen Status.

Ich erkenne aber nicht woher das plötzlich kommt. Bin aber auch nicht sonderlich gut mit MQTT2 vertraut. Wie gesagt vor einigen Tagen lief das noch, zumindest ohne von außen erkennbare Schwierigkeiten. Hoffe ihr habs einen Tipp für mich.


Update:
Habe die Ausgabe des MQTT2 zusammen mit einem Ping auf den Sonoff in die gleich Ausgabe laufen lassen. Man erkennt, dass immer wieder Pings fehlen und dass genau dann der Sonoff "von uns geht".

Code Auswählen Erweitern

64 bytes from 10.3.1.27: icmp_seq=34 ttl=128 time=3.94 ms
64 bytes from 10.3.1.27: icmp_seq=35 ttl=128 time=8.70 ms
64 bytes from 10.3.1.27: icmp_seq=36 ttl=128 time=4.54 ms
64 bytes from 10.3.1.27: icmp_seq=46 ttl=128 time=8.78 ms
64 bytes from 10.3.1.27: icmp_seq=47 ttl=128 time=5.44 ms
2019.05.18 21:35:38 4: Connection accepted from MQTT2_FHEM_Server_10.3.1.27_14707
2019.05.18 21:35:38 5: CONNECT: (16)V(0)(4)MQTT(4)(238)(0)(10)(0)(16)sonoff-subwoofer(0)(25)tele/sonoff-subwoofer/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2019.05.18 21:35:38 4: MQTT2_FHEM_Server_10.3.1.27_14707 sonoff-subwoofer CONNECT V:4 keepAlive:10 LWT:tele/sonoff-subwoofer/LWT:Offline usr:DVES_USER
2019.05.18 21:35:38 5: PUBLISH: 1!(0)(25)tele/sonoff-subwoofer/LWTOnline
2019.05.18 21:35:38 4: MQTT2_FHEM_Server_10.3.1.27_14707 sonoff-subwoofer PUBLISH tele/sonoff-subwoofer/LWT:Online
2019.05.18 21:35:38 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Online
64 bytes from 10.3.1.27: icmp_seq=48 ttl=128 time=3.52 ms
64 bytes from 10.3.1.27: icmp_seq=49 ttl=128 time=3.67 ms
64 bytes from 10.3.1.27: icmp_seq=50 ttl=128 time=3.86 ms
64 bytes from 10.3.1.27: icmp_seq=51 ttl=128 time=3.44 ms
64 bytes from 10.3.1.27: icmp_seq=52 ttl=128 time=4.04 ms
64 bytes from 10.3.1.27: icmp_seq=53 ttl=128 time=5.90 ms
64 bytes from 10.3.1.27: icmp_seq=54 ttl=128 time=65.3 ms
64 bytes from 10.3.1.27: icmp_seq=55 ttl=128 time=85.0 ms
64 bytes from 10.3.1.27: icmp_seq=56 ttl=128 time=107 ms
64 bytes from 10.3.1.27: icmp_seq=57 ttl=128 time=3.66 ms
2019.05.18 21:36:02 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_10.3.1.27_14707/sonoff-subwoofer left us (keepalive check)
2019.05.18 21:36:02 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Offline
2019.05.18 21:36:04 4: Connection accepted from MQTT2_FHEM_Server_10.3.1.27_10523
2019.05.18 21:36:04 5: CONNECT: (16)V(0)(4)MQTT(4)(238)(0)(10)(0)(16)sonoff-subwoofer(0)(25)tele/sonoff-subwoofer/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2019.05.18 21:36:04 4: MQTT2_FHEM_Server_10.3.1.27_10523 sonoff-subwoofer CONNECT V:4 keepAlive:10 LWT:tele/sonoff-subwoofer/LWT:Offline usr:DVES_USER
2019.05.18 21:36:04 5: PUBLISH: 1!(0)(25)tele/sonoff-subwoofer/LWTOnline
2019.05.18 21:36:04 4: MQTT2_FHEM_Server_10.3.1.27_10523 sonoff-subwoofer PUBLISH tele/sonoff-subwoofer/LWT:Online
2019.05.18 21:36:04 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Online
64 bytes from 10.3.1.27: icmp_seq=73 ttl=128 time=5.03 ms
64 bytes from 10.3.1.27: icmp_seq=74 ttl=128 time=4.85 ms
64 bytes from 10.3.1.27: icmp_seq=75 ttl=128 time=3.12 ms
64 bytes from 10.3.1.27: icmp_seq=76 ttl=128 time=3.92 ms
64 bytes from 10.3.1.27: icmp_seq=77 ttl=128 time=3.50 ms
64 bytes from 10.3.1.27: icmp_seq=78 ttl=128 time=4.27 ms
64 bytes from 10.3.1.27: icmp_seq=79 ttl=128 time=3.55 ms
64 bytes from 10.3.1.27: icmp_seq=80 ttl=128 time=3.20 ms
64 bytes from 10.3.1.27: icmp_seq=81 ttl=128 time=4.82 ms
2019.05.18 21:36:22 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_10.3.1.27_10523/sonoff-subwoofer left us (keepalive check)
2019.05.18 21:36:22 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Offline
64 bytes from 10.3.1.27: icmp_seq=98 ttl=128 time=5.34 ms
2019.05.18 21:36:30 4: Connection accepted from MQTT2_FHEM_Server_10.3.1.27_11389
2019.05.18 21:36:30 5: CONNECT: (16)V(0)(4)MQTT(4)(238)(0)(10)(0)(16)sonoff-subwoofer(0)(25)tele/sonoff-subwoofer/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2019.05.18 21:36:30 4: MQTT2_FHEM_Server_10.3.1.27_11389 sonoff-subwoofer CONNECT V:4 keepAlive:10 LWT:tele/sonoff-subwoofer/LWT:Offline usr:DVES_USER
2019.05.18 21:36:30 5: PUBLISH: 1!(0)(25)tele/sonoff-subwoofer/LWTOnline
2019.05.18 21:36:30 4: MQTT2_FHEM_Server_10.3.1.27_11389 sonoff-subwoofer PUBLISH tele/sonoff-subwoofer/LWT:Online
2019.05.18 21:36:30 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Online
64 bytes from 10.3.1.27: icmp_seq=99 ttl=128 time=3.54 ms
2019.05.18 21:36:52 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_10.3.1.27_11389/sonoff-subwoofer left us (keepalive check)
2019.05.18 21:36:52 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Offline
64 bytes from 10.3.1.27: icmp_seq=123 ttl=128 time=4.20 ms
2019.05.18 21:36:56 4: Connection accepted from MQTT2_FHEM_Server_10.3.1.27_13439
2019.05.18 21:36:56 5: CONNECT: (16)V(0)(4)MQTT(4)(238)(0)(10)(0)(16)sonoff-subwoofer(0)(25)tele/sonoff-subwoofer/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2019.05.18 21:36:56 4: MQTT2_FHEM_Server_10.3.1.27_13439 sonoff-subwoofer CONNECT V:4 keepAlive:10 LWT:tele/sonoff-subwoofer/LWT:Offline usr:DVES_USER
2019.05.18 21:36:56 5: PUBLISH: 1!(0)(25)tele/sonoff-subwoofer/LWTOnline
2019.05.18 21:36:56 4: MQTT2_FHEM_Server_10.3.1.27_13439 sonoff-subwoofer PUBLISH tele/sonoff-subwoofer/LWT:Online
2019.05.18 21:36:56 5: MQTT2_FHEM_Server: dispatch autocreate=complex\000sonoff_subwoofer\000tele/sonoff-subwoofer/LWT\000Online
64 bytes from 10.3.1.27: icmp_seq=124 ttl=128 time=64.8 ms
64 bytes from 10.3.1.27: icmp_seq=125 ttl=128 time=3.68 ms
64 bytes from 10.3.1.27: icmp_seq=126 ttl=128 time=3.88 ms
64 bytes from 10.3.1.27: icmp_seq=127 ttl=128 time=4.72 ms

[bartman121]

Benutze doch bitte die Code-Tags....

Entweder habe ich es überlesen oder du hast es nicht geschrieben.

Als es noch funktioniert hat, hattest du da eine andere tasmota-Version drauf?
Wenn ja, dann Wechsel doch auf die alte Version zurück.

[Henrik.A]

Guter Hinweis, hab's aktualisiert. 

Um Deine Frage zu beantworten - nein, die Tasmotaversion hat sich nicht geändert.

[Beta-User]

Die Frage war vielleicht etwas eng gestellt. Erweitert: hast du was geändert?Insbesondere die Zahl der WLAN-Geräte? (Kann auch ohne fhem-Bezug sein)

[bartman121]

Okay, dann bleibt entweder ein WLAN-Problem oder tatsächlich ein Mqtt2-Problem.

Du schriebst es hat mal funktioniert: machst du regelmäßig fhem-Updates?

1. Schau mal ob es Updates bei mqtt2 gab und versuch mal downzugraden.

2. Deaktiviere mal im tasmota das mqtt und checke dann mal mit ping ob das device im WLAN bleibt.

3. Du könntest mal einen mosquito-Server installieren und damit testen ob das device sich dann "vernünftig" verhält.

[DasQ]

Könntest du mal deine config posten? Raw und List und vom tasmota?

BTW. Was sagt denn der tasmota log?

[rudolfkoenig]

Man erkennt, dass immer wieder Pings fehlen und dass genau dann der Sonoff "von uns geht".

Ist mAn ein Netzwerkproblem, und hat wenig mit der FHEM MQTT2 Implementation zu tun.

Auffällig ist, dass ich auch das Webinterface nicht mehr erreichen kann sobald er Kontakt mit MQTT aufnimmt.

Ich vermute ein Problem in Tasmota: bestimmte Netzwerkaufrufe sind blockierend.
Ich wuerde versuchen auf dem Sonoff Logs zu erzeugen, es scheint aber auf dem ersten Blick nicht ganz trivial zu sein.

[Henrik.A]

Zunächst mal vielen Dank für die vielen Reaktionen zu meinem Thema!
Ihr habt echt schwer was los. 

Ich versuch mal die von euch vorgebrachten Punkte zu beantworten und fange mit dem Thema Updates an, denn zunächst hatte ich auch in diese Richtung gedacht...
Bevor der ganze Zauber los ging, hatte ich auf meiner Fritzbox6820 LTE eine Laborversion (7.10) getestet, da die LTE-Einwahl nicht immer stabil arbeitete. Diese neue Version ergab keine Verbesserung, darum hab ich sie wieder entfernt. Nachdem dann irgendwann später der besagte Problem an den Sonoffs aufgetreten sind hatte ich die Sorge es könnte doch noch irgendwas an der Box verbogen sein und hab' den AVM-Support um Unterstützung gebeten. Dort riet man mir die Firmware mit einem speziellen Programm neu auf die Box zu flachen, dann sei alles wie bei Auslieferung. Gesagt, getan. Die ganze Konfiguration war natürlich weg. Um allem aus dem Weg zu gehen, hab ich die Einstellungen manuell wieder eingetragen und nicht die Sicherung eingespielt, doch das Problem trat wieder auf.
Nächster Gedanke - da gibt's ja noch einen Repeater! Also auch dem Werkseinstellungen verpasst - was soll ich euch sagen, alles ohne durchschlagenden Erfolg. Hab's auch schon ganz ohne den Repeater versucht, das Fehlerbild bleibt.

Das führt nicht zum den FHEM-Updates. Ja, natürlich mache ich diese, den letzten erst vor ein paar Tagen. Da das System (RaspberryPi3 mit Touchscreen unter ArchLinux) aber schon seit mehr als zwei Jahren läuft (natürlich auch immer wieder aktualisiert), hätte es ja sein können, dass da was nicht stimmt. Hab darum ein komplett neues System incl. FHEM aufgesetzt. Der Fehler kommt jedoch wieder vor.

In einem letzten Test habe ich gerade nur das Tasmota-Device mit der MQTT2-Serveradresse versehen und siehe da, es braucht in FHEM nicht mal einen Definition zu existieren und die Probleme treten wieder auf.

Um's jetzt völlig verwirrend für euch zu machen, habe ich auch noch einen MQTT2-Server in einem anderen Teil meines Netzes getestet (habe dazu eine VPN-Verbindungen meiner Fritzbox zu einem weiteren FHEM-Server genutzt ansonsten ist die Infrastruktur aber gleich geblieben). Da tritt das Problem nicht auf. Die beiden haben unterschiedliche Updatestände mit der Version fhem.pl:19085/2019-04-01 funktioniert's mit  fhem.pl:19381/2019-05-13 nicht. Hat die Latenz des VPN-Tunnel u.U. heilsamen Einfluss auf das Verhalten?

Ich bin etwas ratlos doch gehen meine Vermutungen inzwischen in Richtung der Sonoff genauer des Tasmota darauf. Unlogisches aber auch hier. Ich setze die gleiche Tasmota-Version auf Sonoff-Basic und einem LC01 ein. Das Webinterface LC1 antwortet normal, zeigt aber auch Verbindungsabbrüche.

Code Auswählen Erweitern

00:00:00 Projekt sonoff sonoff_deckenlicht_wohnzimmer Version 6.4.1.5(sonoff)-2_4_2
00:00:00 WIF: verbinden mit AP1 xxxxx in Modus 11N wie sonoff_deckenlicht_wohnzimmer-7...
00:00:04 WIF: verbunden
00:00:04 HTP: Web-Server aktiv bei sonoff_deckenlicht_wohnzimmer-7 mit IP-Adresse 10.3.1.26
11:26:47 MQT: Verbindungsversuch...
11:26:47 MQT: verbunden
11:26:47 MQT: tele/sonoff_deckenlicht_wohnzimmer/LWT = Online (beibehalten)
11:26:47 MQT: cmnd/sonoff_deckenlicht_wohnzimmer/POWER =
11:26:47 MQT: tele/sonoff_deckenlicht_wohnzimmer/INFO1 = {"Module":"Arilux LC01","Version":"6.4.1.5(sonoff)","FallbackTopic":"cmnd/sonoff_deckenlicht_wohnzimmer_fb/","GroupTopic":"sonoffs"}
11:26:47 MQT: tele/sonoff_deckenlicht_wohnzimmer/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff_deckenlicht_wohnzimmer-7","IPAddress":"10.3.1.26"}
11:26:47 MQT: tele/sonoff_deckenlicht_wohnzimmer/INFO3 = {"RestartReason":"Fatal exception:3 flag:2 (EXCEPTION) epc1:0x4010011d epc2:0x00000000 epc3:0x40000f68 excvaddr:0x400370d0 depc:0x00000000"}
11:26:47 MQT: stat/sonoff_deckenlicht_wohnzimmer/RESULT = {"POWER":"OFF"}
11:26:47 MQT: stat/sonoff_deckenlicht_wohnzimmer/POWER = OFF
11:26:55 MQT: Verbindungsversuch...
11:26:55 MQT: verbunden
11:26:55 MQT: tele/sonoff_deckenlicht_wohnzimmer/LWT = Online (beibehalten)
11:26:55 MQT: cmnd/sonoff_deckenlicht_wohnzimmer/POWER =
11:26:55 MQT: tele/sonoff_deckenlicht_wohnzimmer/STATE = {"Time":"2019-05-19T11:26:55","Uptime":"0T00:00:14","Vcc":3.549,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Dimmer":100,"Color":"255,255,255","HSBColor":"0,0,100","Channel":[100,100,100],"Scheme":0,"Fade":"ON","Speed":5,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"VHournet","BSSId":"CC:CE:1E:1E:54:36","Channel":6,"RSSI":74}}

Ergibt das für euch noch irgend einen Sinn?

Gruß
Henrik.

[Henrik.A]

Hab gerade in einem anderen Forum was zu Problemen mit MQTT und Tasmota gefunden. Anscheinend ist der Core in der von mir verwendeten Version nicht einwandfrei (https://forum.creationx.de/forum/index.php?thread/922-probleme-mit-sonoff-tasmota-mqtt/&pageNo=1). Werde versuchen ob ein Wechsel auf den Core V2.3.0 was verändert und dann berichten...

[sash.sc]

Das würde heißen, einfach die firmware downgraden. Vorher mal schauen bei welche Firmware sich der Core geändert hat.

Gesendet von meinem E6653 mit Tapatalk

[Beta-User]

Wieso downgraden?

Alle sind mit TASMOTA 6.3.0.12 geflachst.

Das ist doch noch längst nicht die neueste. Warum nicht erst mal die 6.5?

[sash.sc]

Ich habe es auch, das zwischendurch sich die Steckdosen mit der Energiemessung aus den wlan verabschieden. Das hängt aber wohl mit dem dynamischen sleep Modus zusammen. Glaub ich.

Gesendet von meinem E6653 mit Tapatalk

[Beta-User]

Es scheint (auch) von der Gegenstelle abhängig zu sein, siehe https://github.com/arendst/Sonoff-Tasmota/issues/5146.

Dort (und vermutlich auch hier) ist (mal wieder) die Fritzbox Teil des Problems; das hatten wir leider schon häufiger (nicht nur mit tasmota)...

Fakt scheint jedenfalls zu sein, dass MQTT2_SERVER nicht der Verursacher ist.

[Henrik.A]

Hab mir gestern die Nacht um die Ohren geschlagen und die möglichen Kombinationen von Core, MQTT-Varianten und Tasmota Hauptversionen ausprobiert. Habe aber leider erst jetzt die Zeit gefunden euch zu informieren.
Es zeigte sich, dass Core Version 2.3.0 nicht das Problem löste. Erst in Kombination mit der Standard MQTT-Librarry von Tasmota wurde der Sonoff etwas besser ansprechbar. Doch selbst dann blieb immer noch eine deutliche erhöhte Reaktionszeit am Webinterface.
Besser wurde es erst mit der neuesten Tasmota-Version 6.5.0.11 in Verbindung mit dem Core 2.5.1. Seither antwortet das Webinterface zügig und die Verbindung scheint zuverlässig zu halten. Ich werde noch weiter testen...

[Tedious]

Ich hatte mal eine Weile massive Probleme mit den (damals) aktuellen Versionen von Tasmota. Geholfen hat es nur den DynamicSleep herunter zu setzen. Liefen mit 250 sehr gut, denn kam irgendwann ein Update - und sie waren kaum noch ansprechbar. Setz das mal testweise auf 50 runter und schau ob es (noch) besser wird.