Het grote ESPhome topic

[Septillion]

@RobertMe Misschien eens volledig wissen en dan weer voorzien van Kickstarter ofzo? Nooit gehad iig.

Qua programmeren, niet een van die bordjes die je dan handmatig in programming moet zetten dan?

[RobertMe]

Septillion schreef op zondag 16 november 2025 @ 13:41:
@RobertMe Misschien eens volledig wissen en dan weer voorzien van Kickstarter ofzo? Nooit gehad iig.

Dat zou ik idd wel kunnen proberen. Wat het vooral gek maakt is dat het "ineens" is. Ik heb dit bordje dus niet in gebruik genomen, maar wel eerder "gebruikt". En paar weken terug toen er een use case kwam nog eens afgestoft en de oude ESPHome werkte gewoon prima (alleen kon ik niet rebuilden / updaten omdat de externe component voor dit scherm voor de zoveelste keer stuk was). En gisteren dan opnieuw geflasht met de nieuwste ESPHome (en dan die WIP PR voor het scherm) en toen startte die ook nog goed. En ik denk gisteren ook een aantal keren USB er uit gehad en dus ook dat die na de eerste flash nog vaker heeft geboot.

Qua programmeren, niet een van die bordjes die je dan handmatig in programming moet zetten dan?

Gezien ik hem met esptool.py prima kan flashen vanaf de CLI lijkt me dat niet? Als in: geen knoppen voor nodig. Maar idd, ik had ook al een hele puzzel doorlopen om te achterhalen hoe het zit met boot / flash knoppen op dit bord. Want die staan niet duidelijk aangegeven ondanks dat er 5 knoppen op zitten. Maar reset zou "S5" moeten zijn, die direct tegen de ESP aan zit, en boot zou "S6" zijn die direct naast S5 zit.

Edit:
@Septillion

1. esptool.py -p /dev/ttyACM0 erase_flash
2. esptool.py -p /dev/ttyACM0 write_flash 0x0 zonder-static-ip.bin

Same result. DHCP request is voor .111.
Dus tenzij er een manier is om nog meer te verwijderen..., denk ik niet dat het uit maakt?

[ Voor 10% gewijzigd door RobertMe op 16-11-2025 14:05 ]

[Septillion]

@RobertMe Dan ben ik ook even uit ideeën. Nooit eerder gehad

[sjorsjuhmaniac]

@RobertMe en als je een eigenwijs een fixed ip in de yaml zet? Niet wat je wilt maar mogelijk wel werkbaar

[RobertMe]

sjorsjuhmaniac schreef op zondag 16 november 2025 @ 17:02:
@RobertMe en als je een eigenwijs een fixed ip in de yaml zet? Niet wat je wilt maar mogelijk wel werkbaar

Dan werkt het (en had ik denk ik al aangegeven?). Maar als ik dan opnieuw flash zonder static IP probeert die weer doodleuk de .111. Dus dan is het wel permanent om een static IP in de config te zetten.

[RobertMe]

Wat is nu de manier om met (fysieke) knoppen om te gaan richting HA? De voorbeelden die ik tegen kom gaan voornamelijk over binary_sensors, niet alleen intern, maar ook richting HA, brrr (state events op dat een binary sensor naar on gaat). Event entities lijken tegenwoordig wel te kunnen (of nouja, nog steeds in ESPHome zelf triggeren op basis van binary_sensor, maar op zich valt dat te begrijpen gezien je dan combo's met single, double, long, ... kunt maken). Maar die schijnen geen UI support te hebben in HA (dus in de automation builder), en daarnaast, waren event entities niet super crap? Iets met niet (altijd?) triggeren als je twee keer achter elkaar dezelfde "actie" doet, omdat dan hetzelfde event getriggert wordt? / de trigger is dan het event in totaal en vervolgens moet je met een condition filteren? Of is dat in de HA kant verbeterd?

Verder heb ik denk ik alleen Zigbee knoppen, die met Z2M als MQTT device triggers binnen komen. Totaal andere route dus die niet van toepassing is op ESPHome.

Edit:
Of ik check eens wat ze zelf doen De Voice PE gebruikt events (bij de double, tripple , ... clicks. De single click exposen ze niet omdat die acties op het apparaat zelf doet). Maar geen idee of die vervolgens wel of niet zichtbaar zijn in de automation UI etc.

[ Voor 12% gewijzigd door RobertMe op 17-11-2025 22:09 ]

[RobertMe]

Ander vraagje...

Ik probeer de resterende duur uit Home Connect weer te geven op het display. In HA is dit een sensor met device_class duration, unit h (/hour). Voorbeeld state (devtools) is 1.166<...>7 en wordt in de UI weergegeven als 1h10m. Maar, deze sensor is "unavailable" als het apparaat niet actief is. Hoe kan ik hier op controleren in ESPHome? Ik heb wel id(...).has_state() gevonden, maar deze lijkt "altijd" true te zijn? En zal dus wel gebaseerd zijn op "er is een verbinding met HA (en de entity bestaat) dus is er een state". Waarbij de invalid state ("unavailable", voor een sensor, die dus een float moet zijn) doodleuk genegeerd wordt? Waarbij die nu met een printf(..., "%f", id(...).state) heel mooi een "nan" weergeeft.

Edit:
Of ik vind het binnen 5 minuten Standaard C functie isnan in combinatie met ESPHomes raw_state. Dus bv:

C:

if (!isnan(id(...).raw_state)) {
  it.printf(...., "%.0f", id(...).state);
}

[ Voor 13% gewijzigd door RobertMe op 18-11-2025 10:08 ]

[Septillion]

@RobertMe Meestal doe ik toch gewoon als binary_sensor. Event entities zijn op zich nu wel de nieuwe weg en op zich ook prima in de UI te doen. Maar er is gewoon geen event-entity trigger. Dus ben je aangewezen op de state trigger. Daarmee kan je alleen op de state triggeren en niet op event type omdat laatste een attribute is dat, logischerwijs, niet wijzigt als er inderdaad twee keer hetzelfde event type volgt. Naar mijn idee ontbreekt er dus een event entity trigger.

Nu kan je daar met een losse condition of een template wel omheen werken. Dus voor ons hoeft het op zich geen probleem te zijn. Maar gebruikersvriendelijk is anders Om dat gat te vullen zou er dus een event entity trigger (of aanvulling op de event trigger) moeten komen IMHO.

En werkt isnan() niet ook gewoon met state?

[RobertMe]

Septillion schreef op woensdag 19 november 2025 @ 08:42:
@RobertMe Meestal doe ik toch gewoon als binary_sensor. Event entities zijn op zich nu wel de nieuwe weg en op zich ook prima in de UI te doen. Maar er is gewoon geen event-entity trigger. Dus ben je aangewezen op de state trigger. Daarmee kan je alleen op de state triggeren en niet op event type omdat laatste een attribute is dat, logischerwijs, niet wijzigt als er inderdaad twee keer hetzelfde event type volgt. Naar mijn idee ontbreekt er dus een event entity trigger.

Nu kan je daar met een losse condition of een template wel omheen werken. Dus voor ons hoeft het op zich geen probleem te zijn. Maar gebruikersvriendelijk is anders Om dat gat te vullen zou er dus een event entity trigger (of aanvulling op de event trigger) moeten komen IMHO.

Nog een leuke WTF. Als ik nu de ESP reboot (/reflash) dan triggert het event, maar behoud (daarna) de oude state (/timestamp). Dus in HA zie ik nu als state van het event dat het het laatst om bv 17:55+00:00 heeft plaatsgevonden, maar de automation (of eigenlijk trigger based template) wordt wel uitgevoerd elke keer Ik gok dus dat die naar unavailable gaat en daarna weer terug komt met de oude state, "alsof er iets gebeurd is". Hopelijk is dat dan weer wel te fixen door de state trigger uit te breiden met een not_from: unavailable. Maar wel echt slecht dat dat nodig is.

En werkt isnan() niet ook gewoon met state?

Uhm.... Ik ben al blij dat dit werkt * RobertMe vind de docs v.w.b. C(++) code schrijven gewoon echt slecht. An zich heb ik er geen probleem mee als/dat ik ook een deel C(++) docs er bij moet zoeken. Maar wat nu uit id(...) rolt is ook nogal magie naar mijn idee. Categorie dus dat het bij een sensor een float oplevert, bij een text_sensor een std::string etc. En dat je dan bij een it.printf (bij een display) weer zelf een .c_str() er bij moet gooien om %s in het format te gebruiken (wellicht logisch in C(++) omdat std::string relatief nieuw is en by default je met char[] zit, maar ESPHome mag hier toch wel iets in meewerken IMO).