Seltsames Verhalten von MQTT2_SERVER mit Tasmota-LWT

[Beta-User]

Vorab: Bei diesem Thread geht es mir nicht vorrangig darum, Hilfe zu erhalten! Dazu sind meine eigenen Vorarbeiten nicht ausreichend!

Anlass ist die Frage hier:

MQTT2_SERVER hat da bei mir z.B. ein Problem mit einem Tasmota, der (jetzt) im LAN hängt (der Vorgänger war mit demselben Symptom via WLAN eingebunden...)

(Ähnliches gilt für den AHOY-DTU-ESP32, mit dem meine PV-Inverter abgehorcht werden)

Beides find ich interessant. Hattest Du dazu mal irgendwo mehr Hintergrund geteilt?

Also:

Was den Tasmota angeht: Der einzige zwischenzeitlich hier noch eingesetzte Tasmota-ESP hängt am Stromzähler - zweckentsprechend mit einer speziellen Tasmota-Firmware mit scripting für SML. "Früher" war das mal ein ESP01-Komplettgerät aus der Bucht, verbaut im OG. Grottige WLAN-Werte, bei der auch die dann angelötete externe (Folien-) Antenne nicht viel geholfen hat.

Dementsprechend gab es häufiger (echte) Verbindungsabbrüche, so dass das wenig geeignet war, zuverlässig den eigentlichen Zweck zu erfüllen (Regelung eines Hoymiles-Inverters hinter einem Akku, angesteuert über AHOY-DTU). (Der "alte" ZWave-Zangen-Sensor hat auch nicht viel geholfen, weil der nur positive Werte kannte...)

Heute befindet sich der Stromzähler im UG, wo allgemein der WLAN-Empfang noch schlechter ist. Weil ich "sowieso" zusätzlich u.a. noch den Solar-Thermie-Controller auswerten wollte, ist das ganze aktuell ein "fliegender Aufbau" aus einem TTL-Kopf mit abgesetztem ESP32 (WT32_ETH01-Board), verbunden via LAN. Auch auf dem lief früher eine (komplett-) Eigenbau-firmware. Nachdem zwischenzeitlich aber auch die Heizung getauscht ist, ist auch die Thermie umgebaut, was einen anderen Controller erforderlich gemacht hat...

OT-Zwischenbemerkung:
Die ganzen Änderungen aus den letzten Jahren sind nur zum Teil FHEM-seitig vollständig integriert. Es ist zwar "im Prinzip" alles funktional, teils mit Zwischen- und Übergangslösungen und ohne logging etc., aber es gibt so viele Details, die "man sich mal ansehen sollte", dass ich mich jeweils auf den Teil beschränke, der mir grade am "wichtigsten" erscheint, der Rest muss warten...

Back to Topic:
Da das mit dem Akku sowieso nicht so geklappt hat, wie mal gedacht, ist dieser Teil jüngst einer Fertiglösung gewichen (Solakon One), und auf dem Tasmota läuft eine firmware, die nebenbei einen Shelly imitiert (https://github.com/ottelo9/tasmota-sml-images - sehr zu empfehlen, man muss im Prinzip nur noch wissen, welchen Zähler man verbaut hat und auf welchen GPIO die IR-Schnittstelle hängt!), damit der Solakon weiß, was zu tun ist.

Was ich jetzt feststelle:
Mein "LWT"-offline notify sendet weiter unerwartet häufig Benachrichtigungen, dass der Tasmota offline wäre.
Tatsächlich erhält aber der Solakon weiter aktuelle Daten, so dass ich davon ausgehe, dass weder eine wackelige Stromversorgung schuld ist, noch die firmware, noch das Netzwerk.

"Der Hund" scheint irgendwo auf der MQTT-Strecke zwischen dem ESP und dem FHEM-Server begraben zu sein. Die eigentliche Server-Performance dürfte es auch nicht sein (i5 der 8. Gen. mit 32GB RAM), aber ausschließen mag ich auch nicht, dass FHEM hin und wieder just zu der Zeit mit was anderem beschäftigt ist, wenn der Tasmota sich meldet... 

Wie eingangs geschrieben: Meine Erwartung ist nicht unbedingt, sachdienliche Hinweise zu bekommen, im Moment dient mir das nur als (etwas nervende) Erinnerung, dass die eigentliche Ursache noch nicht gefunden ist...

[rudolfkoenig]

Falls im FHEM-Log nichts steht wg. "keepalive check", dann habe ich die ESP Seite in Verdacht.
Um sicher zu gehen wuerde ich pruefen, ob das Problem auch mit mosquitto/MQTT2_CLIENT besteht.