Problem "keepalive check" nach Umstellung auf MQTT2_SERVER

Begonnen von HansDampfHH, 15 Mai 2021, 15:12:49

Vorheriges Thema - Nächstes Thema

HansDampfHH

Hallo, ich habe mittlerweile mein Setup aktualisiert und zigbee2mqtt aktualisiert, das XiaomiMQTTDevice entfernt und durch MQTT2-Server/Device ersetzt.
War einiges an Arbeit, aber mittlerweile läuft alles zufriedenstellend.

Ein Problem habe ich allerdings noch:
Ich habe hier ein paar nodeMCU in der Wohnung verteilt mit entsprechenden Sketches (Pir, Photoresistor, DHT11).
Die funken natürlich auch weiterhin an den MQTT Server, Daten kommen auch an.
Allerdings läuft in meinem Log nun leider folgende Meldung auf:

Zitat
MQTT2_Server: MQTT2_Server_192.168.148.63_65036/ESP8266Client left us (keepalive check)

Hat jemand einen Hinweis, wie ich bei solch einem Konstrukt verfahren muss?
Kann der Sketch sich auch wieder "abmelden" wenn er published hat oder wie ist der richtige Weg?

Alle anderen Devices (Xiaomi, Aqara, Tasmota) haben diesbezüglich keine Meldungen.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

Beta-User

Works as designed, siehe z.B. auch https://forum.fhem.de/index.php/topic,120902.0.html.

Du hast afaik zwei Optionen: Entweder im Sketch (oä.) eine passende "keep alive periode" angeben, oder nach dem Senden dann eine saubere Abmeldung durchführen. Würde für den ersten Weg votieren.
Der Log-Eintrag kommt jedenfalls, wenn sich der Client (ESP) nicht innerhalb der 1,5-fachen Zeit meldet, die er angekündigt hat (der Faktor ist afaik konfigurierbar, aber dann eben für alle gültig)
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

HansDampfHH

Ja, die Info dass das Verhalten so korrekt ist hatte ich bereits gefunden.
Mir war nicht klar, ob ich auf FHEM-Seite noch eine Option habe für entsprechende Devices das Verhalten zu ändern/abzustellen.

Aber dann muss ich mir noch mal die Sketche ansehen und schauen was bzw. wie das geht.
Besten Dank!
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

rudolfkoenig

Das Problem ist auf der Client Seite zu fixen: Entweder nicht behaupten, dass man alle X Sekunden sich melden wird (aka keepalive), oder sich dran halten, und sich alle X Sekunden melden.

HansDampfHH

Ja, ist natürlich richtig. War vor 5 Jahren noch nicht ganz klar ;-)

Ich push ja nur alle 10 Minuten den state, da muss ich die Verbindung nicht unbedingt halten.
War jetzt so das einfachste: client.disconnect();

Meldungen weg, danke !
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink