Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

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