Pro

Mag jetzt eine Dumme Frage sein: Warum ist der Gemini API Key zwingend nötig?

@gargano

Die Antwort wird hier nicht kommen, da es nicht am Script liegt. Wenn der Adapter ins Stable wechselt wird auch das Script funktionieren.

@mcu
Danke, danke, werde ich morgen umsetzen…

@tt-tom wollt ja nur wissen, ob das schon gefixt ist. Ansonsten warte ich halt auf den Fix.

@gargano
Wenn du mit einer Beta Version vom Javascript Adapter arbeitest, musst du mit so etwas rechnen.
Weitere Infos findest du im Testpost zum Adapter.

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

@codierknecht genau, ich fürchte, das wird noch schlimmer werden. Finanziell ist das eine als Bürger, aber der Schaden am Klima durch diese falsche Politik ist noch viel schlimmer

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