NEWS
ESPHome ESP32-S3 mit MQTT verliert Verbindung
-
@wibear Bitte als Code
</>
senden .
Ich kann Dir nicht im Detail helfen, wollte mit den Antworten von ChatGPT nur ein Anstoß geben.
Damit ich es an ChatGPT weitergeben kann bitte als Code schicken. -
@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
INFO ESPHome 2025.6.0b1
letzte LOGDein ESPHome-Log zeigt, dass der MQTT-Client auf deinem ESP32-S3-Board regelmäßig Verbindungsprobleme hat, nachdem MQTT-Subscribe-Textsensoren aktiviert wurden. Hier ist eine Analyse der Ursache und mögliche Lösungen:
🧠 Problemüberblick
Der entscheidende Fehler lautet:python-repl
Kopieren
Bearbeiten
mqtt_message_receive: received a message with an invalid header=0x39
...
MQTT_EVENT_ERROR
...
Client has not connected
Das bedeutet:Der ESP empfängt fehlerhaft formatierte MQTT-Nachrichten (ungültige Header).
Danach bricht die Verbindung ab oder wird als instabil markiert.
Die Verbindung wird ständig neu aufgebaut (Connected, dann wieder Client has not connected usw.)
🧪 Wahrscheinliche Ursachen
1. Fehlende oder falsche Payloads für mqtt_subscribe-Sensoren
Dein ESP erwartet Textnachrichten auf z. B. folgendem Topic:topic: esphome/DisplayTFT/Status/Batterie_SoC
Wenn hier z. B. ein anderer MQTT-Client binäre Daten, JSON, oder nicht-lesbaren Text sendet, kann das zu einem ungültigen MQTT-Header führen.
️ Das passiert häufiger mit ioBroker oder Node-RED, wenn z. B. msg.payload nicht als einfacher String gesendet wird.
2. Mismatch zwischen Publisher und ESPHome-Abo
Beispiel: Wenn mqtt_subscribe einen Textsensor erwartet, aber das Topic z. B. retain-Nachrichten mit falschem Format enthält (z. B. boolean statt String), stürzt der MQTT-Parser im ESP ab.Lösungsvorschläge
️ 1. Überprüfe die Payloads auf den Topics
Nutze MQTT.fx, MQTT Explorer o. ä., um z. B. das hier zu prüfen:esphome/DisplayTFT/Status/Batterie_SoC
esphome/DisplayTFT/Solar/Einspeisung_Jetzt
usw.
Stelle sicher, dass ausschließlich gültige Textwerte (Strings) gesendet werden, z. B.:
"33.2" "An" "Aus"
Nicht:
true // → falscher Typ {...} // → JSON-Objekt, falsch "some\ninvalid\0text" // → ungültige Steuerzeichen
️ 2. Teste das MQTT-Abonnement temporär mit nur einem mqtt_subscribe
Kommentiere alle text_sensor außer einem:text_sensor: - platform: mqtt_subscribe id: Test_Topic topic: esphome/DisplayTFT/Test
Dann sende gezielt gültige Testwerte und schau, ob der ESP stabil bleibt.
️ 3. MQTT-Log im Broker aktivieren
In ioBroker (wenn du Mosquitto nutzt), aktiviere Debug-Logs, um zu sehen, was genau an den ESP gesendet wird. Es hilft dir auch, retain-Werte zu analysieren.️ 4. ESPHome auf Arduino statt ESP-IDF framework setzen
Der Fehler tritt in der esp-idf MQTT-Client-Implementierung auf:esp32: framework: type: arduino # ← statt "espidf"
→ Arduino verwendet eine robustere MQTT-Client-Bibliothek für einfache Fälle.
Fazit
Dein ESP32-S3 erhält MQTT-Nachrichten mit ungültigen Inhalten oder Format, was zu instabiler Verbindung führt. Am wahrscheinlichsten sind:Falsches Datenformat im MQTT-Topic
Binärdaten oder Nicht-Strings bei mqtt_subscribe
Fehlerhafte retain-Nachrichten aus früheren Tests
-
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Ich kann Dir nicht im Detail helfen
aber vielleicht mir
geht es um ESP Home = offTopic - microcontroller oder um den ESP-Home Adapter?
Die
@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Entwickler von ESPHome
wären ja ganz woanders zu suchen.
-
@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Ersetze mqtt_subscribe probeweise durch on_message
und anschließendes LOGDas ist eine sehr gute Nachricht: Dein ESP32-S3 funktioniert jetzt stabil mit den mqtt_subscribe-Textsensoren, nachdem du den ESPHome-Code erfolgreich neu kompiliert und geflasht hast. Du musst on_message offenbar nicht als Workaround einsetzen – die ursprüngliche mqtt_subscribe:-Konfiguration läuft jetzt fehlerfrei.
Was ist passiert?
Dein aktueller Log zeigt:Verbindung bleibt stabil
Alle text_sensor vom Typ mqtt_subscribe empfangen korrekt ihre Werte
Keine Abbrüche oder MQTT-Fehler
Sogar die boot loop counter-Logik wurde erfolgreich zurückgesetzt → kein Crash oder Absturz mehr
🧠 Vermutliche Ursache vorher
Basierend auf deinem vorherigen Problemverlauf war wahrscheinlich einer dieser Punkte ausschlaggebend:Falsche oder beschädigte MQTT-Nachricht (z. B. nicht lesbarer Header bei retained topics)
Framework oder ESPHome-Version war nicht 100 % kompatibel
Früherer mqtt_subscribe-Sensor war nicht korrekt definiert (z. B. Tippfehler oder ungültige Zeichen)
Empfehlung
Da es jetzt läuft:Lass mqtt_subscribe aktiv – du brauchst on_message nicht.
Falls du einzelne Topics manuell steuerst (z. B. aus ioBroker), achte immer darauf, nur gültige Textwerte (Strings) zu veröffentlichen.
Bonus: Retained-Messages prüfen
Wenn du wieder auf Probleme stößt: Nutze MQTT Explorer oder einen MQTT-Client, um retained Topics zu prüfen und bei Bedarf zu löschen – ungültige Daten bleiben sonst dauerhaft im Broker. -
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Bitte als Code </> senden
esphome: name: displaytft friendly_name: DisplayTFT esp32: board: esp32-s3-devkitc-1 framework: type: esp-idf # Enable logging logger: # Enable Home Assistant API api: encryption: key: "oLqhzrUCfhqRKZXIH6+wajtLeBwaVt03e/YAfM8woSU=" ota: - platform: esphome password: "0cb05a749c68876ca294cc4b645222ca" wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Displaytft Fallback Hotspot" password: "O4s50tPm0qCc" captive_portal: # Enable MQTT mqtt: discovery: true broker: 192.168.178.10 port: 1883 username: !secret mqtt_username password: !secret mqtt_password client_id: DisplayTFT topic_prefix: esphome # Subscribe data sensor: - platform: mqtt name: Solar_Einspeisung_Jetzt state_topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt
-
@mcu
In meinem vorherigen Post habe ich die topics überprüft: sie scheinen alle die Daten zu liefern.
Debug in MQTT habe ich jetzt aktiviert.@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Arduino verwendet eine robustere MQTT-Client-Bibliothek für einfache Fälle.
Da war doch ursprünglich Arduino. Ich habe auf Deinen Vorschlag hin, das mit ESP-IDF versucht: keine Änderung.
-
@homoran sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
eht es um ESP Home = offTopic - microcontroller oder um den ESP-Home Adapter?
Klar, es geht um ESP-Home Adapter...
-
@wibear Es sind Antworten von ChatGPT, da kann man nur probieren.
Du nutzt in deinem aktuellen ESPHome YAML folgenden Block:
sensor: - platform: mqtt name: Solar_Einspeisung_Jetzt state_topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt
Das sieht fast korrekt aus – aber ein wichtiger Hinweis:
️ mqtt als sensor-Plattform wird von ESPHome nicht unterstützt
ESPHome unterstützt keine direkte Verwendung von:platform: mqtt
für einen Sensor. Das ist ein Feature von Home Assistant, nicht ESPHome.
Was stattdessen funktioniert in ESPHome
Du musst den mqtt_subscribe-Ansatz nutzen:Beispiel für einen mqtt_subscribe Sensor als text_sensor:
text_sensor: - platform: mqtt_subscribe id: solar_einspeisung_jetzt name: "Solar Einspeisung Jetzt" topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt
Falls du numerische Werte brauchst, kannst du zusätzlich einen internen Sensor anlegen, der den Text in eine Zahl wandelt (z. B. über einen Lambda-Ausdruck).
🧠 Alternativen (nur in Sonderfällen nötig)
Wenn du wirklich aus ESPHome heraus jede beliebige MQTT-Nachricht abfangen und verarbeiten willst, kannst du on_message mit mqtt.on_message verwenden (fortgeschritten):mqtt: on_message: - topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt then: - lambda: |- ESP_LOGD("mqtt", "Nachricht: %s", x.c_str());
Aber: Damit kannst du nicht direkt einen Sensor erzeugen, sondern musst die Werte selbst puffern/verarbeiten.
Empfehlung für dich
Wenn du die Daten wie üblich über MQTT übergibst und im Display zeigen willst:Nutze mqtt_subscribe (wie oben)
Bleibe bei text_sensor, es sei denn, du brauchst einen sensor mit float-Werten (dann: Lambda wandeln)
Lass framework: esp-idf aktiv, wenn jetzt alles stabil läuft
Komplettbeispiel von ChatGPT
esphome: name: displaytft friendly_name: DisplayTFT esp32: board: esp32-s3-devkitc-1 framework: type: esp-idf # Enable logging logger: # Enable Home Assistant API api: encryption: key: "oLqhzrUCfhqRKZXIH6+wajtLeBwaVt03e/YAfM8woSU=" ota: password: "0cb05a749c68876ca294cc4b645222ca" wifi: ssid: !secret wifi_ssid password: !secret wifi_password ap: ssid: "Displaytft Fallback Hotspot" password: "O4s50tPm0qCc" captive_portal: mqtt: discovery: true broker: 192.168.178.10 port: 1883 username: !secret mqtt_username password: !secret mqtt_password client_id: DisplayTFT topic_prefix: esphome # 🔹 Schritt 1: Text-Sensor, empfängt MQTT-String text_sensor: - platform: mqtt_subscribe id: solar_einspeisung_jetzt_text topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt internal: true on_value: then: - lambda: |- // 🔹 Schritt 2: Text in float umwandeln und setzen float val = atof(x.c_str()); id(solar_einspeisung_jetzt_sensor).publish_state(val); # 🔹 Schritt 3: Eigener float-Sensor, der aus Text gespeist wird sensor: - platform: template id: solar_einspeisung_jetzt_sensor name: "Solar Einspeisung Jetzt" unit_of_measurement: "W" accuracy_decimals: 1
-
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Lass framework: esp-idf aktiv, wenn jetzt alles stabil läuft
Das Problem ist, dass es eine kurze Weile läuft und danach nicht mehr mit unzähligen Warnmeldungen:
Ich überlege es mir, eine 2. MQTT Instanz extra dafür zu benutzen?
Auf jeden Fall vielen Dank für Deine Unterstützung und einen schönen Sonnabend.
-
@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Das Problem ist, dass es eine kurze Weile läuft und danach nicht mehr mit unzähligen Warnmeldungen:
Danke für den Hinweis – wenn der ESP nach kurzer Laufzeit unzählige Warnungen ausgibt und die MQTT-Verarbeitung stoppt, liegt sehr wahrscheinlich ein Speicher- oder Ressourcenproblem vor, vor allem bei vielen mqtt_subscribe-Topics und gleichzeitiger Verarbeitung über Lambda-Funktionen.
🧠 Mögliche Ursachen für dein Problem:
- Zu viele MQTT-Subscriptions
ESPHome (besonders auf dem ESP32-S3 mit esp-idf) ist bei vielen mqtt_subscribe-Textsensoren empfindlich, insbesondere wenn:
Jeder Sensor in kurzer Zeit aktualisiert wird
Viele Topics gleichzeitig abonniert sind
Jede Nachricht per lambda ausgewertet wird (wie bei der Float-Umwandlung)
→ Das kann den Task-Speicher oder den MQTT-Handler überlasten.
- Fehlende Speicherfreigabe / Buffer-Überlauf
Der on_value:-Lambda legt ggf. bei jeder MQTT-Nachricht einen Float-Wert an, ohne Pufferung oder Zeitabstand → das kann zu einer Flut von Speicheroperationen führen, besonders bei vielen Topics mit hoher Update-Rate.
Lösungsvorschläge (step-by-step)
1. Begrenze Anzahl gleichzeitig aktiver mqtt_subscribe-Sensoren
Teste probeweise nur mit 2 oder 3 Topics, z. B.:text_sensor: - platform: mqtt_subscribe id: test_1 topic: esphome/DisplayTFT/Test1 on_value: then: - lambda: |- id(sensor_test_1).publish_state(atof(x.c_str()));
2. Füge Logging bei jedem Empfang hinzu (nur Debugzwecke)
logger: level: DEBUG
Oder in der Lambda:
cpp
ESP_LOGD("mqtt", "MQTT-Wert empfangen: %s", x.c_str());
Damit siehst du, ob Nachrichten zu oft oder zu schnell kommen.
3. Füge einen Filter hinzu, um nur Werte zu publizieren, wenn sie sich wirklich ändern
on_value: then: - lambda: |- float val = atof(x.c_str()); if (fabs(val - id(sensor_test_1).state) > 0.1) { id(sensor_test_1).publish_state(val); }
Das reduziert die Anzahl der publish_state()-Aufrufe und entlastet die CPU.
4. Nutze dedizierte text_sensor nur für Strings, und fasse Daten ggf. zusammen
Wenn du z. B. mehrere Werte gleichzeitig senden kannst (z. B. JSON wie {"solar": 82.5, "netz": 71.2}), kannst du:einen einzigen mqtt_subscribe verwenden
und die Werte intern verteilen
Alternativ (stabilster Weg): on_message: zentral verwenden
Anstelle von 15× mqtt_subscribe, kannst du mit mqtt.on_message: alle Nachrichten zentral verarbeiten:mqtt: on_message: - topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt then: - lambda: |- float val = atof(x.c_str()); id(sensor_solar).publish_state(val); sensor: - platform: template id: sensor_solar name: "Solar Einspeisung Jetzt"
→ Spart massiv Ressourcen und ist deutlich robuster.
Fazit
Wenn du viele MQTT-Werte brauchst und es stabil bleiben soll:Verwende lieber mqtt.on_message zentral statt viele mqtt_subscribe.
Begrenze Aktualisierungsfrequenz und publish_state-Events.
Optional: aggregiere Daten in JSON-Form.
- Zu viele MQTT-Subscriptions
-
@ticaki @Dutchman ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Hallo zusammen, könnet Ihr vielleicht Euren Senf dazugeben?
Danke und Grüße -
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Teste probeweise nur mit 2 oder 3 Topics, z. B.:
Das habe ich schon auch ausprobiert: immer dasselbe...
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Zu viele MQTT-Subscriptions
Deswegen musste ich extra ESP32-S3 mit PSRAM nehmen.
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Füge Logging bei jedem Empfang hinzu (nur Debugzwecke)
Gute Idee, mache ich.
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Füge einen Filter hinzu, um nur Werte zu publizieren, wenn sie sich wirklich ändern
Sehr gute Sache, mache ich auch.
@mcu sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Verwende lieber mqtt.on_message zentral statt viele mqtt_subscribe.
Muss ich erstmal rausbekommen, wie das geht...
-
@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:
Muss ich erstmal rausbekommen, wie das geht...
Super Entscheidung – die zentrale Nutzung von mqtt.on_message: ist deutlich effizienter und stabiler, vor allem bei vielen Topics. Ich zeige dir jetzt, wie du das sauber aufbaust:
Zentrales MQTT-Handling mit mqtt.on_message
Statt für jeden Wert einen eigenen mqtt_subscribe zu verwenden, fängst du alle Nachrichten in einem zentralen Block ab – und entscheidest dann per topic, was damit passiert.Beispiel: Zwei MQTT-Werte zentral empfangen und verarbeiten
esphome: name: displaytft friendly_name: DisplayTFT esp32: board: esp32-s3-devkitc-1 framework: type: esp-idf logger: api: encryption: key: "DEIN_KEY" ota: password: "DEIN_PASSWORT" wifi: ssid: !secret wifi_ssid password: !secret wifi_password ap: ssid: "Displaytft Fallback Hotspot" password: "O4s50tPm0qCc" captive_portal: mqtt: broker: 192.168.178.10 username: !secret mqtt_username password: !secret mqtt_password client_id: DisplayTFT topic_prefix: esphome on_message: - topic: esphome/DisplayTFT/Solar/Einspeisung_Jetzt then: - lambda: |- float val = atof(x.c_str()); id(sensor_solar_einspeisung).publish_state(val); - topic: esphome/DisplayTFT/Netz/Verbrauch_Jetzt then: - lambda: |- float val = atof(x.c_str()); id(sensor_netz_verbrauch).publish_state(val); sensor: - platform: template id: sensor_solar_einspeisung name: "Solar Einspeisung Jetzt" unit_of_measurement: "W" accuracy_decimals: 1 - platform: template id: sensor_netz_verbrauch name: "Netz Verbrauch Jetzt" unit_of_measurement: "W" accuracy_decimals: 1 `` 💡 Erklärung Abschnitt Bedeutung mqtt.on_message: Fängt MQTT-Nachrichten für bestimmte Topics ab lambda: Verarbeitet den empfangenen Wert (x) atof(x.c_str()) Wandelt den Text in eine Zahl um template sensor Hält den aktuellen Float-Wert, damit du ihn anzeigen oder weiterverwenden kannst 🔁 Vorteile gegenüber mqtt_subscribe ✅ Kein RAM-Leak bei vielen Topics ✅ Bessere Performance ✅ Saubere zentrale Logik ✅ Keine 20× text_sensor, sondern alles an einem Ort
-
@mcu
Danke, danke, werde ich morgen umsetzen…