Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MCU]

@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:

INFO ESPHome 2025.6.0b1
letzte LOG

Dein 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

[Homoran]

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

[MCU]

@wibear sagte in ESPHome ESP32-S3 mit MQTT verliert Verbindung:

Ersetze mqtt_subscribe probeweise durch on_message
und anschließendes LOG

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

[wibear]

@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

[wibear]

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

[wibear]

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

[MCU]

@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

Vielleicht kann @ticaki oder @Dutchman helfen?

[wibear]

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

[MCU]

@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:

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

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

[wibear]

@ticaki @Dutchman ESPHome ESP32-S3 mit MQTT verliert Verbindung:

Vielleicht kann @ticaki oder @Dutchman helfen?

Hallo zusammen, könnet Ihr vielleicht Euren Senf dazugeben?
Danke und Grüße

[wibear]

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

[MCU]

@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

[wibear]

@mcu
Danke, danke, werde ich morgen umsetzen…