Het grote ESPhome topic

[Freezhost]

Jesse- schreef op vrijdag 14 maart 2025 @ 13:13:
[...]


Zet even een raam open, je moet blijkbaar ventileren

1865 ppm is wat hoog, maar geen onrealistische waarde.

Nou, het is in een ruimte met gigantisch veel ventilatie. Sterker nog, het was er 13 graden omdat ik de ramen nog niet dicht had zitten. Zal hem straks eens buiten parkeren, dat zou rond de 400 moeten zitten.

[Gizz]

@Freezhost het is al vaak terugkomen in CO2-meters voor in huis : buiten terugzetten naar 400 ppm (waar je overigens helemaal niet zeker van kunt zijn) moet je doen bij 20 graden, niet bij de huidige temperaturen.

Als je een kamer hebt waar goed geventileerd wordt, zodat je zeker weet dat er minimaal 1x per dag geen 'oude' CO₂ hangt: ABC aan en verder niet klooien met het zelf buiten 'kalibreren' van dat ding. Dat is juist waar ABC voor bedoeld is.

Alleen als je ruimtes hebt met nauwelijks ventilatie of 24/7 mensen, dan is het handig om ABC uit te schakelen. In alle andere gevallen (slaapkamer die overdag leeg is, huiskamer en kantoren waar 's nachts niemand is): ABC aan en gaan met die banaan.

Hier thuis draai ik al jaren prima met o.a. de MH-Z19 en S8 en ABC aan.

Mijn advies: zet ABC aan, hou je sensor lekker in de kamer waar hij thuishoort en kijk over een paar dagen eens wat je van de meetwaardes vindt.

Ik begrijp nooit zo goed waarom mensen de door de fabrikant ontwikkelde en geteste methodiek om sensor-drift te voorkomen bewust uitschakelen Zie ook deze uitleg van Senseair

[ Voor 23% gewijzigd door Gizz op 14-03-2025 13:44 ]

[Freezhost]

@Gizz dus als ik het goed begrijp gewoon ABC inschakelen en verder niets doen? Of wel eerst buiten kalibreren bij 20 graden?

[Gizz]

@Freezhost ABC aan en gewoon gebruiken op z'n vaste plek. En dan een paar dagen wachten (en die kamer net als gewoonlijk ventileren). Ben even kwijt hoe snel de MHZ-19 z'n baseline weer heeft, of dat direct na een na 24 uur is of dat hij er wat langer over doet. Qua die timing zit er wel wat verschil tussen de MHZ-19, S8 en andere sensoren, die ik even niet uit mijn hoofd ken

[Freezhost]

Gizz schreef op vrijdag 14 maart 2025 @ 14:08:
@Freezhost ABC aan en gewoon gebruiken op z'n vaste plek. En dan een paar dagen wachten (en die kamer net als gewoonlijk ventileren). Ben even kwijt hoe snel de MHZ-19 z'n baseline weer heeft, of dat direct na een na 24 uur is of dat hij er wat langer over doet. Qua die timing zit er wel wat verschil tussen de MHZ-19, S8 en andere sensoren, die ik even niet uit mijn hoofd ken

Dat ga ik proberen, buiten meet hij overigens nu 796 ppm... helaas geen meetstation in de buurt dus ik kan het niet valideren.

[DAX23E]

Heeft iemand als eens gebruik gemaakt van een module van Kincony? Ik heb de Kincony KC868-A16 echter krijg ik het niet goed werkend. Via ESP home heb ik het kunnen vinden en heb ik het geïnstalleerd. Vervolgens staat het dan wel in Home Asistant zonder functies.

Schopje naar de buren

[ Voor 5% gewijzigd door Septillion op 17-03-2025 14:22 ]

[timenator]

DAX23E schreef op zondag 16 maart 2025 @ 16:08:
Heeft iemand als eens gebruik gemaakt van een module van Kincony? Ik heb de Kincony KC868-A16 echter krijg ik het niet goed werkend. Via ESP home heb ik het kunnen vinden en heb ik het geïnstalleerd. Vervolgens staat het dan wel in Home Asistant zonder functies.

Ik heb de KC868-A6, deze heb ik werkend gekregen met de onderstaande code. Echter nog niet veel mee gedaan. Denk niet dat ik je verder kan helpen, maar misschien kun je iets met de code.

YAML:

# Basic Config
esphome:
  name: kc868
  on_boot:
    then:
      # read the RTC time once when the system boots
      ds1307.read_time:

esp32:
  board: esp32dev
  framework:
    type: esp-idf

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

logger:

api:
  encryption:
    key: "xxxx"

ota:
  - platform: esphome
    password: "xxx"

uart:
  - id: rs485
    tx_pin: GPIO27
    rx_pin: GPIO14
    baud_rate: 9600
  - id: rs232
    tx_pin: GPIO17
    rx_pin: GPIO16
    baud_rate: 9600

spi:
  clk_pin: GPIO18
  mosi_pin: GPIO23
  miso_pin: GPIO19
  # cs pin: GPIO5

i2c:
  sda: GPIO4
  scl:
    number: GPIO15
    ignore_strapping_warning: true
  frequency: 800kHz

pcf8574:
  - id: inputs
    address: 0x22
  - id: outputs
    address: 0x24

output:
  - platform: esp32_dac
    pin: GPIO25
    id: dac_output2
  - platform: esp32_dac
    pin: GPIO26
    id: dac_output1

time:
  - platform: ds1307
    id: rtc_time
    # repeated synchronization is not necessary unless the external RTC
    # is much more accurate than the internal clock
    update_interval: never
  - platform: homeassistant
    # instead try to synchronize via network repeatedly ...
    on_time_sync:
      then:
        # ... and update the RTC when the synchronization was successful
        ds1307.write_time:

font:
  - file: "gfonts://Roboto"
    id: roboto
    size: 10

interval:
  - interval: 5s
    then:
      - display.page.show_next: my_display
      - component.update: my_display

display:
  - platform: ssd1306_i2c
    id: my_display
    model: "SSD1306 128x64"
    address: 0x3C
    rotation: 90
    pages:
      - id: page1
        lambda: |-
          it.rectangle(0, 0, 16, 128);
          it.rectangle(17, 0, 47, 128);
          it.strftime(0, 0, id(roboto), "%Y-%m-%d %H:%M", id(rtc_time).now());
      - id: page2
        lambda: |-
          if (id(relay_1).state) {
            it.print(0, 0, id(roboto), "state: DRM0");
          } else if (id(relay_2).state) {
            it.print(0, 0, id(roboto), "state: DRM1");
          } else {
            it.print(0, 0, id(roboto), "state: OFF");
          }

light:
  - platform: monochromatic
    output: dac_output1
    name: "KC868-A6-DAC1"
    gamma_correct: 2
    id: dac_light1

binary_sensor:
  - platform: gpio
    name: "KC868-A6-IN-1"
    pin:
      pcf8574: inputs
      number: 0
      mode: INPUT
      inverted: true
    on_press:
      then:
        - output.set_level:
            id: dac_output1
            level: 50%
  - platform: gpio
    name: "KC868-A6-IN-2"
    pin:
      pcf8574: inputs
      number: 1
      mode: INPUT
      inverted: true
    on_press:
      then:
        - output.set_level:
            id: dac_output1
            level: 25%
  - platform: gpio
    name: "KC868-A6-IN-3"
    pin:
      pcf8574: inputs
      number: 2
      mode: INPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-IN-4"
    pin:
      pcf8574: inputs
      number: 3
      mode: INPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-IN-5"
    pin:
      pcf8574: inputs
      number: 4
      mode: INPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-IN-6"
    pin:
      pcf8574: inputs
      number: 5
      mode: INPUT
      inverted: true

switch:
  - platform: gpio
    name: "KC868-A6-RELAY-1"
    id: relay_1
    pin:
      pcf8574: outputs
      number: 0
      mode: OUTPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-RELAY-2"
    id: relay_2
    pin:
      pcf8574: outputs
      number: 1
      mode: OUTPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-RELAY-3"
    id: relay_3
    pin:
      pcf8574: outputs
      number: 2
      mode: OUTPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-RELAY-4"
    id: relay_4
    pin:
      pcf8574: outputs
      number: 3
      mode: OUTPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-RELAY-5"
    id: relay_5
    pin:
      pcf8574: outputs
      number: 4
      mode: OUTPUT
      inverted: true
  - platform: gpio
    name: "KC868-A6-RELAY-6"
    id: relay_6
    pin:
      pcf8574: outputs
      number: 5
      mode: OUTPUT
      inverted: true

[Lief Adje]

Vanochtend geüpdatet naar 2025.3, maar daar lijkt een bug in te zitten, wat ik ook probeer te compilen resulteert in een error.

code:

Compiling .pioenvs/esp32ble/src/esphome/components/api/api_server.cpp.o
xtensa-esp32s3-elf-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
*** [.pioenvs/esp32ble/src/esphome/components/api/api_connection.cpp.o] Error 1

[Septillion]

@Lief Adje Hier geen last van zo te zien. Wat als je een keer "Clean build files" doet?

[Obelixxx]

Ik ook heb een issue na versie 2025.3.
Cheap Yellow Display doet helaas niets meer

[Lief Adje]

Septillion schreef op donderdag 20 maart 2025 @ 13:36:
@Lief Adje Hier geen last van zo te zien. Wat als je een keer "Clean build files" doet?

Nee helaas ook dan niet.

Edit: gelukt, home assistant vm opnieuw opstarten en normaals clear build gedaan

[ Voor 15% gewijzigd door Lief Adje op 20-03-2025 16:36 ]

[Obelixxx]

Obelixxx schreef op donderdag 20 maart 2025 @ 13:38:
Ik ook heb een issue na versie 2025.3.
Cheap Yellow Display doet helaas niets meer

Vanochtend is het issue met mijn Cheap Yello Display opgelost door de esphome update

[M.v.Veelen]

Heeft iemand een idee of de Qnect wifi switches via een URL zijn te bedienen? Ik heb het IP adres, maar ze hebben zo te zien geen webserver oid. Ik zou ze graag on/off willen switchen om verder aan te sturen met Domoticz.

[u_nix_we_all]

M.v.Veelen schreef op dinsdag 25 maart 2025 @ 17:42:
Heeft iemand een idee of de Qnect wifi switches via een URL zijn te bedienen? Ik heb het IP adres, maar ze hebben zo te zien geen webserver oid. Ik zou ze graag on/off willen switchen om verder aan te sturen met Domoticz.

Niet met de standaard firmware, dat gaat allemaal via de Tuya cloud.
Waarschijnlijk kun je de firmware wel overschrijven met tuya-cloudcutter en er dan esphome firmware (esphome-libretiny versie) opzetten. Zie: https://digiblur.com/2023...home-bk7231-how-to-guide/

[M.v.Veelen]

Heb daar zitten lezen, maar is geen kattepis zoals voorheen met Tasmota flashen op een Sonoff of Shelly. Ik heb nu de App gebruikt om maar wat aan/uit-blokken in te stellen. Dat voldoet voor nu. Mocht het eenvoudiger worden om er bijv. Tasmota op te flashen dan ben ik van de partij, thanks.

[jgsr]

Heeft iemand hier ervaring met het werkend krijgen van een m5stack core2 v1.1 via Esphome? Ik ben een aardig eind gekomen maar op de één of andere manier krijg ik de power en reset buttons niet werkend en wil de core2 enkel inschakelen via een usb kabel...

[Septillion]

@jgsr Als ik naar het schema kijk zie ik reset gewoon direct aan de ESP hangen dus die zou moeten werken.

En de power button lijkt volledig door de externe chip afgehandeld te worden. Ik zie ook geen directe koppeling met de ESP vand e power button. Dus weet niet of je er überhaupt wat mee kunt.

[ Voor 8% gewijzigd door Septillion op 27-03-2025 12:41 ]

[jgsr]

Septillion schreef op donderdag 27 maart 2025 @ 12:40:
@jgsr Als ik naar het schema kijk zie ik reset gewoon direct aan de ESP hangen dus die zou moeten werken.

En de power button lijkt volledig door de externe chip afgehandeld te worden. Ik zie ook geen directe koppeling met de ESP vand e power button. Dus weet niet of je er überhaupt wat mee kunt.

Jaa het lijkt erop dat de axp2101 library in esphome niet volledig is en wat functionaliteit mist.

Als ik de m5stack core library van arduinoIDE gebruik werken de pwr en rst prima.

[Brynnie]

Ik heb iets vreemds aan de hand bij het koppelen van een IKEA Vindriktning aan mijn Home Assistant installatie. De Vindriktning is op zich een dom device dat partijleden met diameter 2.5 micrometer meet in de lucht. Ik denk dat het op de IKEA site niet meer verkocht wordt.

Ik volg deze Reddit werkwijze, er staan op meerdere sites en YouTube gelijkaardige voorbeelden.

De D1 mini wordt gezien in ESP Home maar er komt geen data door, de meter blijft op NA staan, er komen geen waardes binnen bij Home Assistant. In ESP Home staat het device online, en ik kan OTA updates doen. Ik vermoed dus dat de power (5V en ground) correct aangesloten zijn, maar de data die lijkt niet doorgegeven te worden. Ik heb al verschillende pin posities op de D1 mini geprobeerd, het solderen opnieuw gedaan, maar niets lijkt te helpen.

De yaml van mijn esp device ziet er als volgt uit:

YAML:

esphome:
  name: esphome-web-5395d3
  friendly_name: Vindriktning 1
  min_version: 2024.11.0
  name_add_mac_suffix: false

# esp8266:
  # board: esp01_1m
esp8266:
  board: d1_mini

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

wifi:
  ssid: ssidnaam
  password: paswoord

web_server:
  port: 80

captive_portal:
# Example configuration entry
uart:
  rx_pin: D5
  baud_rate: 9600
sensor:
  - platform: pm1006
    pm_2_5:
      name: "Ikea Vindriktning PM25"

[jj85]

Brynnie schreef op vrijdag 28 maart 2025 @ 15:22:
Ik heb iets vreemds aan de hand bij het koppelen van een IKEA Vindriktning aan mijn Home Assistant installatie. De Vindriktning is op zich een dom device dat partijleden met diameter 2.5 micrometer meet in de lucht. Ik denk dat het op de IKEA site niet meer verkocht wordt.

Ik volg deze Reddit werkwijze, er staan op meerdere sites en YouTube gelijkaardige voorbeelden.

De D1 mini wordt gezien in ESP Home maar er komt geen data door, de meter blijft op NA staan, er komen geen waardes binnen bij Home Assistant. In ESP Home staat het device online, en ik kan OTA updates doen. Ik vermoed dus dat de power (5V en ground) correct aangesloten zijn, maar de data die lijkt niet doorgegeven te worden. Ik heb al verschillende pin posities op de D1 mini geprobeerd, het solderen opnieuw gedaan, maar niets lijkt te helpen.

De yaml van mijn esp device ziet er als volgt uit:

YAML:

esphome:
  name: esphome-web-5395d3
  friendly_name: Vindriktning 1
  min_version: 2024.11.0
  name_add_mac_suffix: false

# esp8266:
  # board: esp01_1m
esp8266:
  board: d1_mini

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

wifi:
  ssid: ssidnaam
  password: paswoord

web_server:
  port: 80

captive_portal:
# Example configuration entry
uart:
  rx_pin: D5
  baud_rate: 9600
sensor:
  - platform: pm1006
    pm_2_5:
      name: "Ikea Vindriktning PM25"

Deel aub even wat foto's van je projectje

[piforce]

Ik probeer een lsc powerplug via de instructie van de keetsupport site te flashen. De yaml ervan staat in dit topic blz 6. Echter loop ik vast met het maken van de uf2 en yaml ergens plaatsen.

First we need to create a yaml file for the plug and download a UF2 package we can flash.

Yaml file kan ik vinden maar hoe maak ik die uf2 package. Als ik in de webui connect kan ik nergen uf2 package aanvinken/maken

[Septillion]

@piforce De yaml plaats je in ESPhome Builder in een nieuw device. Daarna kan je op install klikken en kies je voor Manual download. Na het compilen krijg je dan de vraag in welk formaat je het wilt downloaden.

[piforce]

Top dat is gelukt krijg alleen nog niet in itchiptool de chip gereset. Zoals in omschrijving de zwarte cen op ground maar gebeurt niks.

[Septillion]

@piforce Zorgen dat de plug spanning heeft (3V3, niet 230V). Dan de upload starten en dan geeft je de CEN pin een tikje met GND. Kan paar tikjes nodig hebben. Tot je de werkelijke upload ziet starten.

[Brynnie]

jj85 schreef op vrijdag 28 maart 2025 @ 15:50:
[...]

Deel aub even wat foto's van je projectje

Moeilijk te zien op de foto’s, maar volgens mij zijn de verbindingen correct.

[jgsr]

Brynnie schreef op dinsdag 1 april 2025 @ 00:04:
[...]


Moeilijk te zien op de foto’s, maar volgens mij zijn de verbindingen correct.

[Afbeelding]

[Afbeelding]

Je groene kabel op de 2e foto mag wel even opnieuw gestripped en gesoldeerd. Ziet er niet best uit zo en zou pennetjes erop solderen en dan, op je 1e foto lijkt wel een brug te zien tussen d2 en d3...

[ Voor 6% gewijzigd door jgsr op 01-04-2025 08:01 ]

[Septillion]

@Brynnie Zou alles even nalopen. Sommige zijn wat grof, sommige wat droog (zoals de GND op de Wemos) en D2 en D3 lijken aan elkaar te zitten.

En ik zou de data aan D7 hangen. Als je de logger via serial uit zet en D7 als Rx maakt is ESPhome zo slim om de hardware serial UART0 over te zetten (serial swap) naar D7. Dit is in hardware en kan dus niet op elke random pin.

[Brynnie]

Bedankt voor de constructieve feedback. Ik zal morgen jullie adviezen volgen. Het is dan ook de allereerste keer dat ik een soldeerbout gebruik.

[Antonio di]

Er is een mooi Tweakers forum gemaakt door @dotcom87 over het koppelen van een Ecowitt 868Mhz grondvochtigheidsmeter aan Home Assistant via een 868Mhz ESP32-bordje, zie:
Koppelen van de Ecowitt WH51 aan Home Assistant
Gesaved/doorgestreept(verwijdert): @u_nix_we_all ik wacht wel op @Septillion waar hij vindt dat het moet staan!

[ Voor 20% gewijzigd door Antonio di op 02-04-2025 00:43 ]

[u_nix_we_all]

@Antonio di Leuk maar heeft niets met ESPhome te maken?

[frans3]

Is het mogelijk om de gegevens van een HA entiteit in te lezen in ESPhome ?

Wil graag de wattage van de zonnepanelen uitlezen in ESPhome en deze gegevens naar een esp8266 sturen en deze een PWM signaal laten uitsturen.

YAML:

sensor:
  - platform: homeassistant
    id: Current_power_production
    entity_id: envoy_122252020183_current_power_production
    attribute: opbrengst momenteel

krijg geen foutmelding maar zie niets verschijnen

Schopje naar het grote topic + code-tag fix

[ Voor 6% gewijzigd door Septillion op 06-04-2025 20:42 ]

[Septillion]

@frans3 Dat is wel heel summier... Waar zie je niets?

Standaard is een Home Assistant Sensor internal, dus heb je de waarde netjes in ESPhome maar zie je hem niet terug in HA of je dashboard. Maar je kan er in ESPhome dan wel wat mee.

[jj85]

frans3 schreef op zondag 6 april 2025 @ 19:46:
Is het mogelijk om de gegevens van een HA entiteit in te lezen in ESPhome ?

Wil graag de wattage van de zonnepanelen uitlezen in ESPhome en deze gegevens naar een esp8266 sturen en deze een PWM signaal laten uitsturen.

YAML:

sensor:
  - platform: homeassistant
    id: Current_power_production
    entity_id: envoy_122252020183_current_power_production
    attribute: opbrengst momenteel

krijg geen foutmelding maar zie niets verschijnen

[mbr]Schopje naar het grote topic + code-tag fix[/]

Probeer eens:

YAML:

    entity_id: sensor.envoy_122252020183_current_power_production

in plaats van

YAML:

    entity_id: envoy_122252020183_current_power_production

[Septillion]

@jj85 Volgens de documentatie moet het gewoon het volledige entity id zijn. Op zich ook logisch, er kan zowel een sensor.foo als een select.foo. Van beide kan je een attribute in een sensor stoppen in ESPhome.

[jj85]

Septillion schreef op zondag 6 april 2025 @ 21:23:
@jj85 Volgens de documentgatie moet het gewoon het volledige entity id zijn. Op zich ook logisch, er kan zowel een sensor.foo als een select.foo. Van beide kan je een attribute in een sensor stoppen in ESPhome.

Dat was de strekking van m'n post
Nu is het envoy_122252020183_current_power_production
dat zou waarschijnlijk sensor.envoy_122252020183_current_power_production moeten zijn

[Gizz]

@frans3 waarom niet in HA je zonnepanelen omzetten in een pwm-waarde en vervolgens alleen direct pwm aansturen op je esp? Gewoon via deze optie in esphome.

Zo doe ik het ook met de aansturing van mijn mechanische ventilatie. Lijkt me een makkelijkere route.

[ Voor 21% gewijzigd door Gizz op 06-04-2025 21:36 ]

[Septillion]

@jj85 Ik moet naar bed

Verder wel eens met @Gizz, ik doe het automatiseren ook liever in HA zelf.

[ Voor 59% gewijzigd door Septillion op 06-04-2025 21:51 ]

[jj85]

Septillion schreef op zondag 6 april 2025 @ 21:50:
@jj85 Ik moet naar bed

Haha, maar je toelichting over attributen triggert me wel


@frans3 , de sensor.envoy_122252020183_current_power_production kent volgens mij geen attributen.
Dus het stukje code attribute: opbrengst momenteel doet verder ook niet veel.

Met onderstaande code zou jouw envoy sensor in ESPHome beschikbaar moeten zijn onder id(Current_power_production)

YAML:

sensor:
  - platform: homeassistant
    id: Current_power_production
    entity_id: sensor.envoy_122252020183_current_power_production

[frans3]

@Septillion uhh idd even moeten melden, maar ik bedoel in de webserver van de esp8266


@Gizz oww top, ga ik me in verdiepen .... voor mij geen gesneden koek

[frans3]

@jj85 hola..... krijg nu wel wat binnen maar 0,00 kan wel kloppen this donker buiten :-)

ga er verder mee

Top !!!

[KabouterSuper]

Chips, net een projectje weer opgepakt met een esp32, maar per ongeluk wat draden losgetrokken. Vaak niet erg, maar in dit geval zijn het twee draden die te maken hebben met deep sleep.
Ik heb een draad zonder weerstand die volgens mij bedoeld is om de esp32 uit de deep sleep te halen. Ik denk dat deze altijd op en en GPIO16 moet.
Daarnaast heb ik een draad gemaakt met een 10K weerstand. Deze moet tussen een pin en 5V of tussen een pin en G. Deze is bedoeld om de esp uit de deepsleep te houden. Het geheel heeft goed gewerkt.
Uit de log haal ik

code:

[C][api:026]: Setting up Home Assistant API server...
[C][deep_sleep:013]: Setting up Deep Sleep...
[I][deep_sleep:018]: Scheduling Deep Sleep to start in 20000 ms
...
[C][deep_sleep:026]: Setting up Deep Sleep...
[C][deep_sleep:029]:   Sleep Duration: 300000 ms
[C][deep_sleep:032]:   Run Duration: 20000 ms
[C][deep_sleep:043]:   Wakeup Pin: GPIO34
...

[I][deep_sleep:060]: Beginning Deep Sleep
[I][deep_sleep:062]: Sleeping for 300000000us

Weet iemand toevallig verstand heeft van deepsleep en weet wat ik met elkaar moet verbinden om de esphome uit z'n deepsleep te houden? Zodra ik dat kan, kan ik de yaml file ook weer inzien. Ik heb nu pin 34 op 5V verbonden via de 10K weerstand, maar dit werkt niet. Ook pin 34 met G verbinden geeft niet het goede gedrag.

[Septillion]

@KabouterSuper De ESP8266 heeft een verbinding tussen GPIO16 en RST/EN nodig. Maar zo ver ik weet de ESP32 niet.

En hoezo dan de yaml weer inzien? Die staat niet op de ESP, die heb je in ESPhome builder of van een externe locatie.

[DjoeC]

Begrijp ik goed dat je code deepsleep bevat maar dat je die niet wilt uitvoeren? Volgens kan dat niet meer zodra de deepsleep code bereikt is. De pinverbinding van de esp8266 is bedoeld om de processor weer uit deepsleep te laten komen, zonder die connectie is deepsleep sleepforever.

Het enige dat ik me voor kan stellen om deepsleep te voorkomen is 1) flashen zonder de deepsleep code of 2) als er interrupts in je proggie zitten die zodanig snel uit te voeren dat deepsleep niet bereikt wordt..

[KabouterSuper]

Septillion schreef op woensdag 9 april 2025 @ 19:36:
@KabouterSuper De ESP8266 heeft een verbinding tussen GPIO16 en RST/EN nodig. Maar zo ver ik weet de ESP32 niet.

En hoezo dan de yaml weer inzien? Die staat niet op de ESP, die heb je in ESPhome builder of van een externe locatie.

Dank je voor de heads up. Ik zat met mijn duffe hoofd op https://web.esphome.io/ te zoeken in plaats van de esphome installatie op mijn HA server, excuus. Ik kan inderdaad de yaml daar gewoon zien.

Wat betreft de verbinding naar RST/EN, daar kan ik niet veel over vinden. Je hebt gelijk dat dit ESP8266-specifiek is, maar betekent dit dat je helemaal geen verbinding naar RST/EN meer nodig hebt met esp32?

DjoeC schreef op woensdag 9 april 2025 @ 22:11:
Begrijp ik goed dat je code deepsleep bevat maar dat je die niet wilt uitvoeren? Volgens kan dat niet meer zodra de deepsleep code bereikt is. De pinverbinding van de esp8266 is bedoeld om de processor weer uit deepsleep te laten komen, zonder die connectie is deepsleep sleepforever.

Het enige dat ik me voor kan stellen om deepsleep te voorkomen is 1) flashen zonder de deepsleep code of 2) als er interrupts in je proggie zitten die zodanig snel uit te voeren dat deepsleep niet bereikt wordt..

Het idee is dat zodra ik de wakup pin 3.4V geef, dat de esp32 dan wakker wordt en niet meer in deepsleep gaat. Als de pin niet verbonden is, dan gaat de esp wel in deepsleep en ontwaakt elke 5 minuten. Zo kan ik het verbruik verminderen, maar als ik wil de esp wakker kan houden (is wel makkelijk als je een nieuwe yaml erop wil krijgen). Maar ik was dus de details vergeten en ook welke pin ik ook alweer gebruikt had.

Inmiddels heb ik het weer draaiend:

YAML:

deep_sleep:
  run_duration: 20s
  sleep_duration: 300s
  wakeup_pin: GPIO34
  wakeup_pin_mode: KEEP_AWAKE

Als ik pin 34 via een 10K weerstand verbind met 3.4V, krijg ik weer netjes in mijn log:

code:

[09:52:39][W][deep_sleep:059]: Waiting wakeup pin state change to enter deep sleep...

[DjoeC]

@KabouterSuper Misschien kun je hier: https://randomnerdtutoria...uino-ide-wake-up-sources/ meer info vinden.... Ik lees daar iig niets over een verplichte connectie zoals bij de ESP8266.

[Septillion]

Volgens mij dus niet nodig. En is een pin als external wake up gebruik dus optioneel. En zou je er zelfs de interne pull weerstand op kunnen gebruiken.

[bbn_ldp]

Goedemiddag,

Ik krijg enkele esphome apparaten niet meer geüpdatet, omdat ik de volgende foutmelding krijg.

code:

INFO ESPHome 2025.4.0
INFO Reading configuration /config/esphome/meteo-tuin-en-schuur.yaml...
Failed config

esphome: [source /config/esphome/meteo-tuin-en-schuur.yaml:8]
  name: meteo-tuin-en-schuur
  
  Please remove the `platform` key from the [esphome] block and use the correct platform component. This style of configuration has now been removed.
  platform: esp32
  board: mhetesp32devkit

Ik begrijp niet wat ik precies moet veranderen. Onderstaand het stukje uit de yaml dat de fout aangeeft.

YAML:

substitutions:
  devicename: "Meteo-tuin-en-schuur"  
  friendly_name: ${devicename}
  # Unique device ID in HA
  deviceid: "Meteo-tuin-en-schuur"  
  
esphome:
  name: meteo-tuin-en-schuur
  platform: esp32
  board: mhetesp32devkit

Wat is hier de oplossing?

Groet Ben

[ Voor 1% gewijzigd door Septillion op 23-04-2025 16:15 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[babbelbox]

bbn_ldp schreef op woensdag 23 april 2025 @ 16:08:
Goedemiddag,

Ik krijg enkele esphome apparaten niet meer geüpdatet, omdat ik de volgende foutmelding krijg.

INFO ESPHome 2025.4.0
INFO Reading configuration /config/esphome/meteo-tuin-en-schuur.yaml...
Failed config

esphome: [source /config/esphome/meteo-tuin-en-schuur.yaml:8]
name: meteo-tuin-en-schuur

Please remove the `platform` key from the [esphome] block and use the correct platform component. This style of configuration has now been removed.
platform: esp32
board: mhetesp32devkit

Ik begrijp niet wat ik precies moet veranderen. Onderstaand het stukje uit de yaml dat de fout aangeeft.

substitutions:
devicename: "Meteo-tuin-en-schuur"
friendly_name: ${devicename}
# Unique device ID in HA
deviceid: "Meteo-tuin-en-schuur"

esphome:
name: meteo-tuin-en-schuur
platform: esp32
board: mhetesp32devkit

Wat is hier de oplossing?

Groet Ben

Even uit het hoofd, vervang de platform declaratie voor esp32: met als onderdeel de board definitie.

[Septillion]

@bbn_ldp Aanpassen in:

YAML:

substitutions:
  devicename: "Meteo-tuin-en-schuur"  
  friendly_name: ${devicename}
  # Unique device ID in HA
  deviceid: "Meteo-tuin-en-schuur"  
  
esphome:
  name: meteo-tuin-en-schuur

esp32:
  board: mhetesp32devkit

[bbn_ldp]

Septillion schreef op woensdag 23 april 2025 @ 16:16:
@bbn_ldp Aanpassen in:

YAML:

substitutions:
  devicename: "Meteo-tuin-en-schuur"  
  friendly_name: ${devicename}
  # Unique device ID in HA
  deviceid: "Meteo-tuin-en-schuur"  
  
esphome:
  name: meteo-tuin-en-schuur

esp32:
  board: mhetesp32devkit

Als ik jullie wijzigingen doe krijg ik het rode golfje onder substitutions: en dat geeft zover mijn kunde gaat dan ook weer een fout aan toch?
substitutions:

In de yaml parser krijg ik dan de foutmelding:
Error : Unable to parse.
Line : 9 esp32

Te vroeg gereageerd. Namelijk toen ik de yaml tekst kopieerde van septillion werkte het wel

[ Voor 13% gewijzigd door bbn_ldp op 23-04-2025 16:25 ]

[Septillion]

@bbn_ldp Wel : achter esp32 staan?

[ Voor 61% gewijzigd door Septillion op 23-04-2025 16:47 ]

[bbn_ldp]

Septillion schreef op woensdag 23 april 2025 @ 16:47:
@bbn_ldp Wel : achter esp32 staan?

Ja bedankt het is gelukt

[Bockelaar]

mocht je psram errors krijgen op je esphome met de Athome Echo: het is een bugje waar een fix voor aankomt.
Tussenoplossing is om een external component in je yaml toe te voegen:

YAML:

external_components:
  - source: github://esphome/esphome@2025.3.3
    components: [psram]

.
zie ook https://github.com/esphome/esphome/pull/8584

[bloksnor]

bbn_ldp schreef op woensdag 23 april 2025 @ 16:08:

YAML:

substitutions:
  devicename: "Meteo-tuin-en-schuur"  
  friendly_name: ${devicename}
  # Unique device ID in HA
  deviceid: "Meteo-tuin-en-schuur"  
  
esphome:
  name: meteo-tuin-en-schuur
  platform: esp32
  board: mhetesp32devkit

Wat is hier de oplossing?

Groet Ben

als ik naar esphome.io ga, zie ik het volgende:

YAML:

esphome:
  name: awesome
esp32:
  board: nodemcu-32s

Dit is precies wat babbelbox zegt

[gastje01]

Ik heb een issue waar ik niet uit kom. Ik heb een Wemel ESP32 met ESPHome en een RS485 adapter en de bedoeling is om hier een 10A DMX dimmer mee aan te sturen. In theorie werkt dit, maar de praktijk is rauwer dan de bedoeling is. Wanneer ik de dimmer namelijk met de ESP aanstuur, pulseert/knippert de dimmer, zelfs op 100% zie ik dit fenomeen. Context: ik wil hier een boiler mee aansturen, maar als test heb ik een 300W bouwlamp gebruikt, en die geeft hetzelfde resultaat.

De dimmer is goed, met een handmatige schuif kun je DMX overrulen en dan is de uitgang stabiel.
De RS485 adapter zowel op 3.3 als 5V aangesloten, zelfde resultaat.

Ik heb te weinig verstand van DMX, maar wat ik zo gelezen heb, zou het een timing issue kunnen zijn. Wat zou ik nog kunnen testen, anders dan een andere adapter bestellen?

[SnarfB]

Ik heb een paar jaar geleden een regeling voor ventilatoren gebruikt, deze wil ik nu weer gebruiken in ESPhome maar ik krijg nu foutmeldingen. Om de beginnen in het deel OTA ik ben niet zo bedreven in ESPhome , als ik het deel onder OTA weghaalt krijg ik een foutmelding bij de Dallas sensor en boven bij esphome.
Heeft iemand een idee wat er aangepast moet worden.

YAML:

esphome:
  name: "fan-3"

#########################                                                                                                                                                                                                                
# ESP AND NETWORK SETUP                                                                                                                                                                                                                

esp8266:
  board: d1_mini

# pid climate log update is noisy, dial it back to warn                                                                                                                                                                                  
logger:
  level: DEBUG
  logs:
    dallas: DEBUG

# uncomment if you prefer native api
#api:


web_server:
  port: 80

# default HA integration, OTA updater and backup http web portal                                                                                                                                                                         
ota:
  on_begin:
    then:
      - logger.log: "OTA start"
  on_progress:
    then:
      - logger.log:
          format: "OTA progress %0.1f%%"
          args: ["x"]
  on_end:
    then:
      - logger.log: "OTA end"

captive_portal:

wifi:
  # Read the wifi/pass from secrets.yaml:                                                                                                                                                                                                
  # wifi_ssid: "My Wifi XX"                                                                                                                                                                                                              
  # wifi_password: "XXXXXXX"                                                                                                                                                                                                             

  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true

  # Optional manual IP
  manual_ip:
    static_ip: 192.168.20.89
    gateway: 192.168.20.254
    subnet: 255.255.255.0  

  # Enable fallback hotspot (captive portal) in case wifi connection fails                                                                                                                                                               
  ap:
    ssid: FanController


text_sensor:
  # Send IP Address                                                                                                                                                                                                                      
  - platform: wifi_info
    ip_address:
      name: IP Address
    ssid:
      name: SSID

  # Send Uptime in raw seconds                                                                                                                                                                                                           
  - platform: template
    name: Uptime
    id: uptime_human
    icon: mdi:clock-start

dallas:
  - pin: D7
    update_interval: 10s

sensor:
  # Send WiFi signal strength & uptime to HA                                                                                                                                                                                             
  - platform: wifi_signal
    name: WiFi Strength
    update_interval: 60s
                                                                                                                                                                                                              

  - platform: dallas
    #address: 0xf13cele3807ab228
    index: 0
    resolution: 9
    name: "Temperature"
    id: fan_temperature
    accuracy_decimals: 1
    #alternative use lambda with map
    on_value:
      # map min temp whn fan should start 30°C to max temp 50°C when it should have max speed
      - lambda: !lambda |
          auto pct = constrain(map(x, id(start_temp).state, id(max_temp).state, 1, 80),0, 80);
          if( id(automatic).state ) {
            if (pct>1) {
              auto call = id(the_fan).turn_on(); call.set_speed(pct); call.perform();
            } else {
              auto call = id(the_fan).turn_off(); call.set_speed(1); call.perform();
            }
            ESP_LOGD("custom", "Setting speed to %i %%", pct);
          }

output:
  # Wire D1 into the PWM pin of your 12v fan                                                                                                                                                                                  
  # ledc is the name of the pwm output system on an esp32                                                                                                                                                                                
  - platform: esp8266_pwm
    id: fan_speed
    pin: D1

    # 25KHz is standard PC fan frequency, minimises buzzing for eso8266 1kHz is max                                                                                                                                                                           
    frequency: "25 Hz"

    # my fans stop working below 13% powerful.                                                                                                                                                                                           
    # also they're  powerful and loud, cap their max speed to 80%                                                                                                                                                                        
    min_power: 0.5
    max_power: 1
    zero_means_zero: True
    
  # Fan power (MOSFET) via D3 with will switch GND for the fan through an N-Ch MOSFET
  - platform: gpio
    pin: D3
    id: fan_power

fan:
  - platform: speed
    output: fan_speed
    name: Fan
    id: the_fan
    on_turn_on:
      - output.turn_on: fan_power
    on_turn_off:
      - output.turn_off: fan_power

# two number controlling the speed adjustment range
number:
  - platform: template
    name: "Fan max. Speed"
    id: max_speed
    internal: false
    initial_value: 80
    max_value: 100
    min_value: 50
    unit_of_measurement: pct
    step: 1
    optimistic: true
    mode: slider

  - platform: template
    name: "Fan Start Temp"
    id: start_temp
    internal: false
    max_value: 40.0
    min_value: 20.0
    initial_value: 25
    step: 1
    optimistic: true
    mode: slider

  - platform: template
    name: "Fan 100% Temp"
    id: max_temp
    internal: false
    initial_value: 45
    max_value: 50.0
    min_value: 25.0
    step: 1
    optimistic: true
    mode: slider


switch:
  # template switch, whether control is fully manual or temperature controlled
  - platform: template
    name: Temperature Controlled
    optimistic: true
    id: automatic
    restore_mode: RESTORE_DEFAULT_ON
    on_turn_on:
      # if auto is turned on restore temp based value
      - lambda:  !lambda |
          auto pct = constrain(map(id(fan_temperature).state, id(start_temp).state, id(max_temp).state, 1, 80),0,80);
          if (pct>1) {
            auto call = id(the_fan).turn_on(); call.set_speed(pct); call.perform();
          } else {
            auto call = id(the_fan).turn_off(); call.set_speed(1); call.perform();
          }
          
button:
  # Expose an ESP32 restart button to HA                                                                                                                                                                                                 
  - platform: restart
    name: "Restart"

[Gizz]

@SnarfB Je OTA stukje vind ik vrij uitgebreid. En de basis voor OTA binnen Esphome ontbreekt juist. Dit is de de basis volgens de documentatie:

YAML:

# Example configuration entry
ota:
  - platform: esphome
    password: !secret ota_password

Verder klopt je Dallas-stuk inderdaad niet. Vergelijk het maar met de documentatie. Het is nu dallas_temp.

Edit: en al je logging op debug instellen lijkt me overbodig. Daar wordt in de comments van de door jouw geplaatste code ook een opmerking over gemaakt, dat je dat beter kunt terugbrengen tot warnings.

[ Voor 17% gewijzigd door Gizz op 29-04-2025 15:30 ]

[Septillion]

@gastje01 Wat bedoel je met "DMX overrulen"?

En welke module exact? En wat is je yaml?

[gastje01]

Septillion schreef op dinsdag 29 april 2025 @ 20:36:
@gastje01 Wat bedoel je met "DMX overrulen"?

En welke module exact? En wat is je yaml?

Als je de fysieke slider op de dimmer aanpast, dan negeert ie het DMX signaal en pakt ie de waarde die je op de slider instelt, het dim gedeelte werkt dus. Wanneer ik dezelfde waarde via DMX instel (zeg 30%) schiet t alle kanten op.

Ik gebruik deze module: https://www.amazon.com/AL...icator/dp/B08XLT21S6?th=1

en deze code om t spul aan te sturen:

YAML:

esphome:
  name: boiler-dmx
  friendly_name: Boiler-DMX


esp32:
  board: wemos_d1_mini32

# Enable logging
logger:

mqtt:
  broker: 192.168.1.15
  username: boileruser
  password: boilerpwd

ota:
  - platform: esphome
    password: "d52e1c2b45cbbf49f65274554a840ece"

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

external_components:
  - source: github://andyboeh/esphome-dmx512

substitutions:
  device_name: "Boiler DMX Controller"

uart:
  id: uart_bus
  baud_rate: 250000
  tx_pin:
    number: GPIO22
    allow_other_uses: true
  stop_bits: 2

dmx512:
  id: dmx
  uart_id: uart_bus
#  enable_pin: 33
  tx_pin:
    number: GPIO22
    allow_other_uses: true
  uart_num: 1

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${device_name} IP

sensor:
  - platform: uptime
    name: ${device_name} Uptime
  - platform: wifi_signal
    name: ${device_name} WiFi Signal
    update_interval: 60s
  - platform: dallas_temp
    name: Boiler Temperatuur
    update_interval: 20s


output:
  - platform: dmx512
    channel: 1   
    universe: dmx
    id: dmx_1
#   min_power: 0.1
#   max_power: 0.95 

light:
  - platform: monochromatic
    name: "${device_name} Dimmer"
    output: dmx_1
    id: dimmer_01
    default_transition_length: 0.1s

# Temperatuur Sensor
one_wire:
  - platform: gpio
    pin: GPIO16

    

Enige wat ik nog ga doen (los van een andere module proberen, die is besteld), is een DMX terminator plaatsen op de uitgang van de boiler. Ik had geen weerstanden meer met de juiste waarde, dus die heb ik ook besteld.

[ Voor 5% gewijzigd door Septillion op 30-04-2025 12:20 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Septillion]

@gastje01 Ah, okay, maar dat zegt dus niet of de dimmer überhaupt correct op DMX reageert.

Qua code, probeer eens de logging op uart uit te zetten. Zou kunnen dat de logger dezelfde uart nu gebruikt en dus "random" data op de DMX bus zet.

YAML:

logger:
  baud_rate: 0

Termination is ook wel wijsheid ja. En als ik even snel kijk dan lijkt me de MAX485 een chip die 5V wil...


PS Neem aan dat je het gaat aansturen via HA? Dan niet je entities prefixen met je device name, dat doet HA al voor je. En waarom geen API?

[gastje01]

Septillion schreef op woensdag 30 april 2025 @ 12:17:
@gastje01 Ah, okay, maar dat zegt dus niet of de dimmer überhaupt correct op DMX reageert.

Zo had ik m nog niet bekeken. Boiler is nieuw (van een inmiddels falliet verklaarde webshop), maar geen garanties natuurlijk.

Qua code, probeer eens de logging op uart uit te zetten. Zou kunnen dat de logger dezelfde uart nu gebruikt en dus "random" data op de DMX bus zet.

YAML:

logger:
  baud_rate: 0

Ga ik vanmiddag testen. Logger gebruik ik in pricipe niet.

Termination is ook wel wijsheid ja. En als ik even snel kijk dan lijkt me de MAX485 een chip die 5V wil...

Hij krijgt ook netjes 5V. Heb 'm even op 3.3V gehad (dacht aan een overstuurd signaal?) maar dan zie ik hetzelfde gedrag. Termination staat in bestelling. Kabeltje is erg kort, geen idee of dat een voordeel of nadeel is voor dit type signaal.

PS Neem aan dat je het gaat aansturen via HA? Dan niet je entities prefixen met je device name, dat doet HA al voor je. En waarom geen API?

Yes, prefix verwijderd, ziet er inderaad een stukje netter uit zo

MQTT heb ik gekozen omdat in principe al mijn devices daar op zitten. Wat zou een voordeel zijn van de API tov MQTT? Dacht altijd dat dat lekker licht was.

[Toppe]

Iemand die hier wat geks ziet?

YAML:

esphome:
  name: zwembad-watertemperatuur
  friendly_name: Zwembad watertemperatuur

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "B3lQ4FFmvn9fNZtPvb6ShaqWr1e86xS3ufwrx6jqt4o="

ota:
  - platform: esphome
    password: "705f4adee1092b9a7c849ec9ddc13b25"

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Zwembad-Watertemperatuur"
    password: "5DP8wAaK0XyE"

captive_portal:

web_server:
  port: 80
  version: 3

one_wire:
  - platform: gpio
    pin: GPIO21

deep_sleep:
  run_duration: 30s
  sleep_duration: 3min

sensor:
  - platform: adc
    pin: 35
    name: Battery
    update_interval: 1s
    attenuation: auto
    filters:
      - multiply: 2

  - platform: dallas_temp
    address: 0x76012211c0650c28
    name: Temperature
    update_interval: 15s

De temperatuur wil met grote regelmaat geen update sturen terwijl de batterij wel netjes doorkomt...

[SnarfB]

Ik wil de output in homeassistant ( percentage ) zichtbaar, hoe kan ik dat doen ?

YAML:

substitutions:
  name: "Deye Fan" # Location and Entity Names (Capitals and Spaces Allowed)
  dallas_addr: "0x1cf2689c1e64ff28" # Put YOUR Dallas Sensor Address here

esphome:
  name: "deye-fan"

esp8266:
  board: d1_mini
  restore_from_flash: true

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

api:
ota:
  platform: esphome

web_server:
  port: 80
  auth:
    username: !secret esphome_web_username
    password: !secret esphome_web_password  

preferences:
  flash_write_interval: 10000s

logger:
  logs:
    dallas.sensor: none
    number: none
    sensor: none
    fan: none

### Add this to fix the Breaking Change one_wire: change ###
### This has now been "fixed" in ESPHome 2024.6.2 and therefore no longer required ###
#external_components:
#  - source:
#      type: git
#      url: https://github.com/ssieb/esphome
#      ref: onewire
#    components: [ gpio ]
#    refresh: 1min
############################################################

number:
  # Slider to set Min Temperature to start fan
  - platform: template
    id: set_temp
    name: $name Set Temp
    optimistic: True
    min_value: 25
    max_value: 45
    initial_value: 35
    step: 1
    restore_value: true # Store setting between reboots

one_wire:
  - platform: gpio
    pin: D7

sensor:
  - platform: dallas_temp
    address:  $dallas_addr
    name: $name Temperature
    id: temp_sensor1
    update_interval: 2s
    accuracy_decimals: 1

  - platform: homeassistant
    id: temp_sensor
    entity_id: sensor.energiebrands_temperature    

    # Adjust fan speed(1-100%). Else, turn it off and set the speed to 1
    on_value:
      - lambda: !lambda |
          auto pct = map(x, id(set_temp).state, id(set_temp).state+5, 0, 100);
          if (pct>1) {
            auto call = id(the_fan).turn_on(); call.set_speed(pct); call.perform();
          } else {
            auto call = id(the_fan).turn_off(); call.set_speed(1); call.perform();
          }


switch:
  # Fan power (MOSFET)
  - platform: gpio
    pin: D3
    id: fan_power

fan:
  - platform: speed
    id: the_fan
    output: fan_pwm
    name: $name Fan
    speed_count: 100
    on_turn_on:
      - switch.turn_on: fan_power
    on_turn_off:
      - switch.turn_off: fan_power


output:
  - platform: esp8266_pwm
    id: fan_pwm
    pin:
      number: D1
    min_power: 0.0 #Slowest Speed for Noctua Fans is 10% - Set to 0 for 'Other' Fans
    frequency: 20.0kHz #Pulse the fan fast to prevent noise

[Septillion]

@Toppe Probeer eens een veel kleinere tijd voor de update van de dallas. Ook 1s bijvoorbeeld.

[Toppe]

Septillion schreef op donderdag 1 mei 2025 @ 19:12:
@Toppe Probeer eens een veel kleinere tijd voor de update van de dallas. Ook 1s bijvoorbeeld.

Dat werkt ook niet. Denk dat ik er achter ben… had hem al in HA gezet zonder deep_sleep. Toen verwijderd, deep sleep toegevoegd en opnieuw in HA opgenomen.

Nu sensor andere naam gegeven, verwijderd en toen hij via autodiscovery terug kwam had hij nog steeds de ‘oude’ naam.

Herstart van HA loste het op, toen werd hij zichtbaar met de nieuwe naam en lijken de updates goed te gaan.

Die tijd zou volgens de geleerde ook niet uit moeten maken bij deep sleep

[DjoeC]

Bij de Dallas temperatuursensoren er rekening mee houden dat snelle verversing meer rekenkracht achter elkaar vergt waardoor de uiteindelijke temperatuur te hoog kan worden. Ook hoge resolutie vergt meer rekenwerk.

[ Voor 3% gewijzigd door DjoeC op 01-05-2025 20:27 ]

[Bockelaar]

Bockelaar schreef op woensdag 23 april 2025 @ 19:41:
mocht je psram errors krijgen op je esphome met de Athome Echo: het is een bugje waar een fix voor aankomt.
Tussenoplossing is om een external component in je yaml toe te voegen:

YAML:

external_components:
  - source: github://esphome/esphome@2025.3.3
    components: [psram]

.
zie ook https://github.com/esphome/esphome/pull/8584

deze bug is opgelost in 2025.4.1 dus de workaround is niet meer nodig

[SnarfB]

Kan iemand mijn helpen, ik heb een aansturing van een ventilator met een PWM output.
Ik zou graag de output in % willen zien in HA, nu is dat schijnbaar zo niet mogelijk maar ik heb gehoord dat dit met een template in ESPhome wel mogelijk is maar ik heb geen idee hoe ik dit moet maken.

YAML:

substitutions:
  name: "Deye Fan" # Location and Entity Names (Capitals and Spaces Allowed)
  dallas_addr: "0x1cf2689c1e64ff28" # Put YOUR Dallas Sensor Address here

esphome:
  name: "deye-fan"

esp8266:
  board: d1_mini
  restore_from_flash: true

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

api:
ota:
  platform: esphome

web_server:
  port: 80
  auth:
    username: !secret esphome_web_username
    password: !secret esphome_web_password  

#preferences:
#  flash_write_interval: 10000s

logger:
  logs:
    dallas.sensor: none
    number: none
    sensor: none
    fan: none

captive_portal:

### Add this to fix the Breaking Change one_wire: change ###
### This has now been "fixed" in ESPHome 2024.6.2 and therefore no longer required ###
#external_components:
#  - source:
#      type: git
#      url: https://github.com/ssieb/esphome
#      ref: onewire
#    components: [ gpio ]
#    refresh: 1min
############################################################

number:
  # Slider to set Min Temperature to start fan
  - platform: template
    id: set_temp
    name: $name Set Temp
    optimistic: True
    min_value: 15
    max_value: 45
    initial_value: 20
    step: 1
    restore_value: true # Store setting between reboots

#one_wire:
#  - platform: gpio
#    pin: D7

sensor:
  - platform: homeassistant
    id: temp_sensor
    entity_id: sensor.energiebrands_temperature

#  - platform: dallas_temp
#    address:  $dallas_addr
#    name: $name Temperature
#    id: temp_sensor1
#    update_interval: 2s
#    accuracy_decimals: 1

    # Adjust fan speed(1-100%). Else, turn it off and set the speed to 1
    on_value:
      - lambda: !lambda |
          auto pct = map(x, id(set_temp).state, id(set_temp).state+4, 25, 100);
          if (pct>1) {
            auto call = id(the_fan).turn_on(); call.set_speed(pct); call.perform();
          } else {
            auto call = id(the_fan).turn_off(); call.set_speed(1); call.perform();
          }


switch:
  # Fan power (MOSFET)
  - platform: gpio
    pin: D3
    id: fan_power

fan:
  - platform: speed
    id: the_fan
    output: fan_pwm
    name: $name Fan
    speed_count: 100
    on_turn_on:
      - switch.turn_on: fan_power
    on_turn_off:
      - switch.turn_off: fan_power


output:
  - platform: esp8266_pwm
    id: fan_pwm
    pin:
      number: D1
    min_power: 0.0 #Slowest Speed for Noctua Fans is 10% - Set to 0 for 'Other' Fans
    frequency: 20.0kHz #Pulse the fan fast to prevent noise

[Septillion]

@SnarfB Op deze manier heb je het toch gewoon als 0-100% sturing onder de fan entity in HA?

[SnarfB]

Septillion schreef op woensdag 7 mei 2025 @ 11:20:
@SnarfB Op deze manier heb je het toch gewoon als 0-100% sturing onder de fan entity in HA?

Nee deze wordt in HA niet getoond

[Gizz]

@SnarfB wat is dan die mooie schuif onder bediening? Klik er eens op. Die gaat toch van 0% tot 100%?

Zo ziet het er bij mij uit:



Bij mij wordt de waarde binnen HA vastgesteld en niet binnen ESPHome, maar dat maakt verder niet uit. Het blijft een slider van 0 tot 100%.

[ Voor 74% gewijzigd door Gizz op 07-05-2025 15:13 ]

[Septillion]

@Gizz Dat is zijn template number.

@SnarfB Open je fan entity, daar zal gewoon een speed slider staan.

[Toppe]

Weet iemand of het mogelijk is om een dag en nacht optie met deep_sleep te gebruiken?

Ik wil ‘s nachts 1x per uur een waard een overdag elke 10 minuten maar kan er weinig over vinden

[sjorsjuhmaniac]

Toppe schreef op zondag 11 mei 2025 @ 16:55:
Weet iemand of het mogelijk is om een dag en nacht optie met deep_sleep te gebruiken?

Ik wil ‘s nachts 1x per uur een waard een overdag elke 10 minuten maar kan er weinig over vinden

Dynamic deep sleep zou daarvoor moeten werken.

[jj85]

Toppe schreef op zondag 11 mei 2025 @ 16:55:
Weet iemand of het mogelijk is om een dag en nacht optie met deep_sleep te gebruiken?

Ik wil ‘s nachts 1x per uur een waard een overdag elke 10 minuten maar kan er weinig over vinden

Ik doe iets soortgelijks, update overdag elk uur en 's avonds een langere slaap. Hier zou je een variatie op kunnen maken.

YAML:

  #settings
  sleep_time: 60min
  wake_time: 60s #default wake time
  screen_update_time: 18s

 


deep_sleep:
  id: deep_sleep_1
  run_duration: ${wake_time}
  sleep_duration: ${sleep_time}
            


time:
  - platform: homeassistant
    id: esptime
    timezone: Europe/Amsterdam
    on_time_sync:
      - then:
          - logger.log: Time has been set and is valid!       
    on_time:
      # Every evening after 22:00
      - hours: 22
        then:
          - logger.log: Going for a sleep during the night. Good night!   
          - deep_sleep.enter:
              id: deep_sleep_1
              until: "6:00:00"
              time_id: esptime

[alex3305]

Afgelopen weken heb ik ESPHome weer wat meer opgepakt. Ik heb al een paar jaar een aantal IKEA VINDRIKTNING met Wemos D1 Mini (ESP8266) draaien, maar ik wilde ook eens gaan spelen met o.a. BLE en mmWave presence detection. En daarmee dus ook die sensoren updaten.

Eerder dit jaar heb ik voor BLE presence detection wat goedkope OEM Lolin32 Lite bordjes op de kop getikt. Eerst met ESPresense, later met Bermuda. Dat werkte wel, maar enorm veel valse positieve die ik toch niet helemaal weg kreeg. Ook was er enorm veel verschil in gain tussen de verschillende bordjes. Dus dat heb ik als op zichzelf staand project laten varen.

Daarom heb ik een paar weken geleden een aantal LD2410's mmWave sensoren en een partijtje ESP32-C3 Super Mini bordjes gekocht bij Ali. Maar helaas heb ik een variant gekocht met een brak antenne design waardoor deze enorm onbetrouwbaar zijn. Met name als je de hardware TX/RX pinnen van de C3's gebruikt. Die ik nodig heb voor de LD2410.

Vandaar heb ik besloten om verder te gaan met ESP32-C6. Om precies te zijn de bordjes van DFRobot. Maar ook dit lijk ik niet stabiel te krijgen onder ESPHome .

Mijn sketch met een SCD40, BMP280 en CCS811 over I2C, PM1006 en LD2410 over UART en BLE past echt net op het flashgeheugen van 4MB. Maar dan zonder web server of captive portal. Ik gebruik de Home Assistant API, maar soms valt de verbinding ineens weg en komt ook niet meer terug. Via MQTT kan ik niet eens een stabiele verbinding tot stand brengen.

Mijn (relevante) code:

YAML:

esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: false
  min_version: 2025.4.1
  platformio_options:
    build_flags: "-DI2C_NUM_1=I2C_NUM_0"  # [esp32-c6]

esp32:
  board: esp32-c6-devkitm-1
  flash_size: 4MB
  variant: ESP32C6
  framework:
    type: esp-idf
    # Zelfde problemen op 5.3.1 met platform 6.9.0.
    version: 5.4.1
    platform_version: 54.03.20
    sdkconfig_options:
      # Ensure 4MB flash (probably not needed?)
      CONFIG_ESPTOOLPY_FLASHSIZE_4MB: y

      # Setup Wi-Fi
      CONFIG_OPENTHREAD_ENABLED: n
      CONFIG_ENABLE_WIFI_STATION: y
      CONFIG_USE_MINIMAL_MDNS: y

      # Setup Bluetooth
      CONFIG_BT_CTRL_MODEM_SLEEP: y
      CONFIG_BT_BLE_DYNAMIC_ENV_MEMORY: y
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: n  # [bt]
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y  # [bt]

      # Increase the watchdog timeout to 10s to give low powered
      # devices a little bit more breathing room.
      CONFIG_ESP_TASK_WDT: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"

      # Enable Compiler optimization for size
      CONFIG_COMPILER_OPTIMIZATION_SIZE: y
      CONFIG_COMPILER_OPTIMIZATION: "size"

api:
  encryption:
    key: ${api_encryption_key}

# Ook PR #8483 geprobeerd, maar deze nieuwe I2C driver herkent
# mijn CCS811 en (fake) BMP280 niet
i2c:
  sda: GPIO19
  scl: GPIO20
  scan: false
  frequency: 100kHz

# LD2410 sensoren allemaal weggelaten, ik heb alles vanuit de officiële documentatie,
# maar is zo'n 300 regels configuratie en opmerkingen
# 🌍 https://esphome.io/components/sensor/ld2410.html
ld2410:
  id: ld2410_sensor
  uart_id: uart_ld2410
  throttle: 2s

light:
  - platform: status_led
    id: status_led_1
    internal: true
    restore_mode: ALWAYS_OFF
    pin:
      number: GPIO15

ota:
  platform: esphome
  password: "${esphome_ota_password}"

safe_mode:
  boot_is_good_after: 1min
  reboot_timeout: 5min

# Sensor details weggelaten, maar alles heeft configuratie incl.
# filters om het aantal updates te verminderen.
sensor:
  - platform: bmp280_i2c
  - platform: ccs811
  - platform: pm1006
  - platform: scd4x

uart:
  # Hardware UART for LD2410
  - id: uart_ld2410
    tx_pin: GPIO16
    rx_pin: GPIO17
    baud_rate: 256000  # [ld2410]
    parity: NONE
    stop_bits: 1

  # Dedicated UART for PM1006
  - id: uart_pm1006
    rx_pin: GPIO4
    baud_rate: 9600

# Hier ook power_save_mode geprobeerd en tevens btm/rrm
# maar maakt geen enkel verschil in stabiliteit.
wifi:
  ssid: ${wifi_ssid}
  password: ${wifi_password}
  domain: ${wifi_domain}

  ap:
    ssid: ${name}
    password: ""

Wat ik vooral gek vind is dat de Heap Free (~120-150kB) en 15-20ms loop time mij niet echt slecht of bizar lijken. En soms werkt het ook meerdere uren totdat het ineens niet meer werkt. Ook zonder het BLE component trouwens. Zelfs OTA is dan ook nog mogelijk en werkt gewoon. Ik weet dus ook totaal niet meer wat ik nog zou kunnen proberen. Ik zie door de bomen het bos niet meer .

[gastje01]

gastje01 schreef op woensdag 30 april 2025 @ 11:39:
[...]


Als je de fysieke slider op de dimmer aanpast, dan negeert ie het DMX signaal en pakt ie de waarde die je op de slider instelt, het dim gedeelte werkt dus. Wanneer ik dezelfde waarde via DMX instel (zeg 30%) schiet t alle kanten op.

Ik gebruik deze module: https://www.amazon.com/AL...icator/dp/B08XLT21S6?th=1

en deze code om t spul aan te sturen:

YAML:

esphome:
  name: boiler-dmx
  friendly_name: Boiler-DMX


esp32:
  board: wemos_d1_mini32

# Enable logging
logger:

mqtt:
  broker: 192.168.1.15
  username: boileruser
  password: boilerpwd

ota:
  - platform: esphome
    password: "d52e1c2b45cbbf49f65274554a840ece"

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

external_components:
  - source: github://andyboeh/esphome-dmx512

substitutions:
  device_name: "Boiler DMX Controller"

uart:
  id: uart_bus
  baud_rate: 250000
  tx_pin:
    number: GPIO22
    allow_other_uses: true
  stop_bits: 2

dmx512:
  id: dmx
  uart_id: uart_bus
#  enable_pin: 33
  tx_pin:
    number: GPIO22
    allow_other_uses: true
  uart_num: 1

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${device_name} IP

sensor:
  - platform: uptime
    name: ${device_name} Uptime
  - platform: wifi_signal
    name: ${device_name} WiFi Signal
    update_interval: 60s
  - platform: dallas_temp
    name: Boiler Temperatuur
    update_interval: 20s


output:
  - platform: dmx512
    channel: 1   
    universe: dmx
    id: dmx_1
#   min_power: 0.1
#   max_power: 0.95 

light:
  - platform: monochromatic
    name: "${device_name} Dimmer"
    output: dmx_1
    id: dimmer_01
    default_transition_length: 0.1s

# Temperatuur Sensor
one_wire:
  - platform: gpio
    pin: GPIO16

    

Enige wat ik nog ga doen (los van een andere module proberen, die is besteld), is een DMX terminator plaatsen op de uitgang van de boiler. Ik had geen weerstanden meer met de juiste waarde, dus die heb ik ook besteld.

Om toch na wat zoeken de oplossing te vermelden:

Ik heb een weerstand aan de Dimmer kant geplaatst (zoals DMX dat officieel voorschrijft), dat gaf al enige verbetering.

Toen viel het me op dat het 'dippen' exact 2x per seconde gebeurde. In de code is de standaard update interval 500ms (2 Hz), nu ik deze op 50 heb gezet, werkt alles perfect zoals ik bedacht had!

Blijkbaar wil de dimmer vaker een signaal hebben anders gaat ie terug naar 0.

[Septillion]

@gastje01 Aha, dan ligt dat feitelijk aan de lamp. Klinkt als of die een minimale update interval nodig heeft, anders denkt hij dat hij geen DMX krijgt.

Staat met dat dippen dan de schuif op de unit op 0?

[gastje01]

Septillion schreef op dinsdag 13 mei 2025 @ 10:38:
@gastje01 Aha, dan ligt dat feitelijk aan de lamp. Klinkt als of die een minimale update interval nodig heeft, anders denkt hij dat hij geen DMX krijgt.

Staat met dat dippen dan de schuif op de unit op 0?

Yes. Met de schuif maak je er een handmatige dimmer van en wordt het DMX signaal compleet genegeerd (als dat er al is).

Ik ben op het verkeerde been gezet omdat het DMX lampje wel netjes blijft knipperen (=signaal) en had eigenlijk verwacht dat de dimmer een waarde zou vasthouden tot er een nieuwe waarde gestuurd wordt of de huidige waarde bevestigd wordt, maar zo werkt het blijkbaar niet.

[Septillion]

@gastje01 Op zich doet hij dat dus ook, maar denk dat hij na 400ms ofzo denkt, uhh, geen DMX meer, ik neem de handmatige dimmer waarde aan. Waarna dus iets later toch een DMX pakket binnen komt en hij die waarde weer aanneemt. 2Hz is ook aardig traag voor DMX. Maximale snelheid voor full frame (alle 512 kamelen) is 44Hz.

[ThinkPad]

Ik had een M5Stack Atom Lite liggen en had hier ESPHome op gezet. Ik heb er ook een "BPS' sensor bij. Opdruk op de PCB hiervan 'BMP280', maar daarmee kreeg ik het niet werkend. Na enig uitzoeken blijkt dat het een QMP6988 sensor is.

Hiermee heb ik het werkend (relevante delen even eruit gepikt):

YAML:

esp32:
  board: m5stack-atom


i2c:
  sda: GPIO26
  scl: GPIO32
  #scan: true


  - platform: qmp6988
    temperature:
      name: "QMP6988 Temperature"
    pressure:
      name: "QMP6988 Pressure"
    address: 0x70
    update_interval: 60s

[barrymossel]

Ik kom er even echt niet meer uit. Ik hang een ESP32 aan ESPHome Builder, maak een nieuw device aan en installeer hem. Ik zet er een willekeurige sensor in en integreer hem in HA: de enige entity is firmware. Wat ik ook doe...

YAML:

esphome:
  name: ventilatoren-tv
  friendly_name: Ventilatoren TV

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

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

ota:
  - platform: esphome
    password: "XXXXXXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  domain: .different
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Ventilatoren-Tv Fallback Hotspot"
    password: "XXXXX"

captive_portal:
  
text_sensor:
  - platform: wifi_info
    ssid:
      name: ESP Connected SSID

Iemand enig idee wat er fout zou kunnen zijn?

---edit---
Even een toevoeging: de ESPHome en HA zitten in verschillende VLANs (al zitten de ESP8266s die wél werken daar ook in). Heb al drie verschillende ESP32s geprobeerd...

---edit2---
Het lijkt erop dat wanneer ik de yaml aanpas en opnieuw (bedraad) naar de ESP schrijf er helemaal geen nieuwe code op komt te staan. Zojuist een ander domain en vast IP eraan proberen te hangen via de yaml, maar daar doet ie helemaal niks mee...?

---edit3---
bin downloaden en via https://web.esphome.io/ uploaden werkt wél. Geen idee waarom, maar best...

[ Voor 21% gewijzigd door barrymossel op 17-05-2025 13:08 ]

[Septillion]

@barrymossel Klinkt alsof je OTA faalt. Zie je gewoon succesvolle upload in de log tijdens een upload?

[barrymossel]

Septillion schreef op vrijdag 16 mei 2025 @ 20:23:
@barrymossel Klinkt alsof je OTA faalt. Zie je gewoon succesvolle upload in de log tijdens een upload?

Uploaden doe ik via USB, aangezien ik het domein moest aanpassen om OTA te doen (en dat lukte dus niet, omdat de upload niet werkte). En hij geeft gewoon netjes aan dat die upload succesvol is, maar niet dus...

[Septillion]

@barrymossel Dus in beide gevallen probeer je het via de USB te doen? En je kreeg gewoon een success te zien voor de upload (en niet alleen voor de compile!)?

[barrymossel]

Septillion schreef op zondag 18 mei 2025 @ 15:23:
@barrymossel Dus in beide gevallen probeer je het via de USB te doen? En je kreeg gewoon een success te zien voor de upload (en niet alleen voor de compile!)?

Klopt. OTA werkte sowieso niet door het domain. USB upload via HA/builder gaf een success (je ziet dan niet eens een compile (behalve installatie voorbereiden - wat neem ik aan de compile is). Download en upload via https://web.esphome.io/ laat precies dezelfde success zien en dan werkt het wel.

[Septillion]

@barrymossel Owja, dan liet ESPHome geen console met logging zien. Heel raar eigenlijk.

Maar wat voor domein? Zolang HA en de ESP met elkaar kunnen praten dan kan je ook wel OTA doen. Alleen als de resolve niet kan, kan je use_address gebruiken met het IP (of iets dat wel te resolve is door ESPhome).

[barrymossel]

Septillion schreef op zondag 18 mei 2025 @ 17:56:
@barrymossel Owja, dan liet ESPHome geen console met logging zien. Heel raar eigenlijk.

Maar wat voor domein? Zolang HA en de ESP met elkaar kunnen praten dan kan je ook wel OTA doen. Alleen als de resolve niet kan, kan je use_address gebruiken met het IP (of iets dat wel te resolve is door ESPhome).

Hij gaat nu standaard naar .local en bij mij zitten ze in een ander domein. Dan vindt ie ze niet. Maar use_address kende ik niet. En dan nog, die krijg ik dus zonder USB niet eens in de ESP... Maakt ook niet uit, want via USB is het net zo makkelijk. ALS het werkt... Maar goed, geen idee wat er mis gaat, gelukkig werkt het nu op deze manier wel.

[Septillion]

@barrymossel jawel, want use_address doet niets met de code zelf en wordt alleen door ESPhome gebruikt wanneer het contact zoekt (upload of log). Dat is ook want je kan gebruiken om een OTA te doen wanneer je het device name aanpast en dus ten tijde van de upload het dus nog niet nieuwe-naam.local is maar nog oude-naam.local.

En dan heb je niet zo zeer een ander domein maar een afgesloten stukje netwerk en draai je geen mDNS reflector.

[Hermarcel]

@barrymossel Ik heb ook een ander domein dan .local en dat werkt prima. Draai wel een eigen DNS server. Heb de mdns functionaliteit van ESPhome zelfs uitgeschakeld. Wel je domain opgeven in de yaml:

YAML:

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

Waarbij "domain" dus in je secrets staat en iets als ".abcd.nl" is (let op: begint met een punt).

[barrymossel]

Septillion schreef op zondag 18 mei 2025 @ 18:16:
@barrymossel jawel, want use_address doet niets met de code zelf en wordt alleen door ESPhome gebruikt wanneer het contact zoekt (upload of log). Dat is ook want je kan gebruiken om een OTA te doen wanneer je het device name aanpast en dus ten tijde van de upload het dus nog niet nieuwe-naam.local is maar nog oude-naam.local.

En dan heb je niet zo zeer een ander domein maar een afgesloten stukje netwerk en draai je geen mDNS reflector.

Ah top, dat wist ik niet.

Hermarcel schreef op zondag 18 mei 2025 @ 23:55:
@barrymossel Ik heb ook een ander domein dan .local en dat werkt prima. Draai wel een eigen DNS server. Heb de mdns functionaliteit van ESPhome zelfs uitgeschakeld. Wel je domain opgeven in de yaml:

YAML:

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

Waarbij "domain" dus in je secrets staat en iets als ".abcd.nl" is (let op: begint met een punt).

Zo heb ik het ook, maar ik kreeg dus geen nieuwe code via de builder op de ESP, dus ook niet het domain stukje. Via die ESPHome website lukte dat wel en dan is de ESP ook gewoon online.

[Septillion]

@barrymossel Dat domain werkt alleen als er werkelijk iets in je netwerk is dat er voor zorgt dat je device-name.domain kunt resolven. Standaard is dat dus via mDNS voor .local. Dat is multicast dus gaat standaard niet over VLANS heef, dan heb je een reflector nodig.

Wil je domain inzetten zal je bijvoorbeeld via je eigen DNS server moeten zorgen dat je device-name.domain kunt resolven (vanuit ESPhome).

[alex3305]

Een follow-up van mijn vorige post. Inmiddels heb ik het soort van werkend. Ik heb twee ESP32-C6 draaien en beide laten zien nog een paar keer per dag te crashen. De enige reset reden die ik dan krijg vanuit het debug component is: Software reset via esp_restart. Inmiddels gebruik ik de nieuwe I2C driver en dat verbeterd met esp-idf 5.5 de stabiliteit dus aanzienlijk.

Ik vermoed dat een van de watchdogs de reset triggered. Ik ben dus nu nog aan het testen met langere watchdogs om te kijken of dat de boel verbeterd. Relevante code:

YAML:

esphome:
  min_version: 2025.4.1
  platformio_options:
    build_flags: "-DI2C_NUM_1=I2C_NUM_0"  # [esp32-c6]

esp32:
  board: esp32-c6-devkitm-1
  flash_size: 4MB
  variant: ESP32C6
  framework:
    type: esp-idf
    version: 5.5.0
    release: "ard33a"
    platform_version: 54.03.20
    sdkconfig_options:
      # Ensure 4MB flash (probably not needed?)
      CONFIG_ESPTOOLPY_FLASHSIZE_4MB: y

      # Setup Wi-Fi
      CONFIG_OPENTHREAD_ENABLED: n
      CONFIG_ENABLE_WIFI_STATION: y
      CONFIG_USE_MINIMAL_MDNS: y

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

      # Increase the watchdog timeout to 10s to give low powered
      # devices a little bit more breathing room.
      CONFIG_ESP_TASK_WDT_EN: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "30"
      
      CONFIG_ESP_INT_WDT: y
      CONFIG_ESP_INT_WDT_TIMEOUT_MS: "1000"

external_components:    
  - source: github://pr#8483
    components: [ i2c ]

[J-sto]

alex3305 schreef op maandag 19 mei 2025 @ 14:28:
Een follow-up van mijn vorige post. Inmiddels heb ik het soort van werkend. Ik heb twee ESP32-C6 draaien en beide laten zien nog een paar keer per dag te crashen. De enige reset reden die ik dan krijg vanuit het debug component is: Software reset via esp_restart. Inmiddels gebruik ik de nieuwe I2C driver en dat verbeterd met esp-idf 5.5 de stabiliteit dus aanzienlijk.

Ik vermoed dat een van de watchdogs de reset triggered. Ik ben dus nu nog aan het testen met langere watchdogs om te kijken of dat de boel verbeterd. Relevante code:

YAML:

esphome:
  min_version: 2025.4.1
  platformio_options:
    build_flags: "-DI2C_NUM_1=I2C_NUM_0"  # [esp32-c6]

esp32:
  board: esp32-c6-devkitm-1
  flash_size: 4MB
  variant: ESP32C6
  framework:
    type: esp-idf
    version: 5.5.0
    release: "ard33a"
    platform_version: 54.03.20
    sdkconfig_options:
      # Ensure 4MB flash (probably not needed?)
      CONFIG_ESPTOOLPY_FLASHSIZE_4MB: y

      # Setup Wi-Fi
      CONFIG_OPENTHREAD_ENABLED: n
      CONFIG_ENABLE_WIFI_STATION: y
      CONFIG_USE_MINIMAL_MDNS: y

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

      # Increase the watchdog timeout to 10s to give low powered
      # devices a little bit more breathing room.
      CONFIG_ESP_TASK_WDT_EN: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "30"
      
      CONFIG_ESP_INT_WDT: y
      CONFIG_ESP_INT_WDT_TIMEOUT_MS: "1000"

external_components:    
  - source: github://pr#8483
    components: [ i2c ]

Voor de duidelijkheid, dit is geen ESP32-C6 supermini, of wel?
Ik ben al even op zoek of die supermini aan esphome te koppelen is, maar dit wordt nog niet ondersteund.
Als ik probeer te connecten valt ook elke paar seconden de verbinding weg, dus kan ik hem ook niet flashen vanuit esphome helaas.

[alex3305]

J-sto schreef op maandag 19 mei 2025 @ 20:58:
[...]

Voor de duidelijkheid, dit is geen ESP32-C6 supermini, of wel?

Nee een DFRobot Beetle. Ik heb een aantal C3 Super Mini's gehad, maar die zijn aardig instabiel door de brakke wifi antenne.

Ik ben al even op zoek of die supermini aan esphome te koppelen is, maar dit wordt nog niet ondersteund.
Als ik probeer te connecten valt ook elke paar seconden de verbinding weg, dus kan ik hem ook niet flashen vanuit esphome helaas.

Probeer de wifi output_power maar eens te verminderen naar 8.5dB (het minimum), dan zou het wellicht kunnen werken.

[Gondelier]

Ik krijg mijn m5stack-atom-echo weer niet geüpgraded naar 2025.5.0
Meer gebruikers hier last van ??

[Gizz]

@Gondelier waar gaat het mis? Compilen, flashen (OTA, bedraad?)?

Als je geen specifieke foutmelding met ons deelt wordt het lastig om je te helpen

[ Voor 40% gewijzigd door Gizz op 24-05-2025 10:20 ]

[Gondelier]

Gizz schreef op zaterdag 24 mei 2025 @ 09:24:
@Gondelier waar gaat het mis? Compilen, flashen (OTA, bedraad?)?

Als je geen specifieke foutmelding met ons deelt wordt het lastig om je te helpen

@Gizz
Dank voor je reactie, maar ik kreeg 5 updates voor mijn esphome devices bij instellingen.
Vier van de vijf liepen gewoon en hebben geen problemen gegeven, en een kreeg ik niet voor elkaar, onder in het scherm even heel snel een error en alles is bedraad.
MAAR vanmorgen weer geprobeerd en toen liep de update gewoon door.
Ra ra

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