[geklärt] Tasmota / ESP-LWT seltsam, wohl nicht zuverlässig

[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.

[Beta-User]

Da steht durchaus ordnungsgemäß was, hier mal die drei ersten (von 10) keepalive-Meldungen im aktuellen Log:

Code Auswählen Erweitern

2026.07.26 03:10:20 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.105_63030/DVES_75CA94 left us (keepalive check)
2026.07.26 11:29:38 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.105_63032/DVES_75CA94 left us (keepalive check)
2026.07.26 19:33:44 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.105_63035/DVES_75CA94 left us (keepalive check)
Was auffällt: die Verbindungszahl hinten weist (fast immer) Lücken auf, typisch sind 2-3 Neuverbindungen zwischendurch.

(den keepalive-Faktor am Server wollte ich nicht allgemein hochdrehen).

Wie vorgeschlagen ist das jetzt auf mosquitto umgestellt, mal sehen, ob das da auch auftritt.

[TomLee]

Was steht denn im Log von Tasmota?
Gibts ein WIFI: Connected/Disconnected oder nur ein MQTT-Reconnect ohne WLAN-Abbruch?

Meine Vermutung: nur MQTT-Reconnect, weil das Skript blockiert.

[Beta-User]

Gibts ein WIFI: Connected/Disconnected oder nur ein MQTT-Reconnect ohne WLAN-Abbruch?

Logging war bisher nicht aktiviert, und In /cs? hatte ich bisher auch nicht geschaut, der Abbruch kam ja auch nur "sporadisch" (und manchmal tageweise nicht...).

Am WLAN liegt es sicher jetzt nicht mehr: Das Ding hat einen LAN-Port, unter "Information" ("/in?") steht überall (eth) dahinter wie hier: "IP Address (eth)" .
_________________

Ist zwar noch keine Zeit seit der Umstellung auf mosquitto, aber innerhalb der jetzigen uptime von knapp 2h kamen bisher keine Meldungen.

[TomLee]

Ich sehe Parallelen zu meinem ePaper-Projekt, welches mich dieses Jahr gepackt hat und das ich vor rd. 2 Jahren bei dir angesprochen hatte.
Ich habe die BW-Displays jetzt mit einem ESP (32-C6) am Laufen. Alle BWR sind mittlerweile geschrottet ☹️
Wenn dort der BUSY-Pin hängt, dann ist der ESP weiterhin via WLAN verbunden (zumindest sehe ich keinen Abbruch oder keine Neuverbindung im seriellen Monitor), MQTT2_SERVER setzt nach der versprochenen Zeit aber auf offline. Fängt sich der Pin wieder, findet die auch die MQTT-Verbindung wieder statt.

[Beta-User]

Um sicher zu gehen wuerde ich pruefen, ob das Problem auch mit mosquitto/MQTT2_CLIENT besteht.

So ist es.
5 Meldungen heute Nacht binnen ca 1,5h, die letzte halbe Stunde dann nochmal 3. Uptime des ESP passt zum reboot gestern Nachmittag.

Da das Symptom über der Zeit seit Anfang 2023 mind. 4 ESPs (2*8266-01, 2*WT32_ETH01) und 4 Hauptversionen von Tasmota sowie einen Wechsel der Server-Hardware und Umbau der Netzwerk-Infrastruktur überlebt hat, klingt das nach einem Problem der Firmware bzw. der dortigen scripting-Engine.

Mal sehen, vielleicht hole ich mal eine Standard-Tasmota-Steckdose aus der Gruschtelkiste... Hat aber keine Priorität.

[frober]

Ich denke, das ist ein ESP-Problem.

Meine Shelly 2.5 Gen1 als Rolladenaktor verhalten sich auch so, unabhängig von der Empfangsqualität.

Des Weiteren habe ich seit kurzem einen ESP32 mit PhoneBlock-FW direkt auf der Fritte liegen. Laut Log immer wieder Verbindungsabbrüche.

[passibe]

Habe keinen LAN-ESP, aber vielleicht könnt ihr mal den Traffic mitschneiden? Eventuell sieht man dort irgendwas, was zu den Verbindungsabbrüchen führt.

Oder mal ein Issue auf GitHub aufmachen ...

[Beta-User]

Ich denke, das ist ein ESP-Problem.

Bin bis auf weiteres geneigt, das mit den von dir geschilderten Erfahrungen als solches abzuhaken.

Wie eingangs geschrieben: Es ging mir vorrangig darum, eine gestellte Frage zu beantworten, v.a. da ich (ohne groß danach gesucht zu haben) mangels mir bekannter ähnlicher Berichte davon ausging, dass ich mehr oder weniger der einzige wäre, bei dem das auftritt...

Wenn dem nicht so ist, ist das ein Argument mehr, v.a. auf WLAN-ESP's möglichst zu verzichten. Ich hoffe nur, dass das nicht auch ein Thema ist, das auch im ZigBee-Stack der (mutmaßlich einigermaßen häufig verbauten) ZigBee-Varianten zu finden ist.

[frober]

Wenn man's Inet durchstöbert, gehen die Erfahrungen auseinander...

Die Ursache wird meist auf Stromversorgung und/oder den (selbstgeschriebenen) Sketch geschoben.

Ich meine wir hatten das Thema hier auch schon, zumindest bei den "ersten" ESP8266. Da wurden Pufferkondensatoren an den Eingang der Stromversorgung gelötet.

Die ESP ziehen im Moment der Wlankommunikaktion ein vielfaches vom Strom. Wenn da die Spannungsversorgung nicht nach kommt gibt es Probleme.
Ob das bei Lan genauso ist, weiß ich nicht.

Das erklärt aber nicht, warum LWT auf offline steht obwohl die ESPs erreichbar sind.

[Beta-User]

Das erklärt aber nicht, warum LWT auf offline steht obwohl die ESPs erreichbar sind.

Das ist eigentlich eine einfache Timer-Funktionalität auf der Server-Seite: Der jeweilige client meldet, wann er gedenkt, sich wieder (imo auf diesem Topic!) zu melden. Bleibt das aus, ist er "offline", obwohl ggf. andere Messages eingehen. Ist also sehr anders, als die ähnlich wirkende "alive" Funktionalität, die in MYSENSORS_DEVICE verbastelt ist (oder was in CUL_HM per actiondetector läuft).

Meine simple Interpretation: Es geht schlicht hin und wieder was verloren, man kann sich nicht darauf verlassen, dass der Status dieser Hardwares tatsächlich "korrekt" ist... (!). Solange es "nur" um einen Sensor geht, der sowieso sehr häufig sendet (wie das jetzt der SML-ESP ist), ist mir das eigentlich egal.

Ansonsten sehe ich sowieso meine (negative) Haltung zu ESP-basierten WLAN-Geräten einmal mehr bestätigt. Blöd nur, dass das auch zu gelten scheint, wenn die ESP's am Kabel hängen. Das Netzteil würde ich übrigens in dem Fall eher für ausreichend erachten (Hutschienenmodell mit 15W oder mehr). Ob die Beschaltung auf dem WT32_ETH01 ggf. zu schmal ist, kann ich schlecht prüfen, habe aber angesichts fehlender Dringlichkeit auch nicht die Neigung, dem intensiver nachzugehen. 

Allerdings werde ich wohl zwei Dinge tun:
1. Der SML_ESP kommt wieder nach MQTT2_SERVER. Der scheint in der Hinsicht etwas toleranter (=wartet länger) zu sein wie mosquitto.
2. Bisher hatte ich meinen (einzigen?) anderen ESP (die Ahoy-DTU) nicht (mehr?) in der Überwachung drin. Werde das vermutlich auch ändern und/oder das ganze dann auch noch auf die eigentlich dafür gedachte Hardware umziehen (aktuell noch ein ziemlich schlampig zusammengelöteter Eigentbau auf ESP32-Basis, die "comunity-plattform" auf ESP32-S3-Basis liegt aber schon länger im Eck...).

[frober]

Das ist eigentlich eine einfache Timer-Funktionalität auf der Server-Seite: Der jeweilige client meldet, wann er gedenkt, sich wieder (imo auf diesem Topic!) zu melden. Bleibt das aus, ist er "offline", obwohl ggf. andere Messages eingehen.

Soweit ist mir das klar, allerdings bin ich davon ausgegangen, dass wenn die nächste Nachricht kommt, LWT wieder auf online geht.

Wenn das nicht funktioniert, bzw. sich die Clients nicht an die Regeln halten, wechsle ich ich zu ReadingsWatcher den ich eh schon nutze.

P.S. habe heute gesehen, dass mein Sonoff POW mit Tasmota V5.13 auch auf offline steht, obwohl er funktioniert.

[Beta-User]

Das ist eigentlich eine einfache Timer-Funktionalität auf der Server-Seite: Der jeweilige client meldet, wann er gedenkt, sich wieder (imo auf diesem Topic!) zu melden. Bleibt das aus, ist er "offline", obwohl ggf. andere Messages eingehen.

Soweit ist mir das klar, allerdings bin ich davon ausgegangen, dass wenn die nächste Nachricht kommt, LWT wieder auf online geht.

Nach meinem Verständnis geht es da immer nur um Nachrichten, die als "last will" gekennzeichnet sind (und eben mit einer "Lebensdauer" versehen sind).

Hintergrund nach meinem Verständnis: der Server sorgt nur dafür, dass immer jeweils nur ein Client mit derselben ID angemeldet ist, aber ansonsten ist dem das herzlich egal. Anders gesagt: "üblicherweise" interessiert es keinen, welche Topics zu welchem Client gehören (oder welche konkrete Hardware da ihr Testament gemacht hat...)

$CID wird total überbewertet, wie ich heute an anderer Stelle schon angemerkt hatte!

Wenn das nicht funktioniert, bzw. sich die Clients nicht an die Regeln halten, wechsle ich ich zu ReadingsWatcher den ich eh schon nutze.

Bzgl. der Aktualität von Readings mache ich das auch schon lange so, für die Frage, ob eine Verbindung zu einem bestimmten Client etc. steht, wollte ich "eigentlich schon immer" mal mehr mit "monitoring" spielen.

War bisher nicht wichtig genug...

P.S. habe heute gesehen, dass mein Sonoff POW mit Tasmota V5.13 auch auf offline steht, obwohl er funktioniert.

Eine (firmware-) Antiquität, sieh an! Danke für die Info, dass das offenkundig sehr viel verbreiteter ist, als die (nicht zuverlässig funktionierende) Funktionalität an sich vermuten lassen würde.