MQTT2 / SonOff S20 verliert Verbindung zu FHEM

Begonnen von Rainer82, 02 Dezember 2019, 10:07:12

Vorheriges Thema - Nächstes Thema

Rainer82

Hallo,

nachdem nun die S20-Steckdosen per MQTT2 eingebunden und konfiguriert sind, stelle ich fest, dass die Verbindung zu den Steckdosen nach einem automatischen WLAN-Kanalwechsel der FritzBox nicht mehr vorhanden ist.

Die Geräte sind aber noch im WLAN vorhanden und anpingbar, nur unter FHEM sind die Geräte offline.

Wie können die Geräte wieder in FHEM aktiviert werden ?


TomLee

Warum und weshalb weiß ich auch nicht, blinkt die Led am Sonoff, was passiert den nach einem kurzen stromlos machen oder einem restart 1 in der Konsole ( wenn anpingbar kommst ja sicher auch auf die Tasmotaoberfläche), sind die Dosen dann wieder online ?

Gruß

Thomas

rudolfkoenig

ZitatDie Geräte sind aber noch im WLAN vorhanden und anpingbar, nur unter FHEM sind die Geräte offline.
Ist der MQTT-Server ein externes (mosquitto) oder MQTT2_SERVER?
In beiden Faellen: der Client sollte nach Abbruch der Verbindung eine Neue aufmachen, hier kann keepAlive helfen.

Rainer82

#3
Es wird unter FHEM MQTT2 gestartet (MQTT2_FHEM_Server: port 1883 opened)

Auf die WebGui komme ich drauf, leider werden die S20-Steckdosen danach auch nicht eigebunden.

ZitatIn beiden Faellen: der Client sollte nach Abbruch der Verbindung eine Neue aufmachen, hier kann keepAlive helfen.
Wie wird das genutzt ?

Tedious

Kleiner Tip - installier Dir mal TasmoAdmin für die Verwaltung. Auch immer hilfreich ist z.B. MQTT-Explorer (o.ä.), mal mitlesen was an Nachrichten läuft. Ist so aud der Ferne schwer zu sagen.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Rainer82

#5
mittels $ mosquitto_sub -d -t '#' wird folgendes ausgegeben:

pi@raspberrypi:~ $ mosquitto_sub -d -t '#'
Client mosqsub/32164-fhem2018 sending CONNECT
Client mosqsub/32164-fhem2018 received CONNACK
Client mosqsub/32164-fhem2018 sending SUBSCRIBE (Mid: 1, Topic: #, QoS: 0)
Client mosqsub/32164-fhem2018 received SUBACK
Subscribed (mid: 1): 1
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/S20_4/LWT', ... (7 bytes))
Offline
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/sonoffRF/LWT', ... (7 bytes))
offline
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/sonoff_pow_1/LWT', ... (7 bytes))
Offline
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/S20_3/LWT', ... (7 bytes))
Offline
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/sonoff/LWT', ... (6 bytes))
Online
Client mosqsub/32164-fhem2018 received PUBLISH (d0, q0, r0, m0, 'tele/S20_2/LWT', ... (7 bytes))
Offline


Aktuell habe ich 3 Geräte im Heimnetz. Obwohl 2 weitere S20 im Netz sind (anpingbar), wird nur 1er online angezeigt.

Das Problem entstand wieder nach einem WLAN-Kanalwechsel.

Wie kann ich erreichen, dass wenn die Geräte offline sind, der MQTT2-Server wieder gestartet wird um die Kommunikation wieder aufzunehmen ?

KeepAlive habe ich zwar im MQTT2-Device eingestellt (1.5) hat aber nicht geholfen, heute fehlen wieder 2 Geräte. Ist das System MQTT2 evt. unter FHEM noch nicht ausgereift ?

Beta-User

Kann es sein, dass die Node jeweils nach dem Kanalwechsel versucht, sich am Server neu anzumelden, das aber geblockt wird, weil die CID schon einmal vorhanden ist?
Dann müßte wohl MQTT2_SERVER die Verbindung jedenfalls dann von seiner Seite aus kappen (bzw. die CID wieder zulassen), wenn die LWT-Zeit abgelaufen ist (ggf. auch vor Ablauf des keepAlive-Faktors, um unnötige Events zu vermeiden)? (Kann aber sein, dass ich das ganze völlig falsch interpretiere...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sledge

Auch wenn es nur indirekt helfen wird: Die Fritzbox ist meiner Erfahrung nach nur bedingt für IoT Devices geeignet (ohne eine Grundsatzdiskussion lostreten zu wollen).

Seit Umstellung auf ein vernünftiges Wifi sind all solche Probleme aus meiner Installation verschwunden - auch Kanalwechsel oder Roaming auf andere Access Points bringt meine MQTT-Devices (und alles andere im WLAN) nicht mehr aus dem Tritt.

Die MQTT-Implementierung in FHEM ist (für mich) so gut, dass ich diesen Sommer alles von mosquitto auf MQTT2 migriert habe - und diesen Schritt habe ich nicht bereut. Deutlich weniger Seiteneffekte.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Rainer82

Wie kann der MQTT2-Server neu initialisiert werden ? evt. würde das ja helfen und ich könnte den Neustart vom "Offline"-Zustand abhängig machen ...

Rainer82

Keiner hier, der das Problem kennt oder weiterhelfen kann ?

rudolfkoenig

ZitatWie kann der MQTT2-Server neu initialisiert werden ?
Mit "delete TYPE=MQTT2_SERVER:FILTER=TEMPORARY=1" kann man alle MQTT2_SERVER Verbindungen zumachen. Ob das hilft, kann ich nicht sagen.

ZitatKann es sein, dass die Node jeweils nach dem Kanalwechsel versucht, sich am Server neu anzumelden, das aber geblockt wird, weil die CID schon einmal vorhanden ist?
Nein. Es gibt nur die Logik, dass beim Schliessen einer Verbindung kein lwt verbreitet wird, wenn eine weitere Verbindung mit der gleichen ClientID _und_ IP schon existiert.

Wenn es mit dem automatischen Kanalwechsel Probleme gibt: kann man den Kanal nicht auf einen Festen setzen?

Beta-User

@Rudi: Danke für die Rückmeldung, hatte schon vermutet, dass das "sauber" ist...

@Rainer82:
Wie schon hier angemerkt wurde, ist allgemein bekannt, das Fritte und ESP8266 in größerer Anzahl keine gute Kombi sind.

Vielleicht kannst du was rausfinden, wenn du die Tasmota-Konsole bemühst. Könnte sein, dass darüber was rauszufinden ist, warum der Reconnect von der Tasmota-Seite aus nicht klappt: https://github.com/arendst/Tasmota/wiki/MQTT-Overview#troubleshooting

Ansonsten wären diverse Versionsangaben (Tasmota, Fritte, MQTT2_SERVER, fhem.pl....) usw. eventuell noch Infos, mit denen "Kundige" was anfangen können?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

c-graeser

Auch ich habe das Problem, dass die SonOff S20 sporadisch die Verbindung zum FHEM MQTT2 Broker "verlieren".
Man kann dann die Steckdose noch nicht mal mehr vom FHEM-Server aus anpingen.
Ein
netstat -n -A inet -t
hat mich auf die Fährte gebracht, dass 4 gleichzeitige Verbindungen von der selben Steckdose auf den MQTT2-Port 1883 des FHEM Servers  geöffnet waren.
Wie es zu den redundanten Verbindungen kommt weiss ich leider nicht.
Als WLAN-Router ist eine Fritzbox 7490 im Einsatz, als FHEM Server ein RasPi3.
Vielleicht helfen ja meine Erkenntnisse bei Debugging.
Eine Lösung, wie ich die gleichzeitigen Verbindungen beenden kann, habe ich im Moment noch nicht.
Raspberry Pi, HMUART, LaCrossGW, myJeeLink

wg25

Zitat von: c-graeser am 26 April 2020, 18:58:25
Auch ich habe das Problem, dass die SonOff S20 sporadisch die Verbindung zum FHEM MQTT2 Broker "verlieren".

Mir geht's genauso. Sporadisches Verlieren der Verbindung zum MQTT2 Server. Gibt's schon eine Lösung?

tomseitz320

Habt Ihr hierzu jetzt schon eine Lösung? Stehe gerade vor dem gleichen Problem...