Het grote ESPhome topic

[Mad_Cow]

ik overweeg een e-ink display om te weten waar ik mijn auto heb geparkeerd.
display: seeedstudio epaper panel

- kan ik een kaart laten zien op zon scherm met GPS locaties? (zoals de standaard card in home assistant)
- ik zag wel een voorbeeld in de wiki om screenshots van een homeassistant dashboard te maken. dus dat zou een mogelijkheid zijn.

[Sp33dFr34k]

Ik zit op ESPHome 2025.6.0 en sinds deze versie krijg ik mijn Growatt yaml niet meer werkend...

code:

Error compiling growatt.yaml; Try again in ESPHome dashboard for more information.

In de ESPHome Device Builder, als ik 'm wireless wil installeren krijg ik:

code:

INFO ESPHome 2025.6.0
INFO Reading configuration /config/esphome/growatt.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing growatt (board: esp07s; framework: arduino; platform: platformio/espressif8266@4.2.1)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.3.0
|-- DNSServer @ 1.1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- noise-c @ 0.1.6
Compiling .pioenvs/growatt/src/esphome/components/api/api_pb2.cpp.o
Compiling .pioenvs/growatt/src/esphome/components/api/list_entities.cpp.o
xtensa-lx106-elf-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
xtensa-lx106-elf-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
========================== [FAILED] Took 6.08 seconds ==========================

EDIT: nevermind, was een RAM issue. Ik had de HAOS VM 4GB met ballooning aan op 1GB. Ballooning uitgezet en alles is opgelost.

[ Voor 41% gewijzigd door Sp33dFr34k op 23-06-2025 16:44 ]

[alex3305]

Nadat ik toch redelijk uit het veld geslagen was door de problemen met mijn ESP32-C6 bordjes heb ik zondag de draad weer opgepakt. TL:DR, ik kreeg die krengen totaal niet stabiel werkend. Deze bordjes vielen minimaal eens per uur compleet weg, maar ze rebootten niet .

Ik vond gister deze Github post met een plaatje van tekst . In deze afbeelding stond echter dat de Firebeetle - die lijkt op de door mij gebruikte Beetle Mini - het stukken beter deed met een lagere wifi output power. Ik heb dit dus gisteren aangepast:

YAML:

# Connect to WiFi
wifi:
  ssid: ${wifi_ssid}
  password: ${wifi_password}
  domain: ${wifi_domain}
  output_power: 12dB

Dit heeft ervoor gezorgd dat het apparaat nu al 15 uur stabiel is:



Het was ook puur de wifi verbinding die problemen had, ongeacht waar ik het apparaat plaatste ten opzichte van het AP. In het Unifi dashboard lijkt het niet drastisch verbeterd te zijn, maar dat is het dus wel.



Ik heb echt het idee dat er iets gaars aan de hand is met dit bordje. Ik heb momenteel nog één andere ESP32. Een M5Stack Atom Lite. Maar die valt maar eens per dag (heel kort) weg. De Unifi stats zijn daarvan echter veel slechter, maar ligt ook verder weg:



Dat zegt dus ook niet alles.

In ieder geval lijkt dit nu redelijk goed te gaan. Binnenkort wil ik ook gaan testen met een tweede bordje om te kijken hoe deze zich gedraagt.

Dit bordje is overigens wel echt loaded. Met name voor een ESP32-C6 . Ik heb hier nu LD2410, PM1006, BMP280, CCS811, SCD40 sensoren aanzitten. En ik heb bluetooth tracking aanstaan. Volgens ESPHome is daarmee 99% van de flash storage gevuld . Ik gebruik MQTT als transport omdat ik API eerder niet stabiel kreeg, maar wellicht is dit nog een poging waard .

De watchdog timeout moest ik overigens wel verhogen omdat anders de node spontaan rebootte. Met name bij een boot wordt de module eigenlijk te zwaar belast. Het liefste zou ik bijvoorbeeld de LD2410 pauzeren totdat er een (stabiele) wifi verbinding is, maar ik heb (nog) niet gevonden hoe dat moet. Maar het is dus stabiel met deze ESP32 configuratie:

YAML:

esp32:
  board: esp32-c6-devkitm-1
  flash_size: 4MB
  variant: ESP32C6
  framework:
    type: esp-idf
    sdkconfig_options:
      # Setup Wi-Fi
      CONFIG_OPENTHREAD_ENABLED: n
      CONFIG_ENABLE_WIFI_STATION: y
      CONFIG_USE_MINIMAL_MDNS: y

      # Setup Bluetooth
      CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY: y
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: n
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y

      # Increase watchdog timeout for low-power devices
      CONFIG_ESP_INT_WDT: n
      CONFIG_ESP_TASK_WDT_EN: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "15"

[JeroenH]

Ik zie in mijn Home Assistant de ESPHome Device Builder Update 2025.7.0 opduiken, en dan lees ik altijd even door wat er veranderd is. Vooral zodat ik van relevante breaking changes weet (dat is in het verleden een keer fout gegaan ) maar ook om te kijken wat er nieuw is.

Mijn oog viel op deze component die in ESPHOME toegevoegd is: https://next.esphome.io/components/sx126x

Dat is voor Lora-(achtige) bordjes. Ik heb er daar twee van liggen, ooit eens gekocht, en met Arduino geprobeerd iets van een verbinding op te zetten maar dat is me destijds niet gelukt. Nu dit is toegevoegd in ESPHOME wordt mijn nieuwsgierigheid wel weer getriggerd, en ik zal ze weer eens opzoeken.

Maar in het kader van "een-oplossing-die-op-zoek-is-naar-een-probleem" (dit is ten slotte Tweakers.net ); wat voor toepassing zou je hiermee kunnen bouwen? Kan ik dat als volgt voor me zien: je hebt zo'n ESP32/Lora bordje in je schuur (dus buiten wifi-range) met bv een deursensor, en binnen in je huis een ESP32/Lora bordje die als een soort van bridge tussen Lora en wifi fungeert? Of moet ik dat anders zien?

[Antonio di]

JeroenH schreef op woensdag 16 juli 2025 @ 11:48:
Ik zie in mijn Home Assistant de ESPHome Device Builder Update 2025.7.0 opduiken, en dan lees ik altijd even door wat er veranderd is. Vooral zodat ik van relevante breaking changes weet (dat is in het verleden een keer fout gegaan ) maar ook om te kijken wat er nieuw is.

Mijn oog viel op deze component die in ESPHOME toegevoegd is: https://next.esphome.io/components/sx126x

Dat is voor Lora-(achtige) bordjes. Ik heb er daar twee van liggen, ooit eens gekocht, en met Arduino geprobeerd iets van een verbinding op te zetten maar dat is me destijds niet gelukt. Nu dit is toegevoegd in ESPHOME wordt mijn nieuwsgierigheid wel weer getriggerd, en ik zal ze weer eens opzoeken.

Maar in het kader van "een-oplossing-die-op-zoek-is-naar-een-probleem" (dit is ten slotte Tweakers.net ); wat voor toepassing zou je hiermee kunnen bouwen? Kan ik dat als volgt voor me zien: je hebt zo'n ESP32/Lora bordje in je schuur (dus buiten wifi-range) met bv een deursensor, en binnen in je huis een ESP32/Lora bordje die als een soort van bridge tussen Lora en wifi fungeert? Of moet ik dat anders zien?

Voor thuis zijn de betere draadloze Alarmsystemen, zorg domotica, brand/CO(etc.) en weerstations spullen allemaal 868Mhz mede vanwege het verre bereik en een betrouwbaar simpel ster-netwerk. Dat is natuurlijk allemaal niet voor niets. Dus LoRa is zeker toepasbaar voor ver bereik. Ben benieuwd wat je resultaat is met een LoRa toepassing.

[bloksnor]

JeroenH schreef op woensdag 16 juli 2025 @ 11:48:
Maar in het kader van "een-oplossing-die-op-zoek-is-naar-een-probleem" (dit is ten slotte Tweakers.net ); wat voor toepassing zou je hiermee kunnen bouwen? Kan ik dat als volgt voor me zien: je hebt zo'n ESP32/Lora bordje in je schuur (dus buiten wifi-range) met bv een deursensor, en binnen in je huis een ESP32/Lora bordje die als een soort van bridge tussen Lora en wifi fungeert? Of moet ik dat anders zien?

Ik lees op reddit vaak oplossingen zoals een brievenbusdeur sensor in een appartementengebouw/groot erf. Dan is de afstand vaak te groot voor bluetooth/wifi/zigbee. Verder weet ik zo geen andere leuke oplossingen

[bjp]

hum... nieuw probleem na update ESPHome -> als ik daarna mijn node zelf update, wordt hij helemaal "unavailable". Ik kan er wel nog OTA updates naartoe sturen. Hij verbindt dus wel met MQTT, maar alle veldjes ontbreken.

Setup: node dat verbindt met MQTT, geen web_server (waar er nu ook problemen mee zijn).

Lijkt meer een ESPhome issue dus schopje

[ Voor 7% gewijzigd door Septillion op 17-07-2025 12:11 ]

[Septillion]

@bjp Als je in het dashboard van ESPHome zit kan je het (live) logbook van het device bekijken. Staat daar nog wat in?

En gezien het MQTT is, kan je ook eens met iets als MQTT explorer naar de berichten kijken.

[bjp]

ik heb een rollback gedaan naar vorige ESPHome, werkt terug.

[SnarfB]

Hallo, kan iemand mijn helpen.
Ik heb op github een programma gevonden om mijn bms van mijn batterij uit te lezen.

https://github.com/DpunktS/seplos_v3_sniffer/tree/main.

Echter ik begrijp niet precies hoe ik dit in ESPhome moet configureren.
Als ik naar de "seplos_v3_sniffer.yaml" file kijk dan mis ik het eerste gedeelte van de configuratie van een ESPhome zoals wifi api ota.
Hoe moet ik dit nu eigenlijk opbouwen in ESPhome, ik gebruik een ESP32 D1 mini.
Ik heb al wel uit de map "esphome/components/seplos_parser" het bestand " seplos_parser.h " in de directory van ESPhome gekopieerd.

[gastje01]

Ik heb al enige tijd een sensor in mijn regenwatertank liggen die aangeeft hoel vol deze nog is. Waarschijnlijk heb ik ergens een breaking change gemist, want ik krijg geen waarde meer door. Als ik in ESPhome de log bekijk zie ik deze wel gewoon langs komen, maar hij wordt niet als entiteit aan HA doorgegeven via MQTT.

Wat heb ik hier gemist / Wat moet ik aanpassen om het weer te laten werken?

YAML:

esphome:
  name: regenwatertank
  friendly_name: regenwatertank

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
#api:
#  encryption:
#    key: "XXXXXXXXXXX"

ota:
  password: "XXXXXXXXXX"
  platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Regenwatertank Fallback Hotspot"
    password: "XXXXXXXXXX"

captive_portal:

mqtt:
  broker: 192.168.1.15
  username: regenwatertank
  password: XXXXXXXXXX

i2c:
  sda: 4
  scl: 5
  scan: false
  id: bus_a

sensor:
  - platform: ina219
    address: 0x40
    shunt_resistance: 0.1 ohm
    current:
      name: "INA219 Current"
      id: ina219current 
      filters:
       - lambda: return abs(x);
    power:
      name: "INA219 Power"
    bus_voltage:
      name: "INA219 Bus Voltage"
      filters:
       - lambda: return abs(x);
    shunt_voltage:
      name: "INA219 Shunt Voltage"
      filters:
       - lambda: return abs(x);
    max_voltage: 25.0V
    max_current: 0.2A
    update_interval: 120s

  - platform: copy
    source_id: ina219current
    name: "Tank Level"
    unit_of_measurement: "%"
    filters:  
      - lambda: return abs(x);
      - calibrate_polynomial:
          degree: 1
          datapoints:
          - 0.0039 -> 0.1
          - 0.01365 -> 100.0

[Septillion]

@gastje01 Om welke sensor gaat het exact?

En kan je dat eens laten zien in HA?

En is er een reden voor dat je MQTT doet ipv de ESPHome API / integratie?

[gastje01]

Septillion schreef op dinsdag 22 juli 2025 @ 15:55:
@gastje01 Om welke sensor gaat het exact?

En kan je dat eens laten zien in HA?

En is er een reden voor dat je MQTT doet ipv de ESPHome API / integratie?

Ik heb inmiddels de volgende regels toegevoegd, en nu werkt het weer.

YAML:

    device_class: ''
    state_class: measurement

Het hele stukje ziet er nu zo uit:

YAML:

i2c:
  sda: 4
  scl: 5
  scan: false
  id: bus_a

sensor:
  - platform: ina219
    address: 0x40
    shunt_resistance: 0.1 ohm
    current:
      name: "INA219 Current"
      id: ina219current 
      filters:
       - lambda: return abs(x);
    power:
      name: "INA219 Power"
    bus_voltage:
      name: "INA219 Bus Voltage"
      filters:
       - lambda: return abs(x);
    shunt_voltage:
      name: "INA219 Shunt Voltage"
      filters:
       - lambda: return abs(x);
    max_voltage: 25.0V
    max_current: 0.2A
    update_interval: 120s

  - platform: copy
    source_id: ina219current
    name: "Tank Level"
    unit_of_measurement: "%"
    device_class: ''
    state_class: measurement
    filters:
      - lambda: return abs(x);
      - calibrate_polynomial:
          degree: 1
          datapoints:
            - 0.0039 -> 0.1
            - 0.01365 -> 100.0
    force_update: true

Ik dacht namelijk dat de waarden niet verzonden werden, maar het bleek dat HA deze niet oppakte.

De reden dat ik MQTT gebruik is vooral legacy, ik had de broker ooit op een ander systeem dan HA, de meeste devices (Shelly, Zigbee2MQTT, OpenDTU) heb ik allemaal op deze manier verbonden. Is er een voordeel om te swtichen naar de API?

[Septillion]

@gastje01 De state class wordt alleen voor de LTS gebruikt.

Maar zou kunnen (maar staat niet expliciet in de doc) dat het ESPHome copy component de device class van de bron standaard aanneemt. En dat je daarmee dus een sensor aanmaakte met device_class: current en unit_of_measurement: "%" en dat is een incorrecte combi voor HA. Misschien dat het ina219 component eerst een device class had of dat het copy component aangepast is?

Qua MQTT, als bus ben ik daar op zich ook wel fan van (je hebt nog eens iets om naar te kijken qua debug). Maar gezien de focus van het ESPHome team op de directe API / integratie ligt en deze ook strakker is ben ik toch wel over.

[ Voor 3% gewijzigd door Septillion op 22-07-2025 16:44 ]

[gastje01]

Septillion schreef op dinsdag 22 juli 2025 @ 16:43:
@gastje01 De state class wordt alleen voor de LTS gebruikt.

Maar zou kunnen (maar staat niet expliciet in de doc) dat het ESPHome copy component de device class van de bron standaard aanneemt. En dat je daarmee dus een sensor aanmaakte met device_class: current en unit_of_measurement: "%" en dat is een incorrecte combi voor HA. Misschien dat het ina219 component eerst een device class had of dat het copy component aangepast is?

Qua MQTT, als bus ben ik daar op zich ook wel fan van (je hebt nog eens iets om naar te kijken qua debug). Maar gezien de focus van het ESPHome team op de directe API / integratie ligt en deze ook strakker is ben ik toch wel over.

Ik gok dat laatste van de 2, want als ik unit_of_measurement weg haalde, kreeg ik de waarde in A i.p.v. % in HomeAssistant. Ik heb alleen het copy component in mijn code aangepast, daarna werkte het weer.

Ik weet echter niet of ik dit 'probleem' veroorzaakt heb door een update van HA of ESPHome, het heeft 1 meer dan een jaar probleemloos gewerkt.

Qua MQTT / API ben ik nog niet helemaal overtuigd om over te stappen. Wellicht voor nieuwe ESP projectjes in huis wel, maar ik heb ook 3 ESP sensoren buiten huis die buiten het subnet vallen waar HA in zit (WireGuard tunneltje). Dit is op IP prima te benaderen, maar dan moet ik DNS weer bij gaan houden om te zorgen dat dit ook werkt. Nu maken de ESP-tjes zelf verbinding met de MQTT broker en hoef ik er alleen maar voor te zorgen det deze overal bereikbaar is. Wellicht een edge-case, maar als er verder geen grote voordelen zijn is er voor mij weinig noodzaak om over te stappen.

[Septillion]

@gastje01 Mja, wat dan gewijzigd is weet ik niet. Maar snap dat HA de combi current en % niet goed keurt

Als het probleem in HA ligt dan zou ik daar zeker een melding van in je log verwachten.

Qua API, dat is wel een interessante. Volgens mij zet HA de verbinding op, dus als ze een adres of IP hebben dat vanuit HA bereikbaar is lijkt me dat goed te gaan. Misschien dat discovery niet werkt en je handmatig toe moet voegen.

[gastje01]

Septillion schreef op dinsdag 22 juli 2025 @ 17:01:
@gastje01 Mja, wat dan gewijzigd is weet ik niet. Maar snap dat HA de combi current en % niet goed keurt

Als het probleem in HA ligt dan zou ik daar zeker een melding van in je log verwachten.

Qua API, dat is wel een interessante. Volgens mij zet HA de verbinding op, dus als ze een adres of IP hebben dat vanuit HA bereikbaar is lijkt me dat goed te gaan. Misschien dat discovery niet werkt en je handmatig toe moet voegen.

Ik heb er ook lang niet naar gekeken moet ik toegeven. De waarde heb ik wel ergens in een dashboard gestopt, maar daar kijk ik eigenlijk nooit naar. Ik heb een regenwatertank in de tuin voor mijn bereginingsinstallatie en ik wil altijd een minimale hoeveelheid in de tank houden om te voorkomen dat t grondwater ‘m mogelijk omhoog drukt (de pomp slaat wel automatisch af, maar veel te laat, dan is ie praktisch droog. Het viel me op dat er niet automatisch gesproeid werd vandaar dat ik ben gaan kijken.

De API zou ik wel eens kunnen testen hoe dat over een tunnel werkt. Voor zo ver ik weet werkt de discovery met mDNS, dus ik zal hoe dan ook iets moeten instellen. De verbinding zelf ben ik niet zo bang voor, dat werkt wel, ik ben benieuwd of ESPHome ‘m dan nog ziet (kan altijd de Ping functie aanzetten).

[Septillion]

@gastje01 mDNS is alleen nodig voor zijn makkelijke hostname. Maar je kunt zowel in HA als ESPHome builder ook op basis van IP doen.

[AUijtdehaag]

Voor mensen met esphome versie 2025.7.3 en fout met compilen van esp-idf:

Oplossing:
De esphome addon in HA even herstarten.

https://github.com/esphome/esphome/issues/9895