GPIO8 voor 1-wire vind ik nog niet zo spannend. Deze pin moet hoog zijn tijdens boot, daar zorgt juist de pull up al voor. En een 1-wire slave zal niet uit zichzelf de lijn laag trekken. Dus juist 1-wire is best een goede om GPIO8 te kunnen gebruiken
@tcw82 Heeft het geholpen?
En ja, kan dus met zelfde yaml. Op de achtergrond wordt er eerst heel veel geïnstalleerd om een hele pipeline te maken. Dan pas wordt je yaml omgezet in C++ code, dan worden alle libraries gecompilet of geladen, dan pas je, nu in C++ zijnde, config gecompilet en dan alles gelinkt. Maar op de achtergrond wordt er dus nogal wat aangemaakt. Clean build files gooit dat allemaal weg zodat de hele boel vers opgebouwd moet worden.
En ja, kan dus met zelfde yaml. Op de achtergrond wordt er eerst heel veel geïnstalleerd om een hele pipeline te maken. Dan pas wordt je yaml omgezet in C++ code, dan worden alle libraries gecompilet of geladen, dan pas je, nu in C++ zijnde, config gecompilet en dan alles gelinkt. Maar op de achtergrond wordt er dus nogal wat aangemaakt. Clean build files gooit dat allemaal weg zodat de hele boel vers opgebouwd moet worden.
Ik moest werken(5 uur van huis), ik kan niet bij ha vanuit het werk. Als ik uitgewerkt ben ga ik dit natuurlijk even testen.Septillion schreef op woensdag 4 maart 2026 @ 10:28:
@tcw82 Heeft het geholpen?
En ja, kan dus met zelfde yaml. Op de achtergrond wordt er eerst heel veel geïnstalleerd om een hele pipeline te maken. Dan pas wordt je yaml omgezet in C++ code, dan worden alle libraries gecompilet of geladen, dan pas je, nu in C++ zijnde, config gecompilet en dan alles gelinkt. Maar op de achtergrond wordt er dus nogal wat aangemaakt. Clean build files gooit dat allemaal weg zodat de hele boel vers opgebouwd moet worden.
De one wire op pin 8 is een ongelukkige (on-ervaringsdeskundige) keuze geweest uit het verleden.Septillion schreef op woensdag 4 maart 2026 @ 10:24:
GPIO8 voor 1-wire vind ik nog niet zo spannend. Deze pin moet hoog zijn tijdens boot, daar zorgt juist de pull up al voor. En een 1-wire slave zal niet uit zichzelf de lijn laag trekken. Dus juist 1-wire is best een goede om GPIO8 te kunnen gebruiken
Dat kan uiteraard makkelijk anders. het werkte verder goed, voor alle 7 ESP32 die op custom PCBtjes (met haradwired die one wire dingen op de pin 8 (DOH!) ) door het huis slingeren.
Ik ga vanmiddag beginnen met de clean en dan eens verder kijken.
inmiddels ook gelezen dat herinstaleren van ESPhome kan helpen.
De stekker is al uit de RPi geweest, een echte boot is daarmee volgens mij bewerkstelligt.
Er is niets mis met je redenering. Maar je moet nooit de goden verzoeken als er ook gewone poorten beschikbaar zijn. Het was ook maar een advies.Septillion schreef op woensdag 4 maart 2026 @ 10:24:
GPIO8 voor 1-wire vind ik nog niet zo spannend. Deze pin moet hoog zijn tijdens boot, daar zorgt juist de pull up al voor. En een 1-wire slave zal niet uit zichzelf de lijn laag trekken. Dus juist 1-wire is best een goede om GPIO8 te kunnen gebruiken
Ik weet het, ik wist het toen niet.GJzon schreef op woensdag 4 maart 2026 @ 11:40:
[...]
Er is niets mis met je redenering. Maar je moet nooit de goden verzoeken als er ook gewone poorten beschikbaar zijn. Het was ook maar een advies.
PCBtjes waren gemaakt voor specifieke taken en hebben daarmee weerstandjes en Jst stekkertjes aanboord, nieuwe draadjes trekken is wel mogelijk maar niet heel praktisch. Een volgende iteratie heeft dit natuurlijk anders!
Ik heb een esp01 op mijn garagedeur werkend met deze delay en dat werkt naar behoren. Probeer nu eenzelfde opzet maar dan met d1 mini voor een vriend. Met de switch kan ik ook het relay schakelen zonder dat deze automatisch uit gaat.GJzon schreef op woensdag 4 maart 2026 @ 08:10:
[...]
@-Casper
150 ms is wel heel kort om iets te testen...misschien eerst even op een paar seconden zetten?
Punt is dat ie op dit moment niets doet. Ik hoor m ook niet klikken.
Zal de config van septillion nog ff proberen en kijken of dat nog iets uitmaakt.
Dat is niet de bedoeling natuurlijk. Gisteren avond zat ik scheel kijkend achter de PC, de wekker gaat om 0450 en ik zat al voorbij de bedtijd. Straks ga ik er naar kijken.Septillion schreef op woensdag 4 maart 2026 @ 13:00:
@tcw82 Ahj, okay. Door je reactie was ik een beetje aan het twijfelen of je het nu wel of niet al getest had.
@GJzon Eens hoor als je de keuze nog hebt. Maar zou er geen printen voor weg doen nu hij voor 1-wire in gebruik is. Geluk is met de dommen zullen we maar zeggen
Ben erg benieuwd of iemand op dit forum ervaring heeft met een GMT020-02-7P 20TFTSPI display in combinatie met een ESP-32-WROOM-32D in ESPHOME.
Ik probeer het display aan de gang te krijgen in ESPHOME maar krijg alleen wat verstrooide pixels op een gedeelte van het scherm.
Development board:
- ESP32-WROOM-32D
- HW-395 v0.0.3 (36 pins)
Display:
- GMT020-02-7P
- 20TfTSPI
- Resolutie 240*320
- Driver ST7789
Momenteel ben ik aan het testen met de volgende config:
Ben benieuwd of er hier iemand is die het ding aan de gang heeft.
Ik probeer het display aan de gang te krijgen in ESPHOME maar krijg alleen wat verstrooide pixels op een gedeelte van het scherm.
Development board:
- ESP32-WROOM-32D
- HW-395 v0.0.3 (36 pins)
Display:
- GMT020-02-7P
- 20TfTSPI
- Resolutie 240*320
- Driver ST7789
Momenteel ben ik aan het testen met de volgende config:
code:
Ik heb al diverse varianten (bijv. veranderen fysieke aansluiting VSPI SCK-18 en VSPI MOSI-23, rotation, height en width aanpassen) maar niets helpt.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| spi:
clk_pin: GPIO22
mosi_pin: GPIO21
display:
- platform: st7789v
model: CUSTOM
height: 240
width: 320
offset_height: 0
offset_width: 0
cs_pin: GPIO05
dc_pin: GPIO19
reset_pin: GPIO23
rotation: 90 |
Ben benieuwd of er hier iemand is die het ding aan de gang heeft.
Deze config ook eens geprobeerd. Nog niet aan de garage motor gehangen maar in mijn test hoor ik geen klik van het relay, dus sterk vermoeden dat ie nog steeds niks doet.Septillion schreef op dinsdag 3 maart 2026 @ 20:30:
@-Casper Ja, maar dat kan geen probleem zijn eigenlijk. Want als je inverted aan hebt is het enige dat aan = uit en uit = aan. Maar zou wel gewoon moeten werken. Of heb je dat nu ook?
Totaal zou ik dus doen:YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 esphome: name: garage friendly_name: Garage deur esp8266: board: d1_mini # Enable logging logger: # Enable Home Assistant API api: encryption: key: key: !secret api_key ota: - platform: esphome password: !secret ota_password switch: # Switch to restart the esp. - platform: restart name: Restart # Switch for the garage door. - platform: gpio id: relay name: None internal: true pin: number: D1 mode: OUTPUT button: - platform: template name: None icon: "mdi:garage-variant" on_press: - switch.turn_on: relay - delay: 150ms - switch.turn_off: relay wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Garage Fallback Hotspot" password: "PASS" captive_portal: # Sync time with Home Assistant. time: - platform: homeassistant id: homeassistant_time # Text sensors with general information. text_sensor: # Expose ESPHome version as sensor. - platform: version name: ESPHome Version # Expose WiFi information as sensors. - platform: wifi_info ip_address: name: IP ssid: name: SSID # Sensors with general information. sensor: # Uptime sensor. - platform: uptime name: Uptime # WiFi Signal sensor. - platform: wifi_signal name: WiFi Signal update_interval: 60s
Nog ideeën hoe ik dit verder kan troubleshooten?
Heb je ook de mipi_spi driver geprobeerd? Bij mij werkte deze met:fvhemert schreef op woensdag 4 maart 2026 @ 14:40:
Ben erg benieuwd of iemand op dit forum ervaring heeft met een GMT020-02-7P 20TFTSPI display in combinatie met een ESP-32-WROOM-32D in ESPHOME.
Ik probeer het display aan de gang te krijgen in ESPHOME maar krijg alleen wat verstrooide pixels op een gedeelte van het scherm.
Development board:
- ESP32-WROOM-32D
- HW-395 v0.0.3 (36 pins)
Display:
- GMT020-02-7P
- 20TfTSPI
- Resolutie 240*320
- Driver ST7789
.....
YAML:
Andere pinnen, dus even aanpassen naar je eigen config.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| spi: mosi_pin: 23 clk_pin: 18 display: - platform: mipi_spi id: my_display model: ST7789V color_order: bgr invert_colors: True rotation: 270 cs_pin: 5 dc_pin: 17 reset_pin: 16 spi_mode: MODE3 data_rate: 20MHz buffer_size: 50% update_interval: 100ms |
Ik heb uiteindelijk toch een ander display gezocht, deze heeft namelijk geen pin voor backlight en ik wil hem wel kunnen dimmen.
Ook ben ik overgestapt naar een esp32-s2 met psram. Ik heb redelijk veel pages op het display met hier en daar wat plaatjes, en sensoren waar ik een max van de afgelopen minuut in wil bijhouden, en dat resulteerde in garbage doordat er te weinig geheugen vrij was.
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
Leuk project, ziet er goed uit!
Ben alleen bang dat die regensensor het snel zal begeven in de buitenlucht. Die koperen printsporen zullen gaan oxideren (groen uitslaan) waardoor de sensor stopt met (betrouwbaar) werken verwacht ik.
Als je wil weten 'regent het?' kun je beter kijken naar een optische regensensor zoals gebruikt in auto's. Die kijkt naar de breking van het licht die verandert als er regendruppels op de ruit vallen. Zijn alleen wel aan de prijs zie ik.
[ Voor 12% gewijzigd door ThinkPad op 04-03-2026 16:14 ]
Het lijkt nu goed te gaan. Files gecleaned (alles) en daarna ging het goed. Moet wel wat geduld hebben, 980 seconden had ie nodig, en dat enkel voor een "naam" bij een sensorSeptillion schreef op woensdag 4 maart 2026 @ 13:00:
@tcw82 Ahj, okay. Door je reactie was ik een beetje aan het twijfelen of je het nu wel of niet al getest had.
@GJzon Eens hoor als je de keuze nog hebt. Maar zou er geen printen voor weg doen nu hij voor 1-wire in gebruik is. Geluk is met de dommen zullen we maar zeggen
Bedankt, jij hebt gelijk over die plaat, daarom heb ik de voeding geschakeld gemaakt. Ik had er een met Zigbee die ik zelf had gebouwd met een omgebouwde Aqara-magnetensor met 2 AAA-batterijtjes, ongeveer 4 jaar geleden denk ik. Die zag er nog goed uit.
Ik heb het nu zo gebouwd in mijn weerstation, zodat ik het kan vervangen wanneer het slijt.
Ik heb ook naar zo'n optische sensor gekeken uit de ESPHome-documentatie. Een Hydreon RG-9 Rain Sensor, originele kost meer dan mijn hele setup. Misschien ooit een clone proberen als ze iets goedkoper worden. Tot die tijd zal deze wel volhouden, denk ik.
Dank voor de suggestie! de mipi driver werkt inderdaad. Onderstaand de eerste simpele sketch die het gewenste resultaat geeft met deze display (voor het geval er iemand met een vergelijkbare vraag zit)u_nix_we_all schreef op woensdag 4 maart 2026 @ 15:45:
[...]
Heb je ook de mipi_spi driver geprobeerd? Bij mij werkte deze met:YAML:Andere pinnen, dus even aanpassen naar je eigen config.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 spi: mosi_pin: 23 clk_pin: 18 display: - platform: mipi_spi id: my_display model: ST7789V color_order: bgr invert_colors: True rotation: 270 cs_pin: 5 dc_pin: 17 reset_pin: 16 spi_mode: MODE3 data_rate: 20MHz buffer_size: 50% update_interval: 100ms
Ik heb uiteindelijk toch een ander display gezocht, deze heeft namelijk geen pin voor backlight en ik wil hem wel kunnen dimmen.
Ook ben ik overgestapt naar een esp32-s2 met psram. Ik heb redelijk veel pages op het display met hier en daar wat plaatjes, en sensoren waar ik een max van de afgelopen minuut in wil bijhouden, en dat resulteerde in garbage doordat er te weinig geheugen vrij was.
code:
De display zal onderdeel worden van een barcode scanner en het aantal pagina's zal heel beperkt zijn, psram is dus niet zo belangrijk in mijn specifieke geval. Dat van die backlight kwam ik ook achter toen de display uit de verpakking kwam, de verkoper op Aliexpress was hier niet helemaal duidelijk over. Er blijkt ook een versie te zijn met een extra pin voor de backlight, ik denk dat er nog wel een andere versie gaat komen ....1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| spi:
clk_pin: GPIO22
mosi_pin: GPIO21
lvgl:
widgets:
- label:
align: CENTER
text: 'Hello World!'
display:
- platform: mipi_spi
model: CUSTOM
init_sequence:
# - [ 0xD0, 0x07, 0x42, 0x18]
- delay 10ms
# - [ 0xD1, 0x00, 0x07, 0x10]
dimensions:
height: 240
width: 320
cs_pin: GPIO05
dc_pin: GPIO19
reset_pin: GPIO23
rotation: 90
auto_clear_enabled: false
update_interval: never |
Dank voor de snelle reactie!
Bleek een kwestie van slecht soldeerwerk. Nog eens met de soldeerbout de verbindingen nagelopen en daarna deed ie t. Dank voor de optimalisatie van de code en t meedenken!Septillion schreef op dinsdag 3 maart 2026 @ 20:30:
@-Casper Ja, maar dat kan geen probleem zijn eigenlijk. Want als je inverted aan hebt is het enige dat aan = uit en uit = aan. Maar zou wel gewoon moeten werken. Of heb je dat nu ook?
Totaal zou ik dus doen:YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 esphome: name: garage friendly_name: Garage deur esp8266: board: d1_mini # Enable logging logger: # Enable Home Assistant API api: encryption: key: key: !secret api_key ota: - platform: esphome password: !secret ota_password switch: # Switch to restart the esp. - platform: restart name: Restart # Switch for the garage door. - platform: gpio id: relay name: None internal: true pin: number: D1 mode: OUTPUT button: - platform: template name: None icon: "mdi:garage-variant" on_press: - switch.turn_on: relay - delay: 150ms - switch.turn_off: relay wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Garage Fallback Hotspot" password: "PASS" captive_portal: # Sync time with Home Assistant. time: - platform: homeassistant id: homeassistant_time # Text sensors with general information. text_sensor: # Expose ESPHome version as sensor. - platform: version name: ESPHome Version # Expose WiFi information as sensors. - platform: wifi_info ip_address: name: IP ssid: name: SSID # Sensors with general information. sensor: # Uptime sensor. - platform: uptime name: Uptime # WiFi Signal sensor. - platform: wifi_signal name: WiFi Signal update_interval: 60s
@-Casper Late reactie
Maar dat was eigenlijk wel het volgende wat ik wilde suggereerde. Eigenlijk wel 1e gebod van elektronica: Gij zal de spanningen meten
Ik ben bezig met een Lilygo T-can485 board om in ESPhome te installeren, maar het zit tegen.
Het prepare for first use via de web.esphome.io gaat goed, maar als het eenmaal is geïnstalleerd dan wil ik wifi toevoegen. Daar krijg ik de eerste error: Improv Wi-Fi Serial not detected. Als ik dan in de log device reset klik, dan kan ik wel een wifi toevoegen. Dan zie ik het device ook in HA. Als ik dan in HA adopt aanklik dan wordt er een install gestart, die duurt ongeveer 10 minuten. Als dat klaar is, kan ik nog steeds niks doen. Wifi lijkt het niet te doen op het boardje.
Ik heb de verbinding al een paar keer onderbroken via usb en opnieuw geïnstalleerd via esphome en dan prepare for first use. Maar dat helpt niks helaas.
Hoe kan ik lilygo weer helemaal resetten zodat er niks opstaat, ik denk dat er iets is fout gegaan omdat het LED ook niet meer aan wil, dat was bij de 1e connect wel zo. De verbinding naar de pc via usb doet het wel.
Het prepare for first use via de web.esphome.io gaat goed, maar als het eenmaal is geïnstalleerd dan wil ik wifi toevoegen. Daar krijg ik de eerste error: Improv Wi-Fi Serial not detected. Als ik dan in de log device reset klik, dan kan ik wel een wifi toevoegen. Dan zie ik het device ook in HA. Als ik dan in HA adopt aanklik dan wordt er een install gestart, die duurt ongeveer 10 minuten. Als dat klaar is, kan ik nog steeds niks doen. Wifi lijkt het niet te doen op het boardje.
Ik heb de verbinding al een paar keer onderbroken via usb en opnieuw geïnstalleerd via esphome en dan prepare for first use. Maar dat helpt niks helaas.
Hoe kan ik lilygo weer helemaal resetten zodat er niks opstaat, ik denk dat er iets is fout gegaan omdat het LED ook niet meer aan wil, dat was bij de 1e connect wel zo. De verbinding naar de pc via usb doet het wel.
Marstek Venus E 2.0 5,12 kWh v153 | 9x Jinko 435 WP met Enphase iQ8+ | HW P1 6.0304 | Quatt | Vvw | Tibber
Wifi signaal sterk genoeg ?User9 schreef op zaterdag 14 maart 2026 @ 12:25:
Ik ben bezig met een Lilygo T-can485 board om in ESPhome te installeren, maar het zit tegen.
Het prepare for first use via de web.esphome.io gaat goed, maar als het eenmaal is geïnstalleerd dan wil ik wifi toevoegen. Daar krijg ik de eerste error: Improv Wi-Fi Serial not detected. Als ik dan in de log device reset klik, dan kan ik wel een wifi toevoegen. Dan zie ik het device ook in HA. Als ik dan in HA adopt aanklik dan wordt er een install gestart, die duurt ongeveer 10 minuten. Als dat klaar is, kan ik nog steeds niks doen. Wifi lijkt het niet te doen op het boardje.
Ik heb de verbinding al een paar keer onderbroken via usb en opnieuw geïnstalleerd via esphome en dan prepare for first use. Maar dat helpt niks helaas.
Hoe kan ik lilygo weer helemaal resetten zodat er niks opstaat, ik denk dat er iets is fout gegaan omdat het LED ook niet meer aan wil, dat was bij de 1e connect wel zo. De verbinding naar de pc via usb doet het wel.
@User9 Flashen ervan is eigenlijk hele reset. Alleen wat Wifi credentials blijven staan.
Via de web flasher lukt wifi mij eigenlijk ook nooit. Doe ik dan via de hotspot die hij aanmaakt.
En voeg je hem daarna toe aan HA of aan ESPHome builder? Ik zou dus alleen laatste doen.
Of als alternatief, zelf als device in ESPHome maken, wat instellen zoals naam en dan manual download. Device flashen via web flasher en daarna naar het AP gaan. En dan ipv de wifi in te stellen kan je dan volgens mij ook een firmware upload doen.
Via de web flasher lukt wifi mij eigenlijk ook nooit. Doe ik dan via de hotspot die hij aanmaakt.
En voeg je hem daarna toe aan HA of aan ESPHome builder? Ik zou dus alleen laatste doen.
Of als alternatief, zelf als device in ESPHome maken, wat instellen zoals naam en dan manual download. Device flashen via web flasher en daarna naar het AP gaan. En dan ipv de wifi in te stellen kan je dan volgens mij ook een firmware upload doen.
Ja sterk genoeg. Hij vindt het ook als ik in de log kijk.
Nu zag ik wel dat het wachtwoord in de secrets.yaml verkeerd was, deze heb ik nu goed gezet en het boardje opnieuw geïnstalleerd, maar werkt ook niet. Ook zonder wifi credentials in de secrets.yaml werk het niet.
Dan wil die wel op magische wijze via dezelfde wifi verbinding maken.
In HA vindt die hetzelf, tenminste in ESPhome in HA. Soms staat die dan als connected en soms ook niet. Dus het is allemaal wel raar volgens mij. Wifi blijft een error geven ook met de juiste credentials in de secrets.yaml.Septillion schreef op zaterdag 14 maart 2026 @ 14:25:
@User9 Flashen ervan is eigenlijk hele reset. Alleen wat Wifi credentials blijven staan.
Via de web flasher lukt wifi mij eigenlijk ook nooit. Doe ik dan via de hotspot die hij aanmaakt.
En voeg je hem daarna toe aan HA of aan ESPHome builder? Ik zou dus alleen laatste doen.
Of als alternatief, zelf als device in ESPHome maken, wat instellen zoals naam en dan manual download. Device flashen via web flasher en daarna naar het AP gaan. En dan ipv de wifi in te stellen kan je dan volgens mij ook een firmware upload doen.
Kan ik ook manual iets van github toevoegen via ESPhome als die eenmaal geconnect is? En wat moet ik dan precies toevoegen uit github? Is dat een bepaalde file? Ik kom ook niet verder met google over hoe het precies werkt.
[ Voor 7% gewijzigd door User9 op 14-03-2026 16:36 ]
Marstek Venus E 2.0 5,12 kWh v153 | 9x Jinko 435 WP met Enphase iQ8+ | HW P1 6.0304 | Quatt | Vvw | Tibber
Wat ik doe is eerst een first use installatie bij een nieuw device. Via HA -> ESPHome Builder -> +nieuw device. Daarna in de log kijken welk ip adres is toegekend.User9 schreef op zaterdag 14 maart 2026 @ 14:32:
[...]
Ja sterk genoeg. Hij vindt het ook als ik in de log kijk.
Nu zag ik wel dat het wachtwoord in de secrets.yaml verkeerd was, deze heb ik nu goed gezet en het boardje opnieuw geïnstalleerd, maar werkt ook niet. Ook zonder wifi credentials in de secrets.yaml werk het niet.
Dan wil die wel op magische wijze via dezelfde wifi verbinding maken.
[...]
In HA vindt die hetzelf, tenminste in ESPhome in HA. Soms staat die dan als connected en soms ook niet. Dus het is allemaal wel raar volgens mij. Wifi blijft een error geven ook met de juiste credentials in de secrets.yaml.
Kan ik ook manual iets van github toevoegen via ESPhome als die eenmaal geconnect is? En wat moet ik dan precies toevoegen uit github? Is dat een bepaalde file? Ik kom ook niet verder met google over hoe het precies werkt.
Dan in het uiteindelijke programma dit ip adres gebruiken, je wifi gegevens (SSID en password, ota:
- platform: esphome) etc. etc. invoeren en dan installeren via "instal -> plug into this computer. Wachten op de download, bewaren en dan met ESPHome Web aangesloten op een USB pport, dit bestand opzoeken en installeren.
Daarna kun je (althans ik) altijd met OTA verder. Nooit geen problemen.
Wordt gewoon gevonden in HA (d.w.z. ESPHome Builder). En anders middels 'apparaten en diensten -> ESPHome het device selecteren en toevoegen.
[ Voor 6% gewijzigd door GJzon op 15-03-2026 19:16 ]
Ik heb het werkend via deze tool: https://esphome.github.io/esp-web-tools/
Met alle andere dingen kreeg ik het niet voor elkaar. De wifi wou niet connecten en ik kreeg geen ip adres voor het device. Dus ik kon ook niet op visit klikken in ESPhome.
Via die webtool ging het in 1x goed, ook geen wifi errors meer.
Daarna in ESPhome een project voor de Marstek accu er op gezet en dat werkte ook.
Ook een vast ip adres gegeven in de editor anders ging ESPhome naar een .local adres en dat werkte ook niet.
Met alle andere dingen kreeg ik het niet voor elkaar. De wifi wou niet connecten en ik kreeg geen ip adres voor het device. Dus ik kon ook niet op visit klikken in ESPhome.
Via die webtool ging het in 1x goed, ook geen wifi errors meer.
Daarna in ESPhome een project voor de Marstek accu er op gezet en dat werkte ook.
Ook een vast ip adres gegeven in de editor anders ging ESPhome naar een .local adres en dat werkte ook niet.
Marstek Venus E 2.0 5,12 kWh v153 | 9x Jinko 435 WP met Enphase iQ8+ | HW P1 6.0304 | Quatt | Vvw | Tibber
Volgens mij is het dezelfde tool. Via HA kom je op : https://web.esphome.io/?dashboard_install of zo je wilt direct via https://web.esphome.io/User9 schreef op zondag 15 maart 2026 @ 18:51:
Ik heb het werkend via deze tool: https://esphome.github.io/esp-web-tools/
Met alle andere dingen kreeg ik het niet voor elkaar. De wifi wou niet connecten en ik kreeg geen ip adres voor het device. Dus ik kon ook niet op visit klikken in ESPhome.
Via die webtool ging het in 1x goed, ook geen wifi errors meer.
Daarna in ESPhome een project voor de Marstek accu er op gezet en dat werkte ook.
Ook een vast ip adres gegeven in de editor anders ging ESPhome naar een .local adres en dat werkte ook niet.
Er ligt een nieuwe versie/variant in de schappen bij de Action: de "3202087.1", een op BK7237 BK7238 ipv BK7231N gebaseerde plug met board opschrift T1-2S-NL. De pinout van de 7237 is identiek. Ik denk nog even na over een werkend template. Mocht iemand suggesties hebben of bovenstaande aanpassing behoeft dan houd ik me aanbevolen! De plug meld zich via Tuya ook met een nieuwe string: "LSC Power Plug EU incl. Power meter" ipv de gebruikelijke "LSC Smart Power Plug"Septillion schreef op dinsdag 19 maart 2024 @ 20:03:
@PerlinNoise Hierbij de yaml voor de LCS Smart Connect pluggen (3202087) maar dan bij de burenIk heb er een general device yaml van gemaakt die ik dan importeer in elk device.
Devices\LSC_3202087.yamlYAML:En dan in het device:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 esphome: name: ${device_name} friendly_name: ${friendly_name} bk72xx: board: generic-bk7231n-qfn32-tuya logger: baud_rate: 0 web_server: captive_portal: mdns: api: encryption: key: !secret api_key ota: password: !secret ota_password wifi: networks: - ssid: !secret wifi_ssid password: !secret wifi_password ap: button: - platform: restart name: Restart debug: update_interval: 30s text_sensor: - platform: debug reset_reason: name: Reset Reason - platform: libretiny version: name: LibreTiny Version sensor: - platform: uptime name: Uptime - platform: hlw8012 model: BL0937 update_interval: 500ms change_mode_every: 2 cf_pin: number: P26 inverted: true cf1_pin: number: P24 inverted: true sel_pin: number: P11 inverted: true current: name: Current id: current accuracy_decimals: 3 on_value: component.update: apparent_power filters: - multiply: ${current_multiply} - sliding_window_moving_average: window_size: 4 send_every: 2 voltage: name: Voltage id: voltage on_value: component.update: apparent_power filters: - sliding_window_moving_average: window_size: 4 send_every: 2 power: name: Power id: power on_value: component.update: power_factor filters: - sliding_window_moving_average: window_size: 4 send_every: 2 energy: name: Energy voltage_divider: ${voltage_divider} current_resistor: ${current_resistor} - platform: template name: "Apparent power" id: apparent_power unit_of_measurement: VA device_class: apparent_power lambda: |- return id(voltage).state * id(current).state; update_interval: never on_value: component.update: power_factor - platform: template name: "Power factor" id: power_factor unit_of_measurement: '' device_class: power_factor lambda: |- return id(power).state / id(apparent_power).state; filters: - clamp: min_value: 0 max_value: 1 update_interval: never binary_sensor: - platform: gpio id: binary_switch_1 pin: number: P7 inverted: true mode: INPUT_PULLUP filters: - delayed_on: 10ms on_press: then: - switch.toggle: switch_1 switch: - platform: gpio id: switch_1 name: none pin: P8 restore_mode: RESTORE_DEFAULT_OFF on_turn_on: script.execute: set_status_led on_turn_off: script.execute: set_status_led light: - platform: status_led id: light_red name: "Red led" pin: P6 restore_mode: RESTORE_DEFAULT_OFF - platform: binary name: "Status led" id: blue_led output: output_blue_led restore_mode: RESTORE_DEFAULT_OFF internal: true output: - platform: gpio id: output_blue_led pin: P10 select: - platform: template name: "Status led mode" id: status_led_mode optimistic: true restore_value: True entity_category: CONFIG update_interval: never options: - "Normal" - "Invert" - "Off" initial_option: "Normal" on_value: script.execute: set_status_led script: - id: set_status_led then: - if: condition: lambda: |- return strcmp(id(status_led_mode).state.c_str(), "Normal") == 0; then: if: condition: switch.is_on: switch_1 then: light.turn_on: blue_led else: light.turn_off: blue_led - if: condition: lambda: |- return strcmp(id(status_led_mode).state.c_str(), "Invert") == 0; then: if: condition: switch.is_on: switch_1 then: light.turn_off: blue_led else: light.turn_on: blue_led - if: condition: lambda: |- return strcmp(id(status_led_mode).state.c_str(), "Off") == 0; then: light.turn_off: blue_ledYAML:Waar je dan de naam en exacte kalibratie opgeeft.
1 2 3 4 5 6 7 8 9 substitutions: device_name: foo-bar friendly_name: Foo Bar voltage_divider: '795' current_resistor: '0.001' current_multiply: '0.450' packages: device_base: !include Devices/LSC_3202087.yaml
[ Voor 1% gewijzigd door DjB42 op 17-03-2026 13:09 . Reden: foutje in chipnummer ]
Gasloos A+ jaren 30 huis, HomeAssistant, Panasonic H 9KW, SolarEdge + 36 panelen, Hyundai Kona EV 48kW
@User9 Ik zou hem dus eerst toevoegen aan ESPHome Builder. En pas aan HA als je een specifieke firmware hebt. ESPHome Builder en HA draaien los van elkaar inclusief dus de detectie.
En wil je firmware maken via ESPHome Builder zal je wifi correct in je secrest.yaml moeten staan.
Volgens mij is @GJzon ook correct dat web.esphome.io gewoon een implementatie van ESP Web Tools is dus zou niet uit moeten maken.
En wil je firmware maken via ESPHome Builder zal je wifi correct in je secrest.yaml moeten staan.
Volgens mij is @GJzon ook correct dat web.esphome.io gewoon een implementatie van ESP Web Tools is dus zou niet uit moeten maken.
@DjB42 Oei, dat is jammer
De BK7237 zie ik namelijk niet in de support list van Libre Tiny staan.
Of heb jij hem al weten uit te lezen / programmeren?
Of heb jij hem al weten uit te lezen / programmeren?
Uitlezen was geen probleem, programmeren moet ik nog even proberen...Septillion schreef op maandag 16 maart 2026 @ 11:16:
@DjB42 Oei, dat is jammerDe BK7237 zie ik namelijk niet in de support list van Libre Tiny staan.
Of heb jij hem al weten uit te lezen / programmeren?
Gasloos A+ jaren 30 huis, HomeAssistant, Panasonic H 9KW, SolarEdge + 36 panelen, Hyundai Kona EV 48kW
Hier heb ik er in de loop van de tijd ook veel van in de lokale cloud binnengeharkt, en ze doen het nog allemaal. Maar toch, als ik nu nog een plug zou willen toevoegen dan ga ik voor matter, wel zo makkelijk. Of mis ik dan iets?DjB42 schreef op maandag 16 maart 2026 @ 10:11:
[...]
Er ligt een nieuwe versie/variant in de schappen bij de Action: de "3202087.1", een op BK7237 ipv BK7231N gebaseerde plug met board opschrift T1-2S-NL. De pinout van de 7237 is identiek. Ik denk nog even na over een werkend template. Mocht iemand suggesties hebben of bovenstaande aanpassing behoeft dan houd ik me aanbevolen! De plug meld zich via Tuya ook met een nieuwe string: "LSC Power Plug EU incl. Power meter" ipv de gebruikelijke "LSC Smart Power Plug"
@DjB42 Gewoon met ltchiptool uitgelezen? En die detecteert correct?
@marcel3 Mijn eerste Matter (over Wifi) uitstapje was ik nog niet gelijk heel enthousiast over. Was dan wel iets "complexer" dan een plug, namelijk een screen/rolluik module. Daar is de kalibratie weer niet generiek Matter en heb je dus als nog de app van de fabrikant nodig.
Maar daarnaast geeft het je op een plug als dit ook gewoon meer opties die de meeste fabrikanten je niet geven. Ontkoppelen van de knop, of altijd aan, of een auto off timer etc etc. Met ESPHome kan je dat erin bakken en iets als Tasmota ondersteund complexere zaken ook al. Eigenlijk alleen Shelly (en een beetje Sonoff) snapt die behoefte.
Maar daarnaast geeft het je op een plug als dit ook gewoon meer opties die de meeste fabrikanten je niet geven. Ontkoppelen van de knop, of altijd aan, of een auto off timer etc etc. Met ESPHome kan je dat erin bakken en iets als Tasmota ondersteund complexere zaken ook al. Eigenlijk alleen Shelly (en een beetje Sonoff) snapt die behoefte.
Ah ja dat zijn wel heel specifieke use cases, maar nu je het zegt: ik heb de led van een plug ook wel eens gebruikt als subtiele verklikker voor een geactiveerde alarminstallatie.Septillion schreef op maandag 16 maart 2026 @ 19:58:
@marcel3 Mijn eerste Matter (over Wifi) uitstapje was ik nog niet gelijk heel enthousiast over. Was dan wel iets "complexer" dan een plug, namelijk een screen/rolluik module. Daar is de kalibratie weer niet generiek Matter en heb je dus als nog de app van de fabrikant nodig.
Maar daarnaast geeft het je op een plug als dit ook gewoon meer opties die de meeste fabrikanten je niet geven. Ontkoppelen van de knop, of altijd aan, of een auto off timer etc etc. Met ESPHome kan je dat erin bakken en iets als Tasmota ondersteund complexere zaken ook al. Eigenlijk alleen Shelly (en een beetje Sonoff) snapt die behoefte.
Uitlezen met ltchiptool gaat goed, maar ik heb nog geen werkende image kunnen maken met esphome builder. Overigens werkt backup en flash met BK7231Easy wel en heb ik de plug nu wel werkend als OpenBK plug via MQTT.Septillion schreef op maandag 16 maart 2026 @ 19:54:
@DjB42 Gewoon met ltchiptool uitgelezen? En die detecteert correct?
Ik blijf nog even puzzelen op de ESPHome optie...
Gasloos A+ jaren 30 huis, HomeAssistant, Panasonic H 9KW, SolarEdge + 36 panelen, Hyundai Kona EV 48kW
@DjB42 Dus ltchiptool ziet hem werkelijk als BK7237?
En van OpenBK gebruik je dan gewoon de BK7231N binary?
En van OpenBK gebruik je dan gewoon de BK7231N binary?
LTchiptool ziet een 7238 (ik schreef eerder per abuis BK7237, maar dat klopt niet) en kan wel een read doen op de chip. Een write lukt ook, maar bij gebrek aan ondersteuning in LibreTiny gaat de stekker daarna in storing. Ik zag een Feature Request bij LT voor support van de 7238, maar die is ongoing. Link naar LibreTiny issue 342Septillion schreef op dinsdag 17 maart 2026 @ 07:30:
@DjB42 Dus ltchiptool ziet hem werkelijk als BK7237?
En van OpenBK gebruik je dan gewoon de BK7231N binary?
Flashen met OpenBk gaat prima, die heeft ook netjes ondersteuning voor de 7238 en de plug doet daarna prima mee. Alleen in HA hangen is wat omslachtiger dan met ESPHome, vond ik. Link naar BK7231GUIFlashTool waarmee het in 1x flashen werkt.
[ Voor 3% gewijzigd door DjB42 op 17-03-2026 13:10 . Reden: correctie chipnummer ]
Gasloos A+ jaren 30 huis, HomeAssistant, Panasonic H 9KW, SolarEdge + 36 panelen, Hyundai Kona EV 48kW
De laatste tijd heb ik steeds iets vreemds met mijn twee Home assistant Voice PE's.
Ik heb er een op de eerste etage staan (Hey Jarvis) en ik heb er een in de huiskamer staan (Okey Nabu).
Het vreemde is nu dat zowel bij het normaal praten in de huiskamer als ook de TV aanstaat de PE constant antwoorden aan het geven is.
Nooit last hiermee gehad maar het begint nu toch wel storend te worden.
Ik gebruik Home assistant CLOUD en OpenAI Conversation.
Ook heb ik geprobeert andere wake woorden te gebruiken, steeds beide verschillend,
De PE's verder uit het zicht zetten niets helpt, hij blijft maar kwekken.
Als iemand een oplossing weet, heel graag.
Ik heb er een op de eerste etage staan (Hey Jarvis) en ik heb er een in de huiskamer staan (Okey Nabu).
Het vreemde is nu dat zowel bij het normaal praten in de huiskamer als ook de TV aanstaat de PE constant antwoorden aan het geven is.
Nooit last hiermee gehad maar het begint nu toch wel storend te worden.
Ik gebruik Home assistant CLOUD en OpenAI Conversation.
Ook heb ik geprobeert andere wake woorden te gebruiken, steeds beide verschillend,
De PE's verder uit het zicht zetten niets helpt, hij blijft maar kwekken.
Als iemand een oplossing weet, heel graag.
@Gondelier Stock config of zelf config aangepast?
@SeptillionSeptillion schreef op dinsdag 31 maart 2026 @ 20:14:
@Gondelier Stock config of zelf config aangepast?
Nee, niets van dit alles.
Ik ga v.d. week die twee PE’s uit de ESPHome Builder halen en opnieuw flashen met de web flashen, dan krijg ik OTA updates waar regelmatig o.a. een update voor de wake word detection in zit. Zoals TheFes omschreef.
Ik begrijp nog steeds niet hoe het in de ESPHome Builder terecht is gekomen.
Ik hoop dat het probleem dan opgelost is.
Bedankt 🙏 voor je reactie
Kan dit ook met de M5NanoC6? Dan heb je zelfs geen behuizing meer nodig. ;-)Septillion schreef op maandag 13 april 2026 @ 13:34:
Omdat mijn schoonouders wat meer inzicht in hun verbruik willen daar ook maar even Home Assistant op de NAS gedrukt. Restte alleen nog een P1 lezer. Nu ESPhome support heeft voor om UART pins te inverteren is er geen externe inverter meer nodig. Wel bleek de interne pull up van de ESP te zwak.
Maar zie dan daar, de SuperSimpleP1™ESP-C3 SuperMini, 1k weerstand en een RJ12 (6P6C) kabeltje.
[Afbeelding]
[Afbeelding]
Kan je gewoon de SlimmeLezer ESPhome config voor gebruiken met als aanpassing:YAML:
1 2 3 4 5 6 uart: baud_rate: 115200 rx_pin: number: GPIO4 inverted: true rx_buffer_size: 1700
André Huisman (www.new-line.nl)
Nice, zo heb ik het een paar maanden geleden ook gemaakt! Zonder behuizing, identiek op deze wijze. Ik heb het kabeltje heel kort gemaakt waardoor deze achter een klepje in de P1-meter zit, zodat er niets te zien is.Septillion schreef op maandag 13 april 2026 @ 13:34:
Omdat mijn schoonouders wat meer inzicht in hun verbruik willen daar ook maar even Home Assistant op de NAS gedrukt. Restte alleen nog een P1 lezer. Nu ESPhome support heeft voor om UART pins te inverteren is er geen externe inverter meer nodig. Wel bleek de interne pull up van de ESP te zwak.
Maar zie dan daar, de SuperSimpleP1™ESP-C3 SuperMini, 1k weerstand en een RJ12 (6P6C) kabeltje.
[Afbeelding]
[Afbeelding]
Kan je gewoon de SlimmeLezer ESPhome config voor gebruiken met als aanpassing:YAML:
1 2 3 4 5 6 uart: baud_rate: 115200 rx_pin: number: GPIO4 inverted: true rx_buffer_size: 1700
Hier heeft iemand de Homewizard P1-meter geimplementeerd in ESP32, wellicht voor sommigen bruikbaar voor loadbalancing, batterijen etc.
☀️ 7920 Wp | 🔋 Zendure Solarflow 800+ |🌡️ Stiebel Eltron WPL 15 ACS, HM Trend | Home Assistant
Interessant, dat zou weer energieverbruik schelen op mijn server. (usb 2 uart zorgt voor een hogere C state)
Weet iemand of je de historie makkelijk mee kan nemen als je van een usb 2 uart converter naar een esp bordje gaat?
Weet iemand of je de historie makkelijk mee kan nemen als je van een usb 2 uart converter naar een esp bordje gaat?
Je moet dan de nieuwe sensoren exact dezelfde namen geven. Bij mij was het een heel gedoe maar wel gelukt. Helaas ben ik daarbij wel de energiekosten die HA bijhoudt kwijtgeraakt.spitsv schreef op maandag 13 april 2026 @ 18:37:
Interessant, dat zou weer energieverbruik schelen op mijn server. (usb 2 uart zorgt voor een hogere C state)
Weet iemand of je de historie makkelijk mee kan nemen als je van een usb 2 uart converter naar een esp bordje gaat?
☀️ 7920 Wp | 🔋 Zendure Solarflow 800+ |🌡️ Stiebel Eltron WPL 15 ACS, HM Trend | Home Assistant
@HuismAndré Ja, aantal aantal UART verschilt tussen de ESP32's maar doen allemaal verder hetzelfde en je hebt maar een enkele UART nodig 
@manusjevanalles Ah, ja, korter kabeltje was ook een idee geweest. Kan hem nu als nog wel achter het klepje vouwen denk ik
@manusjevanalles Ah, ja, korter kabeltje was ook een idee geweest. Kan hem nu als nog wel achter het klepje vouwen denk ik
edit:
verkeerde topic
verkeerde topic
[ Voor 99% gewijzigd door scoobs op 14-04-2026 11:38 ]
Heeft er iemand ervaring met het koppelen van een USB device aan een ESP32?
Ik heb een draadloze handheld barcode scanner die gebruikt maat van een USB dongle. De dongle wordt in een PC gezien als een HID Keyboard Device. Ik vraag mij af of er iemand is die ervaring heeft met het koppelen van een dergelijk device aan een ESP32 device in ESPHOME. Ben erg geïnteresseerd om te horen hoe fysieke koppeling in elkaar steekt en hoe de configuratie er uit ziet.
Mocht je een gewoon USB keyboard gekoppeld hebben dan ben ik ook geïnteresseerd.
Alvast bedankt voor het meedenken.
Ik heb een draadloze handheld barcode scanner die gebruikt maat van een USB dongle. De dongle wordt in een PC gezien als een HID Keyboard Device. Ik vraag mij af of er iemand is die ervaring heeft met het koppelen van een dergelijk device aan een ESP32 device in ESPHOME. Ben erg geïnteresseerd om te horen hoe fysieke koppeling in elkaar steekt en hoe de configuratie er uit ziet.
Mocht je een gewoon USB keyboard gekoppeld hebben dan ben ik ook geïnteresseerd.
Alvast bedankt voor het meedenken.
Die had ik nog niet gezien, het zijn Arduino libraries en ik weet niet of ik die ook in ESPHOME kan gebruiken maar ik ga er zeker eens naar kijken. Dank!Hermarcel schreef op woensdag 15 april 2026 @ 10:13:
Geen ervaring mee, maar kun je die dongle niet gewoon weglaten? Dus de scanner "native" op de ESP32 aansluiten?
Als je toch via USB wil gaan: ik vond dit via Google
Edit: Draadloos gemist...
@fvhemert
EspHome heeft ook een component voor een USB host interface. Geen idee of hid (oa keyboard) support aanwezig is.
EspHome heeft ook een component voor een USB host interface. Geen idee of hid (oa keyboard) support aanwezig is.
Omdat het compilen van de yaml-code op mijn HA Green erg traag gaat, heb ik toch maar Python en ESPhome op mijn desktop geïnstalleerd. Met de nodige tutorials ben ik al ergens geraakt, maar telkens als ik het commando esphome run op mijn bestand kitchen.yaml loslaat, krijg ik de melding
Ik heb alle methodes al geprobeerd (rechtstreeks naar het .tff-bestand, via gfonts, via een URL naar GitHub) maar ik krijg telkens de melding "not a valid font file". Het pad naar het bestand klopt alleszins en het lettertypebestand is niet beschadigd (ik kan het zonder problemen openen in de font viewer van Windows en gebruiken in Word).
Ik ben erg nieuw in deze materie en heb geen idee waar het fout loopt ... (Ik heb via de ESPHome builder in Home Assistant een gelijkaardige code met verwijzing naar lettertypebestanden in mijn esphome-map op HA zonder problemen werkend gekregen, maar het compilen duurt echt eeuwig ...)
code:
.1
| File C:\Users\(...)\AppData\Local\Programs\Python\Python314\Scripts\.esphome\fonts\arial.ttf is not a valid font file. |
Ik heb alle methodes al geprobeerd (rechtstreeks naar het .tff-bestand, via gfonts, via een URL naar GitHub) maar ik krijg telkens de melding "not a valid font file". Het pad naar het bestand klopt alleszins en het lettertypebestand is niet beschadigd (ik kan het zonder problemen openen in de font viewer van Windows en gebruiken in Word).
Ik ben erg nieuw in deze materie en heb geen idee waar het fout loopt ... (Ik heb via de ESPHome builder in Home Assistant een gelijkaardige code met verwijzing naar lettertypebestanden in mijn esphome-map op HA zonder problemen werkend gekregen, maar het compilen duurt echt eeuwig ...)
Die post was ik al tegengekomen, maar daar had ik weinig aan: als ik compile binnen de ESPHome builder-integratie in Home Assistant zelf heb ik net géén probleem. Ik las nu net wel dat er wat problemen zouden zijn met ESPHome, Pillow and de meest recente Pythonversie.
Ik ga vandaag even de online mogelijkheden tot compileren via GitHub bekijken ...
[ Voor 7% gewijzigd door Elpenoor op 18-04-2026 06:02 ]
Die nieuwe feature van ESPHome voor serial proxies (ESPHome docs / Home Assistant aankondiging) is wel interessant. Alleen is het dus geen ser2net (achtige) variant voor zover ik het lees. Puur iets over de native API.
Wat dan dus jammer is. Want dat maakt het lastiger voor bv Zigbee2mqtt en DSMR Reader om het te ondersteunen. Alhoewel DSMR Reader het potentieel wat makkelijker kan doordat die de Python library zo kunnen gebruiken. Z2M is niet in Python geschreven, dus dat gaat niet
Wat dan dus jammer is. Want dat maakt het lastiger voor bv Zigbee2mqtt en DSMR Reader om het te ondersteunen. Alhoewel DSMR Reader het potentieel wat makkelijker kan doordat die de Python library zo kunnen gebruiken. Z2M is niet in Python geschreven, dus dat gaat niet
Ik wil nog een project van mij delen. Ik heb wel meerdere projecten afgemaakt sinds het weerstationproject, een LED-matrix (8x32) ESPHome-klok gebouwd voor mijn zoons kamer, die klok, temperatuur en CO²-gehalte van zijn kamer laat zien en rood/wit flasht als er brandalarm is of blauw/wit flasht als er waterlekkage is (met tekst).
Ik heb ook een ESPHome-sirene gebouwd, omdat de Zigbee-versie niet betrouwbaar was. Gewoon een bestaande "domme" alarmflitser en sirene in een kastje gekocht en daarin een ESP32 ingebouwd.
Project dat ik wil delen is een ESPHome IR Blaster. Ik had een van MOES met Zigbee, maar dit was zo traag en reageerde soms raar als je te snel iets bediende, dus ik heb besloten om zelf een te bouwen. En wat voor een? Een hele krachtige!
Dit ding bedient 3 apparaten in onze woonkamer die ongeveer 12m (inclusief keuken), een IPTV-kast (Formulier Z8) ongeveer 7m verderop, een lamp boven de eettafel ongeveer 3m verderop, en een plafondventilator in de keuken die 6m verderop buiten het zicht van de IR-blaster zit, MOES kon de plafondventilator niet bereiken. Deze IR-blaster is zo krachtig dat het weerkaatsingen vanuit de muren en keukenkasten mogelijk maakt om de plafondventilator te bedienen. Het hangt op dezelfde plek waar de MOES IR Blaster hing.
Het is ook razendsnel vergelijken met MOES!
Ik heb een 3D-behuizing gedesignd en met ASA geprint. Ik heb het zo klein mogelijk gehouden, omdat ik geen joekel van een ding op de muur wil hangen.
Ik heb 3x IR-LED's van 3W 940nm gebruikt. Deze zijn behoorlijk sterk, dus daarbij heb ik een MOSFET moeten gebruiken om ze te schakelen. Ik heb de LED's voorzien van sterkoelribben. Die zijn best groot, maar dat was wat ik had liggen. Ik denk dat het zelfs zonder deze geen problemen veroorzaakt, maar als je het lang bedient, bijvoorbeeld voor de dimfunctie, is het wel handig om deze te koelen. Voor de LED's heb ik per LED een 5W-weerstand gebruikt. Let op, dit zijn grote weerstanden.
IR-receiver om codes van de afstandsbedieningen in te leren is een VS1838B
Ik heb ook een 3mm rode led gebruikt om transmissie te laten zien als het bediend wordt. Dit is niet nodig, het is mooi om te hebben. Het kan ook op dezelfde GPIO aangesloten worden waar 3W IR-LEDs aangestuurd worden, maar ik heb gekozen om een aparte GPIO te gebruiken.
Hier een lijst van onderdelen die ik heb gebruikt:
3x 3W 940nm IR LEDs
3x 5W 4.7 ohm metaaloxide film weerstanden
1x IR Ontvanger VS1838B
1x IRLZ44N Mosfet
3x 36x15mm alu koelers (nogmaals deze zijn best groot) je kan ook kleine vierkante koelers gebruiken.
1x 5V-voeding van minimaal 3A
Andere weerstanden en condensatoren zijn standaard
Zoals ik had gezegd, ik heb de behuizing zo klein mogelijk proberen houden. Hierdoor moest ik bij de buitenste koelers iets afhalen om het passen te maken. Behuizing is 114mm breed, 46mm diep en 76mm hoog. Buitenste LED's zijn 70 graden verdraaid.
Ik heb een smoked lexaanplaat van 3mm tot mijn spijt gebruikt. Dit is te dik om te buigen op een klein stukje lexaan, zelfs na verwarmen. De binnendiameter van de boog is 250mm en lexaan moet 110mm breed en 70mm hoog gezaagd worden voor het buigen.
Beste is om een 1mm lexaan te gebruiken als je makkelijk wil buigen.
Dit is de behuizing boven ondertrapkastdeur:
:strip_exif()/f/image/tF6ObINuzEkUY5yFCQKXrS54.png?f=user_large)
Hier de onderkant, links 3mm rode led, en rechts de IR-receiver:
:strip_exif()/f/image/uDHHzFyXpvtYk4guq9fuh3jH.png?f=user_large)
Hier is het schema dat ik heb getekend voor hier:
/f/image/weQ5LpY5l4h651eHHDAgEzsr.png?f=fotoalbum_large)
Gebruik wel wat dikkere draden tot de IR LED's dus min naar MOSFET en vanuit de MOSFET naar de IR LED's en plus zijde van de MOSFET. Hou het minimaal 0.75mm², de rest mag dunner.
Zoals eerder gezegd, Transmit LED is niet nodig, maar wel leuk om te hebben.
Hieronder de ESPHome Yaml, met twee voorbeelden, een met NEC-protocol en een met Pronto. Tijdens het receiven krijg je meerdere codes te zien; je moet even kijken wat er werkt voor jou. Bij mij was de IPTV en plafondventilator NEC en de eettafellamp Pronto. Je krijgt ze allemaal te zien in de logs van je ESPHome.
Ik zou de receiver wel uit taggen (#) na inleren van alle knoppen, anders spamt het constant als er een IR-afstandsbediening gebruikt wordt.
Wel hierop letten:
carrier_duty_percent: 33%
33% duty cycle gaf kortere en scherpere IR-pulsen, waardoor de IR-ontvangers het signaal beter konden herkennen. Bij 50% werd het signaal te “zwaar” en minder goed gedetecteerd door ontvangers.
50% is normaal gesproken de standaard.
Extra voordeel is dat de IR LEDs, MOSFET en weerstanden hierdoor ook minder warm worden.
Hier HA dashboard:
Ik heb ook een ESPHome-sirene gebouwd, omdat de Zigbee-versie niet betrouwbaar was. Gewoon een bestaande "domme" alarmflitser en sirene in een kastje gekocht en daarin een ESP32 ingebouwd.
Project dat ik wil delen is een ESPHome IR Blaster. Ik had een van MOES met Zigbee, maar dit was zo traag en reageerde soms raar als je te snel iets bediende, dus ik heb besloten om zelf een te bouwen. En wat voor een? Een hele krachtige!
Dit ding bedient 3 apparaten in onze woonkamer die ongeveer 12m (inclusief keuken), een IPTV-kast (Formulier Z8) ongeveer 7m verderop, een lamp boven de eettafel ongeveer 3m verderop, en een plafondventilator in de keuken die 6m verderop buiten het zicht van de IR-blaster zit, MOES kon de plafondventilator niet bereiken. Deze IR-blaster is zo krachtig dat het weerkaatsingen vanuit de muren en keukenkasten mogelijk maakt om de plafondventilator te bedienen. Het hangt op dezelfde plek waar de MOES IR Blaster hing.
Het is ook razendsnel vergelijken met MOES!
Ik heb een 3D-behuizing gedesignd en met ASA geprint. Ik heb het zo klein mogelijk gehouden, omdat ik geen joekel van een ding op de muur wil hangen.
Ik heb 3x IR-LED's van 3W 940nm gebruikt. Deze zijn behoorlijk sterk, dus daarbij heb ik een MOSFET moeten gebruiken om ze te schakelen. Ik heb de LED's voorzien van sterkoelribben. Die zijn best groot, maar dat was wat ik had liggen. Ik denk dat het zelfs zonder deze geen problemen veroorzaakt, maar als je het lang bedient, bijvoorbeeld voor de dimfunctie, is het wel handig om deze te koelen. Voor de LED's heb ik per LED een 5W-weerstand gebruikt. Let op, dit zijn grote weerstanden.
IR-receiver om codes van de afstandsbedieningen in te leren is een VS1838B
Ik heb ook een 3mm rode led gebruikt om transmissie te laten zien als het bediend wordt. Dit is niet nodig, het is mooi om te hebben. Het kan ook op dezelfde GPIO aangesloten worden waar 3W IR-LEDs aangestuurd worden, maar ik heb gekozen om een aparte GPIO te gebruiken.
Hier een lijst van onderdelen die ik heb gebruikt:
3x 3W 940nm IR LEDs
3x 5W 4.7 ohm metaaloxide film weerstanden
1x IR Ontvanger VS1838B
1x IRLZ44N Mosfet
3x 36x15mm alu koelers (nogmaals deze zijn best groot) je kan ook kleine vierkante koelers gebruiken.
1x 5V-voeding van minimaal 3A
Andere weerstanden en condensatoren zijn standaard
Zoals ik had gezegd, ik heb de behuizing zo klein mogelijk proberen houden. Hierdoor moest ik bij de buitenste koelers iets afhalen om het passen te maken. Behuizing is 114mm breed, 46mm diep en 76mm hoog. Buitenste LED's zijn 70 graden verdraaid.
Ik heb een smoked lexaanplaat van 3mm tot mijn spijt gebruikt. Dit is te dik om te buigen op een klein stukje lexaan, zelfs na verwarmen. De binnendiameter van de boog is 250mm en lexaan moet 110mm breed en 70mm hoog gezaagd worden voor het buigen.
Beste is om een 1mm lexaan te gebruiken als je makkelijk wil buigen.
Dit is de behuizing boven ondertrapkastdeur:
:strip_exif()/f/image/tF6ObINuzEkUY5yFCQKXrS54.png?f=user_large)
Hier de onderkant, links 3mm rode led, en rechts de IR-receiver:
:strip_exif()/f/image/uDHHzFyXpvtYk4guq9fuh3jH.png?f=user_large)
Hier is het schema dat ik heb getekend voor hier:
/f/image/weQ5LpY5l4h651eHHDAgEzsr.png?f=fotoalbum_large)
Gebruik wel wat dikkere draden tot de IR LED's dus min naar MOSFET en vanuit de MOSFET naar de IR LED's en plus zijde van de MOSFET. Hou het minimaal 0.75mm², de rest mag dunner.
Zoals eerder gezegd, Transmit LED is niet nodig, maar wel leuk om te hebben.
Hieronder de ESPHome Yaml, met twee voorbeelden, een met NEC-protocol en een met Pronto. Tijdens het receiven krijg je meerdere codes te zien; je moet even kijken wat er werkt voor jou. Bij mij was de IPTV en plafondventilator NEC en de eettafellamp Pronto. Je krijgt ze allemaal te zien in de logs van je ESPHome.
Ik zou de receiver wel uit taggen (#) na inleren van alle knoppen, anders spamt het constant als er een IR-afstandsbediening gebruikt wordt.
YAML:
Werking is simpel, richt je afstandbediening naar de IR-receiver, capture de codes via de logs of via VISIT vanuit de ESPHome-builder, en kijk welk protocol voor jou werkt.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
| esphome: name: esp-ir-blaster friendly_name: esp_ir_blaster esp32: board: esp32-c3-devkitm-1 framework: type: esp-idf logger: level: INFO baud_rate: 0 #baud_rate: 115200 api: encryption: key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ota: - platform: esphome password: "asdfghjklzxcvmbnqwertyuio" wifi: ssid: !secret wifi_ssid password: !secret wifi_password fast_connect: true power_save_mode: none reboot_timeout: 15min output_power: 8.5dB ap: ssid: "Esp-Ir-Blaster Fallback Hotspot" password: "XXXXXXXXXX" captive_portal: remote_transmitter: pin: number: GPIO4 carrier_duty_percent: 33% non_blocking: false remote_receiver: pin: number: GPIO5 inverted: true dump: all output: - platform: gpio pin: number: GPIO6 inverted: false id: status_led_output light: - platform: binary name: "Status LED" id: status_led output: status_led_output restore_mode: ALWAYS_OFF script: - id: tx_led_flash mode: restart then: - light.turn_on: status_led - delay: 150ms - light.turn_off: status_led button: # ---------- IPTV MENU ---------- - platform: template name: "IPTV MENU" on_press: - script.execute: tx_led_flash - remote_transmitter.transmit_nec: address: 0xFF00 command: 0xE51A # ---------- DIM UP SHORT ---------- - platform: template name: "Dim UP Short" on_press: - script.execute: tx_led_flash - remote_transmitter.transmit_pronto: data: "0000 006D 0022 0000 015B 00AF 0016 0017 0016 0017 0016 0017 0016 0016 0016 0017 0016 0017 0016 0017 0016 0042 0016 0042 0017 0042 0016 0042 0016 0042 0016 0042 0016 0042 0016 0042 0016 0017 0016 0017 0016 0042 0017 0016 0016 0017 0016 0042 0016 0017 0016 0017 0016 0017 0016 0042 0016 0017 0016 0042 0016 0042 0017 0016 0016 0042 0016 0042 0016 0042 0016 0181" - repeat: count: 20 then: - delay: 40ms - remote_transmitter.transmit_pronto: data: "0000 006D 0002 0000 015B 0056 0015 0181" # ---------- DIM UP LONG ---------- - platform: template name: "Dim UP Long" on_press: - script.execute: tx_led_flash - remote_transmitter.transmit_pronto: data: "0000 006D 0022 0000 015B 00AF 0016 0017 0016 0017 0016 0017 0016 0016 0016 0017 0016 0017 0016 0017 0016 0042 0016 0042 0017 0042 0016 0042 0016 0042 0016 0042 0016 0042 0016 0042 0016 0017 0016 0017 0016 0042 0017 0016 0016 0017 0016 0042 0016 0017 0016 0017 0016 0017 0016 0042 0016 0017 0016 0042 0016 0042 0017 0016 0016 0042 0016 0042 0016 0042 0016 0181" - repeat: count: 45 then: - delay: 40ms - remote_transmitter.transmit_pronto: data: "0000 006D 0002 0000 015B 0056 0015 0181" sensor: - platform: internal_temperature name: "ESP-IR Blaster Temperature" - platform: wifi_signal name: "ESP-IR Blaster WiFi Signaal" id: wifi_signal_db update_interval: 60s |
Wel hierop letten:
carrier_duty_percent: 33%
33% duty cycle gaf kortere en scherpere IR-pulsen, waardoor de IR-ontvangers het signaal beter konden herkennen. Bij 50% werd het signaal te “zwaar” en minder goed gedetecteerd door ontvangers.
50% is normaal gesproken de standaard.
Extra voordeel is dat de IR LEDs, MOSFET en weerstanden hierdoor ook minder warm worden.
Hier HA dashboard:
[ Voor 1% gewijzigd door Reptile-X op 16-05-2026 14:01 . Reden: Screenshot van HA dashboard toegevoegd. ]
@Reptile-X Netjes
Vooral ook die behuizing maakt het wel af. Scheelt dat je de leds niet veel aan hebt. Want met zo'n lage weerstand is kleine variatie in voedingsspanning of spanningsval al snel groot verschil in vermogen. Dus die 700mA ga je dan zo voorbij. En is je rode led niet ook echt mega fel?
En klein ding, niet je device naam herhalen in je component naam. Dus hier in je wifi en temp sensors
En zelf zet ik dus de API key en het AP password dus ook in mijn secrets.yaml, deelt lekker makkelijk.
En klein ding, niet je device naam herhalen in je component naam. Dus hier in je wifi en temp sensors
En zelf zet ik dus de API key en het AP password dus ook in mijn secrets.yaml, deelt lekker makkelijk.
@Septillion , bedankt
Rood led valt wel mee, maar is wel goed te zien inderdaad. Als het vervelend wordt, kan je het altijd uitlaten, ledje en de weerstand zijn toch een paar cent.
Ik gebruik zelf 6A-voeding, afgezekerd op 5A, hele schakeling gebruikt op zijn piek 2.4A
Devicenaam en componentnaam niet herhalen? Is dat een probleem of is het dan netter? Devicenaam heb ik met underscore. Ik heb ondertussen 13 ESPHome-devices, vandaar dat ik de sensoren een device-naam geef.
Rood led valt wel mee, maar is wel goed te zien inderdaad. Als het vervelend wordt, kan je het altijd uitlaten, ledje en de weerstand zijn toch een paar cent.
Ik gebruik zelf 6A-voeding, afgezekerd op 5A, hele schakeling gebruikt op zijn piek 2.4A
Devicenaam en componentnaam niet herhalen? Is dat een probleem of is het dan netter? Devicenaam heb ik met underscore. Ik heb ondertussen 13 ESPHome-devices, vandaar dat ik de sensoren een device-naam geef.
@Reptile-X Probleem is het niet, gaat niets stuk.
Maar al weer een tijdje gebruikt HA <Device name> <Component name> als entity naam. Dus heb je nu "esp_ir_blaster ESP-IR Blaster WiFi Signaal" wat aardig dubbelop is.
Zelf zou ik voor de (human) friendly name ook gaan voor "ESP IR blaster" ofzo ipv underscores in een leesbare naam. Maar dat hangt wel af van je naam schema in HA.
Maar al weer een tijdje gebruikt HA <Device name> <Component name> als entity naam. Dus heb je nu "esp_ir_blaster ESP-IR Blaster WiFi Signaal" wat aardig dubbelop is.
Zelf zou ik voor de (human) friendly name ook gaan voor "ESP IR blaster" ofzo ipv underscores in een leesbare naam. Maar dat hangt wel af van je naam schema in HA.
@Septillion Aha, daar heb je gelijk in inderdaad. Ik keek alleen naar de namen in de HA-entiteit, niet de entiteit zelf, en die underscore begon ik met het eerste device en ik heb het daarna zo gehouden.
De kachel heb ik zelf ontworpen op basis van een bewezenprincipe van https://batchrocket.eu/.edwin2021 schreef op dinsdag 19 mei 2026 @ 07:01:
[...]
Aha, ik kreeg de indruk dat het al werkte. Ik bedoelde info in de trant van welke bouwtekeningen gebruik je, hoe meet je de temperaturen enz. Gewoon belangstelling.
Daar heb ik een zelf ontworpen warmtewisselaar achter geplaatst.
Mocht je daar vragen over hebben:
Batchrocket "Shorty met warmtewisselaar voor SWW en CV
Het EPShome gedeelte was niet zo spannend, dat werkte vrijwel direct:
YAML:
De aansturing wat ik tot zover in de bovenstaande YAML heb geschreven lijkt te werken op het bureau.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
| esphome: name: "hout-cv" friendly_name: Hout CV kachel esp32: board: esp32dev framework: type: esp-idf # Enable logging logger: # Enable Home Assistant API api: encryption: xxxx key: xxxx ota: - platform: esphome password: xxxx wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: xxxx password: xxxx captive_portal: # ------------------------ # Water temperatuur sensoren # ------------------------ one_wire: - platform: gpio pin: GPIO4 spi: clk_pin: GPIO18 miso_pin: GPIO19 sensor: - platform: dallas_temp name: "CV Aanvoer" address: 0x1600000021e78928 id: cv_aanvoer update_interval: 5s - platform: dallas_temp name: "CV Retour" address: 0x5d00000020c9cc28 id: cv_retour update_interval: 5s - platform: dallas_temp name: "Wisselaar max. temperatuur" address: 0xce000000217ced28 id: max_temp_wisselaar update_interval: 5s - platform: dallas_temp name: "SWW Boven" address: 0x27000000232ee628 id: SWW_boven update_interval: 5s - platform: dallas_temp name: "SWW Onder" address: 0xe900000023506328 id: SWW_onder update_interval: 5s - platform: dallas_temp name: "CV Boven" address: 0xd300000022cb9328 id: CV_boven update_interval: 5s - platform: dallas_temp name: "CV Midden" address: 0x1600000021e78928 id: CV_midden update_interval: 5s - platform: dallas_temp name: "CV Onder" address: 0x5100000020ca8d28 id: CV_onder update_interval: 5s # ------------------------ # Flowmeter CV (puls input) # ------------------------ - platform: pulse_counter pin: number: GPIO27 mode: INPUT_PULLUP name: "Flowmeter" id: flow_pulses update_interval: 5s unit_of_measurement: "puls/min" - platform: template name: "Flow CV" id: flow_cv unit_of_measurement: "L/min" update_interval: 5s lambda: |- return id(flow_pulses).state / 476.0; # -------------------- # ΔT (temperatuur verschil CV) # -------------------- - platform: template name: "Delta_T CV" id: cv_delta_t unit_of_measurement: "°C" lambda: |- return id(cv_aanvoer).state - id(cv_retour).state; # -------------------- # VERMOGEN (kW) # -------------------- - platform: template name: "Vermogen WW" id: vermogen_kw unit_of_measurement: "kW" lambda: |- return 0.0698 * id(flow_cv).state * id(cv_delta_t).state; # ------------------------ # Rookgas temperaturen MAX6675 (SPI thermokoppel) # ------------------------ - platform: max6675 name: "Rookgas wisselaar in" id: rookgas_in cs_pin: GPIO5 update_interval: 5s - platform: max6675 name: "Rookgas wisselaar uit" id: rookgas_uit cs_pin: GPIO17 update_interval: 5s # ------------------------ # Display (I2C Oled scherm) # ------------------------ font: - file: "gfonts://Open Sans" id: font_small size: 12 image: - file: "Datasco.png" id: logo type: BINARY i2c: sda: GPIO22 scl: GPIO23 scan: true globals: - id: display_page type: int restore_value: no initial_value: '0' interval: - interval: 8s then: - lambda: |- id(display_page) = (id(display_page) + 1) % 3; display: - platform: ssd1306_i2c model: "SSD1306_128X64" address: 0x3C update_interval: 1s lambda: |- if (id(display_page) == 0) { it.printf(0, 0, id(font_small), "Flow CV: %.1f L/min", id(flow_cv).state); it.printf(0, 12, id(font_small), "delta_T CV: %.1f °C", id(cv_delta_t).state); it.printf(0, 24, id(font_small), "Vermogen: %.1f kW", id(vermogen_kw).state); } else if (id(display_page) == 1) { it.printf(0, 0, id(font_small), "Rookgas in: %.1f °C", id(rookgas_in).state); it.printf(0, 12, id(font_small), "Rookgas uit: %.1f °C", id(rookgas_uit).state); it.printf(0, 24, id(font_small), "CV aanvoer: %.1f °C", id(cv_aanvoer).state); it.printf(0, 36, id(font_small), "CV retour: %.1f °C", id(cv_retour).state); it.printf(0, 48, id(font_small), "Max. °C W.W.: %.1f °C", id(max_temp_wisselaar).state); } else { it.printf(0, 0, id(font_small), "SWW Boven: %.1f °C", id(SWW_boven).state); it.printf(0, 12, id(font_small), "SWW Onder: %.1f °C", id(SWW_onder).state); it.printf(0, 24, id(font_small), "CV Boven: %.1f °C", id(CV_boven).state); it.printf(0, 36, id(font_small), "CV Midden: %.1f °C", id(CV_midden).state); it.printf(0, 48, id(font_small), "CV Onder: %.1f °C", id(CV_onder).state); } |
Als ik de sensoren in warm water leg lopen de waardes netjes mee en ook de warmtevraag verwachting op basis van forecast lijkt mooi mee te lopen. Dit kan echter nog getweaked worden als de definitieve warmteverlies bekend is.
Later ga ik dit uitbreiden met een WP en 2 elektrische elementen.
Het idee is dat ik dan de keuze kan (laten) tussen de warmtepomp of hout stook afhankelijk van de beschikbaarheid van PV opbrengst.
I.c.m. een 3 fase ess systeem hoop ik hiermee 80% off-grid te kunnen draaien.
Weinig meer HA => schopje naar ESPHome topic
[ Voor 0% gewijzigd door Septillion op 19-05-2026 09:37 ]
Plannen voorbereiden: Renovatie Boerderij (>80% zelfvoorzienend) > Hout CV i.c.m. WP, 300L SWW, 1500L CV, WTW, 16kwp i.c.m. 48/64kwh (D)ESS, regenwater opslag
@Daan_96 Je wilt denk ik nog wat devices classes toevoegen om het gelijk mooi in HA te krijgen.
En gezien een template sensor op deze manier compleet onafhankelijk werkt van de bron kan het zijn dat je template nu net voor de bron update. Om dat te voorkomen geef ik een template altijd update_interval: never en dan bij de bronsensor on_value: component.update: <template id>. Daarmee updaten ze gegarandeerd tegelijk.
En gezien een template sensor op deze manier compleet onafhankelijk werkt van de bron kan het zijn dat je template nu net voor de bron update. Om dat te voorkomen geef ik een template altijd update_interval: never en dan bij de bronsensor on_value: component.update: <template id>. Daarmee updaten ze gegarandeerd tegelijk.
Hoe doe ik dat precies?
Ik ben echt een leek op dat gebied helaas.. maar wil het graag leren.
Net als de update? Hoe integreer ik dat precies, en wat doet het precies? Zonder het klakkeloos 1 op 1 over te nemen en niet de onderliggende werking te snappen. Dat heeft natuurlijk nog niet veel zin.
Ik ben echt een leek op dat gebied helaas.. maar wil het graag leren.
Net als de update? Hoe integreer ik dat precies, en wat doet het precies? Zonder het klakkeloos 1 op 1 over te nemen en niet de onderliggende werking te snappen. Dat heeft natuurlijk nog niet veel zin.
Plannen voorbereiden: Renovatie Boerderij (>80% zelfvoorzienend) > Hout CV i.c.m. WP, 300L SWW, 1500L CV, WTW, 16kwp i.c.m. 48/64kwh (D)ESS, regenwater opslag
@Daan_96 Klein voorbeeldje:
En door de on_value zal elke keer als de puls sensor een nieuwe waarde krijgt de template ook een update krijgen. Zo blijven ze 100% in sync.
YAML:
Door device class toe te voegen weet HA beter om wat voor sensor het gaat en kan het zelfs voor je omrekenen. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| - platform: pulse_counter pin: number: GPIO27 mode: INPUT_PULLUP name: "Flowmeter" id: flow_pulses update_interval: 5s unit_of_measurement: "puls/min" on_value: component.update: flow_cv - platform: template name: "Flow CV" id: flow_cv unit_of_measurement: "L/min" device_class: volume_flow_rate update_interval: never lambda: |- return id(flow_pulses).state / 476.0; |
En door de on_value zal elke keer als de puls sensor een nieuwe waarde krijgt de template ook een update krijgen. Zo blijven ze 100% in sync.
ahh kijk top daar heb ik wat aan.
Je raad dus aan altijd een device class mee te geven?
Bedankt! Ik ga van de week eens sleutelen om de hele yaml aan te passen.
Je raad dus aan altijd een device class mee te geven?
Bedankt! Ik ga van de week eens sleutelen om de hele yaml aan te passen.
Plannen voorbereiden: Renovatie Boerderij (>80% zelfvoorzienend) > Hout CV i.c.m. WP, 300L SWW, 1500L CV, WTW, 16kwp i.c.m. 48/64kwh (D)ESS, regenwater opslag
@Daan_96 Voor zaken waar een device class is zou ik het zeker toevoegen. Dan heeft HA gewoon meer info om een sensor correct mee te nemen.
Met behulp van Gemini weer een stukje verder gekomen.
Thanks voor de tip nogmaals!
Ik heb het nog weer iets meer uitgebreid, zou je er nog een keer overheen willen lezen ;D
Thanks voor de tip nogmaals!
Ik heb het nog weer iets meer uitgebreid, zou je er nog een keer overheen willen lezen ;D
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
| esphome: name: "hout-cv" friendly_name: Hout CV kachel esp32: board: esp32dev framework: type: esp-idf # Enable logging logger: # Enable Home Assistant API api: encryption: key: ota: - platform: esphome password: wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: password: captive_portal: # ------------------------ # Water temperatuur sensoren # ------------------------ one_wire: - platform: gpio pin: GPIO4 spi: clk_pin: GPIO18 miso_pin: GPIO19 sensor: - platform: dallas_temp name: "CV Aanvoer" address: 0x1600000021e78928 id: cv_aanvoer update_interval: 5s device_class: "temperature" state_class: "measurement" on_value: then: - component.update: cv_delta_t - platform: dallas_temp name: "CV Retour" address: 0x5d00000020c9cc28 id: cv_retour update_interval: 5s device_class: "temperature" state_class: "measurement" on_value: then: - component.update: cv_delta_t - platform: dallas_temp name: "Wisselaar max. temperatuur" address: 0xce000000217ced28 id: max_temp_wisselaar update_interval: 5s device_class: "temperature" state_class: "measurement" # Noodbeveiliging logica (Hysteresis 95/85 graden) on_value_range: - above: 95.0 then: - logger.log: "🚨 NOODGREEP: Wisselaar te heet! Bypass open!" - switch.turn_on: bypass_open - delay: 15s - switch.turn_off: bypass_open - below: 85.0 then: - logger.log: "Safe zone bereikt. Normale logica mag weer hervat worden." - if: condition: # Als de kachel nog steeds heter is dan 150 graden, moet de klep weer dicht sensor.in_range: id: rookgas_in above: 150.0 then: - switch.turn_on: bypass_dicht - delay: 15s - switch.turn_off: bypass_dicht - platform: dallas_temp name: "SWW Boven" address: 0x27000000232ee628 id: SWW_boven update_interval: 5s device_class: "temperature" state_class: "measurement" - platform: dallas_temp name: "SWW Onder" address: 0xe900000023506328 id: SWW_onder update_interval: 5s device_class: "temperature" state_class: "measurement" - platform: dallas_temp name: "CV Boven" address: 0xd300000022cb9328 id: CV_boven update_interval: 5s device_class: "temperature" state_class: "measurement" - platform: dallas_temp name: "CV Midden" address: 0x1600000021e78928 # Let op: dit adres is gelijk aan CV Aanvoer! id: CV_midden update_interval: 5s device_class: "temperature" state_class: "measurement" - platform: dallas_temp name: "CV Onder" address: 0x5100000020ca8d28 id: CV_onder update_interval: 5s device_class: "temperature" state_class: "measurement" # ------------------------ # Flowmeter CV (puls input) # ------------------------ - platform: pulse_counter pin: number: GPIO27 mode: INPUT_PULLUP name: "Flowmeter" id: flow_pulses update_interval: 5s unit_of_measurement: "puls/min" on_value: then: - component.update: flow_cv - platform: template name: "Flow CV" id: flow_cv unit_of_measurement: "L/min" update_interval: never lambda: |- return id(flow_pulses).state / 476.0; on_value: then: - component.update: vermogen_kw # -------------------- # ΔT (temperatuur verschil CV) # -------------------- - platform: template name: "Delta_T CV" id: cv_delta_t unit_of_measurement: "°C" update_interval: never lambda: |- return id(cv_aanvoer).state - id(cv_retour).state; on_value: then: - component.update: vermogen_kw # -------------------- # VERMOGEN (kW) # -------------------- - platform: template name: "Vermogen WW" id: vermogen_kw unit_of_measurement: "kW" device_class: "power" state_class: "measurement" update_interval: never lambda: |- return 0.0698 * id(flow_cv).state * id(cv_delta_t).state; # ------------------------ # Rookgas temperaturen MAX6675 (SPI thermokoppel) # ------------------------ - platform: max6675 name: "Rookgas wisselaar in" id: rookgas_in cs_pin: GPIO5 update_interval: 5s device_class: "temperature" state_class: "measurement" # Logica voor de stooksessie en klepbediening on_value_range: - above: 150.0 then: - binary_sensor.template.publish: id: stooksessie_actief state: ON - if: condition: # Alleen dichtsturen als de noodbeveiliging NIET actief is (onder 95 graden) sensor.in_range: id: max_temp_wisselaar below: 95.0 then: - switch.turn_on: bypass_dicht - delay: 15s - switch.turn_off: bypass_dicht - below: 150.0 then: - binary_sensor.template.publish: id: stooksessie_actief state: OFF - switch.turn_on: bypass_open - delay: 15s - switch.turn_off: bypass_open - platform: max6675 name: "Rookgas wisselaar uit" id: rookgas_uit cs_pin: GPIO17 update_interval: 5s device_class: "temperature" state_class: "measurement" # ------------------------ # Virtuele status sensoren # ------------------------ binary_sensor: - platform: template name: "Stooksessie Actief" id: stooksessie_actief device_class: running # ------------------------ # Bypass Klep Aansturing (2 Relais op GPIO25 en GPIO26) # ------------------------ switch: - platform: gpio pin: GPIO25 name: "Bypass Klep Openen" id: bypass_open interlock: [bypass_dicht] inverted: false - platform: gpio pin: GPIO26 name: "Bypass Klep Sluiten" id: bypass_dicht interlock: [bypass_open] inverted: false # ------------------------ # Display (I2C Oled scherm) # ------------------------ font: - file: "gfonts://Open Sans" id: font_small size: 12 image: - file: "Datasco.png" id: logo type: BINARY i2c: sda: GPIO22 scl: GPIO23 scan: true globals: - id: display_page type: int restore_value: no initial_value: '0' interval: - interval: 8s then: - lambda: |- id(display_page) = (id(display_page) + 1) % 3; display: - platform: ssd1306_i2c model: "SSD1306_128X64" address: 0x3C update_interval: 1s lambda: |- if (id(display_page) == 0) { it.printf(0, 0, id(font_small), "Flow CV: %.1f L/min", id(flow_cv).state); it.printf(0, 12, id(font_small), "delta_T CV: %.1f °C", id(cv_delta_t).state); it.printf(0, 24, id(font_small), "Vermogen: %.1f kW", id(vermogen_kw).state); // Regel 4: Stooksessie status tonen if (id(stooksessie_actief).state) { it.printf(0, 36, id(font_small), "Stoken: ACTIEF"); } else { it.printf(0, 36, id(font_small), "Stoken: Inactief"); } // Regel 5: Bypass status tonen (rekening houdend met de noodbeveiliging boven 95 graden) if (id(max_temp_wisselaar).state > 95.0) { it.printf(0, 48, id(font_small), "Bypass: OPEN (NOOD!)"); } else if (id(stooksessie_actief).state) { it.printf(0, 48, id(font_small), "Bypass: DICHT"); } else { it.printf(0, 48, id(font_small), "Bypass: OPEN"); } } else if (id(display_page) == 1) { it.printf(0, 0, id(font_small), "Rookgas in: %.1f °C", id(rookgas_in).state); it.printf(0, 12, id(font_small), "Rookgas uit: %.1f °C", id(rookgas_uit).state); it.printf(0, 24, id(font_small), "CV aanvoer: %.1f °C", id(cv_aanvoer).state); it.printf(0, 36, id(font_small), "CV retour: %.1f °C", id(cv_retour).state); it.printf(0, 48, id(font_small), "Max. °C W.W.: %.1f °C", id(max_temp_wisselaar).state); } else { it.printf(0, 0, id(font_small), "SWW Boven: %.1f °C", id(SWW_boven).state); it.printf(0, 12, id(font_small), "SWW Onder: %.1f °C", id(SWW_onder).state); it.printf(0, 24, id(font_small), "CV Boven: %.1f °C", id(CV_boven).state); it.printf(0, 36, id(font_small), "CV Midden: %.1f °C", id(CV_midden).state); it.printf(0, 48, id(font_small), "CV Onder: %.1f °C", id(CV_onder).state); } |
Plannen voorbereiden: Renovatie Boerderij (>80% zelfvoorzienend) > Hout CV i.c.m. WP, 300L SWW, 1500L CV, WTW, 16kwp i.c.m. 48/64kwh (D)ESS, regenwater opslag
@Daan_96 Voor de temperatuur sensoren enzo is het toevoegen van device en state class niet nodig. Gezien ESPHome daarvoor al echt weet wat het voor component is zal ESPHome daar bij default al iets invullen. Je kan het wel overrulen als de waarde toch wat anders is. Bijvoorbeeld als je het via een filter ofzo als transformt. Maar is dus vooral een ding bij een template sensor waarbij ESPHome dus geen idee heeft wat het voor ding is.
En voor de bypass zou ik denk ik gewoon een template switch maken en dan de huidige 2 als internal markeren.
En voor de bypass zou ik denk ik gewoon een template switch maken en dan de huidige 2 als internal markeren.
Heeft iemand ervaring met de recente update van ESPHOME waarbij LVGL naar versie 9.5 gaat?
Sinds deze update krijg ik het touch gedeelte van mijn display niet meer aan de gang, het lijkt een probleem met de combinatie rotation:90 en de transformation van de raw values van het touchscreen waarbij de display breedte en hoogte wordt verwisseld.
Ik heb een post gemaakt op het community forum ( https://community.home-assistant.io/t/touchscreen-transformation-issues-after-lvgl-update/1011183) en een issue aangemeld op GitHub maar ben erg benieuwd of er hier iemand is die dit is tegen gekomen (en een oplossing weet).
Omdat ik een cross post wil vermijden, hier geen uitgebreide beschrijving maar ik wil wel de gezamenlijke brainpower van dit forum benutten.
22/05/26 EDIT: Inmiddels een stuk wijzer geworden en is het probleem opgelost. De post op het ESPHOME community forum is bijgewerkt met de oplossing.
Sinds deze update krijg ik het touch gedeelte van mijn display niet meer aan de gang, het lijkt een probleem met de combinatie rotation:90 en de transformation van de raw values van het touchscreen waarbij de display breedte en hoogte wordt verwisseld.
Ik heb een post gemaakt op het community forum ( https://community.home-assistant.io/t/touchscreen-transformation-issues-after-lvgl-update/1011183) en een issue aangemeld op GitHub maar ben erg benieuwd of er hier iemand is die dit is tegen gekomen (en een oplossing weet).
Omdat ik een cross post wil vermijden, hier geen uitgebreide beschrijving maar ik wil wel de gezamenlijke brainpower van dit forum benutten.
22/05/26 EDIT: Inmiddels een stuk wijzer geworden en is het probleem opgelost. De post op het ESPHOME community forum is bijgewerkt met de oplossing.
[ Voor 8% gewijzigd door fvhemert op 22-05-2026 14:40 ]
Nice!
Tijdje terug op Ali een setje van 2 nRF52840 "Nice!Nano" / "ProMicro" / "Supermini" bordjes gekocht. Met dus een nRF52840 microcontroller i.p.v. een ESP. Deze microcontroller wordt sinds eind vorig jaar door ESPHome ondersteund, en sinds begin dit jaar is er Zigbee ondersteuning voor. Voordeel van deze bordjes is dat ze zuinig zouden zijn, en dan ook echt zuinig. Deep sleep 0,4uA, vs een ESP32-H2 (ook geen wifi) niet onder de 7uA komt. Waarbij het daadwerkelijke verbruik vaak nog meer in het voordeel van de nRF uitvalt (lees: de nRF is langer / "makkelijker" in de diepste slaapstanden).
Het geflasht krijgen koste me wel aardig wat moeite, waarbij ik ook geen idee heb wat ik gisteren anders gedaan heb dan de dagen ervoor
. Maar nu heb ik wel dit bordje met 2 reed contacts (deur sensoren dus) die ook mooi in Zigbee2mqtt verschijnt. Waarbij voor dat laatste niks nodig is (in de basis). zigbee: blok / regel opnemen in de YAML, flashen, pairing in Z2M activeren en hij koppelt en Z2M genereert automatisch een definitie.
Verbruik aan een USB metertje komt uit op... Nouja, "doet het niet"
. 0,000A en dus ook 0,000W. Waarbij er ook een tellertje v.w.b. duur is en ook die loopt niet.
Heb ook één ESP32-H2 supermini, waarmee ik hetzelfde heb gedaan (2 reed contacts met input pullup, via Zigbee aan Z2M). Verbruik? 0,02xA, continu.
Gek genoeg, een C3 (met dus wifi en onzuinig), met ander projectje (getest met 2 Dallas one wire temp sensors) geeft langere tijd 0,000A aan om dan eens een keer 0,07xA aan te geven. Die lijkt tussendoor dus automatisch iets te sleepen en/of mogelijk een capacitor die zich steeds oplaad en ontlaad waardoor die zo flippert? En ook bij deze dus dat het USB metertje de duur niet laat opnemen als die 0,000A / 0,000W meet.
Alle bordjes overigens van AliExpress, Tenstar shop. De C3 met ingebouwde antenne (er is een verbeterde met antenne connector en losse antenne). De nRF52840 is het zwarte bordje. Nu in mijn zoektocht kwam ik tegen dat het rode bordje beter zou zijn.
Next up wordt dan een batterij / packje zoeken (mogelijk zelfs gewoon een CR2032 knoopcel?). En dan permanent in elkaar rommelen en in de brievenbus plaatsen. Daar zit nu één Aqara contact sensor in, onder de klep. Maar ook een sensor op de deur zou mooi zijn. Nu moet ik nog handmatig op een knop drukken dat de post is in gehaald
Dat kan dan automatisch bij het openen van het deurtje.
En misschien nog kijken om twee lichte load cells erbij te doen. Onderin de brievenbus zit al een roosterje. Daar load cells onder en de post wegen zou wel grappig zijn. Kan de post ook "worden afgemeld" als "grote post" bovenaan de klep wordt uit gepakt
. En zouden de reed contacts natuurlijk niet meer nodig zijn, maar zal dan wel een zwaar negatieve invloed op batterijverbruik hebben. Wat ik begrepen heb zou de nRF in deze setup, met puur binaire sensors aan een "input pullup" automatisch on en uit deep sleep gaan. Als die regelmatig een HX711 moet monitoren gaat dat natuurlijk teniet. Maar die zou die natuurlijk alleen tijdelijk hoeven te checken tijdens/na gerommel met de klep/deur.
Edit:
Het idee met de H2 of een andere ESP32 en dan een DAC met speakertje er aan. Openen klep: "Papier, hier", sluiten klep / gewicht toegenomen: "dankjewel" laat ik dan maar varen
. Zal vast ook niet positief voor het energieverbruik zijn.
Tijdje terug op Ali een setje van 2 nRF52840 "Nice!Nano" / "ProMicro" / "Supermini" bordjes gekocht. Met dus een nRF52840 microcontroller i.p.v. een ESP. Deze microcontroller wordt sinds eind vorig jaar door ESPHome ondersteund, en sinds begin dit jaar is er Zigbee ondersteuning voor. Voordeel van deze bordjes is dat ze zuinig zouden zijn, en dan ook echt zuinig. Deep sleep 0,4uA, vs een ESP32-H2 (ook geen wifi) niet onder de 7uA komt. Waarbij het daadwerkelijke verbruik vaak nog meer in het voordeel van de nRF uitvalt (lees: de nRF is langer / "makkelijker" in de diepste slaapstanden).
Het geflasht krijgen koste me wel aardig wat moeite, waarbij ik ook geen idee heb wat ik gisteren anders gedaan heb dan de dagen ervoor
Verbruik aan een USB metertje komt uit op... Nouja, "doet het niet"
Heb ook één ESP32-H2 supermini, waarmee ik hetzelfde heb gedaan (2 reed contacts met input pullup, via Zigbee aan Z2M). Verbruik? 0,02xA, continu.
Gek genoeg, een C3 (met dus wifi en onzuinig), met ander projectje (getest met 2 Dallas one wire temp sensors) geeft langere tijd 0,000A aan om dan eens een keer 0,07xA aan te geven. Die lijkt tussendoor dus automatisch iets te sleepen en/of mogelijk een capacitor die zich steeds oplaad en ontlaad waardoor die zo flippert? En ook bij deze dus dat het USB metertje de duur niet laat opnemen als die 0,000A / 0,000W meet.
Alle bordjes overigens van AliExpress, Tenstar shop. De C3 met ingebouwde antenne (er is een verbeterde met antenne connector en losse antenne). De nRF52840 is het zwarte bordje. Nu in mijn zoektocht kwam ik tegen dat het rode bordje beter zou zijn.
Next up wordt dan een batterij / packje zoeken (mogelijk zelfs gewoon een CR2032 knoopcel?). En dan permanent in elkaar rommelen en in de brievenbus plaatsen. Daar zit nu één Aqara contact sensor in, onder de klep. Maar ook een sensor op de deur zou mooi zijn. Nu moet ik nog handmatig op een knop drukken dat de post is in gehaald
En misschien nog kijken om twee lichte load cells erbij te doen. Onderin de brievenbus zit al een roosterje. Daar load cells onder en de post wegen zou wel grappig zijn. Kan de post ook "worden afgemeld" als "grote post" bovenaan de klep wordt uit gepakt
Edit:
Het idee met de H2 of een andere ESP32 en dan een DAC met speakertje er aan. Openen klep: "Papier, hier", sluiten klep / gewicht toegenomen: "dankjewel" laat ik dan maar varen
[ Voor 3% gewijzigd door RobertMe op 05-06-2026 11:25 ]
Leuk project! Zou je jou yaml voor de nRF52840 kunnen delen? Ik heb er zojuist een paar besteld om daar ook eens mee te spelen.
Het idee is om de kattenbak te gaan monitoren zodat ik een melding kan krijgen zodra de bak een x aantal keer is bezocht.
Dat doe ik nu met een PIR sensor om te zien hoe vaak er een kat in de bak is geweest, en een contact sensor om te kijken of de lade is verwijderd om schoon te maken.
Lijkt me een leuk project om een custom sensor voor te maken, en wat voorbeeld yaml is altijd welkom
Het idee is om de kattenbak te gaan monitoren zodat ik een melding kan krijgen zodra de bak een x aantal keer is bezocht.
Dat doe ik nu met een PIR sensor om te zien hoe vaak er een kat in de bak is geweest, en een contact sensor om te kijken of de lade is verwijderd om schoon te maken.
Lijkt me een leuk project om een custom sensor voor te maken, en wat voorbeeld yaml is altijd welkom
Die is vrij simpel:XyRuS schreef op zaterdag 6 juni 2026 @ 23:32:
Leuk project! Zou je jou yaml voor de nRF52840 kunnen delen? Ik heb er zojuist een paar besteld om daar ook eens mee te spelen.
Het idee is om de kattenbak te gaan monitoren zodat ik een melding kan krijgen zodra de bak een x aantal keer is bezocht.
Dat doe ik nu met een PIR sensor om te zien hoe vaak er een kat in de bak is geweest, en een contact sensor om te kijken of de lade is verwijderd om schoon te maken.
Lijkt me een leuk project om een custom sensor voor te maken, en wat voorbeeld yaml is altijd welkom
YAML:
Om te kunnen flashen moet je vervolgens de RST pin 2x kort kortsluiten met ground (ik heb gewoon een female => male dupont kabel op de RST gezet en tik vervolgens twee keer snel achter elkaar ground aan). Dan verschijnt die als een USB aparaat waar je .uf2 files op kunt droppen (die meteen worden toegepast). Ik heb er ook de nieuwste bootloader op gezet, afkomstig van hier: https://github.com/adafru...oader/releases/tag/0.11.0 (opletten dat je de juiste file pakt! Anders brick je hem? In dit geval dus de update-nice_nano_bootloader-0.11.0_nosd.uf2 als nieuwste (dus de nice_nano variant, en dan de .uf2)).1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| esphome: name: letterbox friendly_name: Letterbox nrf52: board: adafruit_feather_nrf52840 bootloader: adafruit_nrf52_sd140_v6 binary_sensor: - platform: gpio pin: number: P0.29 mode: INPUT_PULLUP name: Flap id: flap device_class: door - platform: gpio pin: number: P0.02 mode: INPUT_PULLUP name: Door id: door device_class: door zigbee: |
Flashen heb ik uiteindelijk aan de praat gekregen aan de PC (niet vanaf de ESPHome server / dashboard met flashen via de browser, alhoewel die dat wellicht intussen wel ook doet). Daarop draai ik al Linux en heb ik ESPHome als volgt middels Docker laten uploaden:
docker run --device /dev/ttyACM0:/dev/ttyACM0 -v ~/esp/esphome:/config --workdir /config esphome/esphome:2026.5 run letterbox.yaml
En nog twee "aantekeningen" bij de YAML. De sd140_v6 bij bootloader verwijst dus naar de gebruikte bootloader. Als je de "flash mode" actief hebt staat er op die "USB drive" ook een txt file, daarin staat de S???D??? versie, wat dus ook verwijst naar 140 / 1.4.0? en 6.x.y.
En de mode: INPUT_PULLUP kun je, blijkbaar, ook uitschrijven als (dat ik ook in nog wat voorbeelden tegen kwam. Ik heb gewoon een copy/paste gedaan van iets wat ik al had met reed contacts):
YAML:
Edit:1
2
3
| mode: input: true pullup: true |
Overigens heeft de device_class denk ik geen nut. In Z2M staat alleen het "Door" endpoint afgebeeld met een deur (en in HA lijken beiden geen device class te hebben). Mijn vermoeden is dat Z2M dit puur op basis van de naam doet. Waarbij de gebruikte name: tijdens het interview proces dus sowieso over de lijn gaat en ook in Z2M (en als gevol in HA) als dusdanig verschijnt. Maar device class lijkt dan geen Zigbee equivalent te hebben.
[ Voor 7% gewijzigd door RobertMe op 07-06-2026 10:01 ]
Bedankt voor je uitgebreide reactie, ook over hoe te flashen
Is inderdaad een vrij basic yaml, ik had gedacht dat er veel meer nodig zou zijn om het apparaat in slaap te brengen en te wekken zodra er een event zou plaats vinden. Heel eerlijk had ik nog niet zoveel eigen onderzoek gedaan, ik ga straks de documentatie eens doornemen
Hoe ik het begreep is het volledig automatisch, op basis van dan ook de GPIO op input pullup. Of in het OS of in de hardware, weet ik niet. In ieder geval is het extreem lage energieverbruik een van de redenen waarom deze microcontroller zo populair is. Als in: voldoende consumenten hardware waar deze nRF52 chips in zitten. Voor Bluetooth, Zigbee / Thread, ....XyRuS schreef op zondag 7 juni 2026 @ 12:00:
ik had gedacht dat er veel meer nodig zou zijn om het apparaat in slaap te brengen en te wekken zodra er een event zou plaats vinden
[ Voor 3% gewijzigd door RobertMe op 07-06-2026 12:08 ]
Weet iemand misschien hoe ik het “Pingeltje” terug kan krijgen op mijn VoicePE na een spraakopdracht. Ik gebruik 2 VoicePE’s op mijn home assistant HAOS en alles met de laatste updates.
edit:
Het is vanzelf opgelost.
Het is vanzelf opgelost.
[ Voor 43% gewijzigd door Gondelier op 15-06-2026 12:42 ]
Interessant! N.a.v. jouw berichten heb ik er wat op de nRF52840 ingelezen. Ik heb net een proefopstelling aan de praat op basis van ESPHome/ESP32-C3 supermini, om mijn jaloeziën gemotoriseerd te kantelen in HA. Althans: de steppermotor draait (eindelijk) na aansturing vanuit HA.RobertMe schreef op vrijdag 5 juni 2026 @ 11:21:
Tijdje terug op Ali een setje van 2 nRF52840 "Nice!Nano" / "ProMicro" / "Supermini" bordjes gekocht. Met dus een nRF52840 microcontroller i.p.v. een ESP.
De stroomtoevoer naar de jaloezie wordt een uitdaging dus de energiezuinigheid (batterij?) van de nRF52840 zou een voordeel zijn. Maar na jouw verhaal over het flashen laat ik voorlopig toch maar een draadje langs het kozijn lopen
Ben benieuwd naar je bevindingen met dat bordje!
Om dan nog maar eens terug te komen op mijn nRF52840 verhaal (gezien de +1s die ik vandaag nog gekregen heb
).
Heb er niet heel veel meer aan gedaan. Maar wat korte dingen:
Heb er niet heel veel meer aan gedaan. Maar wat korte dingen:
- Het runnen / uploaden is/was denk ik een beetje quirky doordat de builds laaaang duren (al dan niet door ophalen dependencies en dergelijke). En ik heb het idee dat die in flash mode na een bepaalde periode reboot. En in ieder geval met de "af fabriek" firmware verscheen er geen USB interface, daardoor moet ik hem in flash mode gooien zodat ik de docker run --device ... kan doen (omdat anders het device niet bestaat). Maar tegen de tijd dat de build dan klaar is was die "uit flash mode"(?). Opnieuw in flash mode zetten en opnieuw esphome run doen werkt dan meestal well, of esphome upload om de al gebuilde binary te uploaden. Waarbij ik mogelijk in eerste instantie bij elke esphome run faal weer aanpassingen in de YAML heb gedaan en die dus weer lang over een build deed wat dan weer mislukte bij het uploaden.
- Debuggen "kan gewoon". Met de logger config in de YAML krijg je gewoon logs te zien na een esphome run (of esphome logs dan). Ik had eerder het idee dat daar extra hardware voor nodig zou zijn. Met de logger enabled heb ik ook het idee dat daarmee er altijd een USB apparaat / serial interface wordt aangemaakt. Alhoewel ik niet zeker weet of die ook kan flashen over die modus. Meen dat die wel met een kinda "magic packet" de flash mode wil activeren. Maar IIRC kreeg ik ook nog errors bij run/upload.
- 1-wire werkt niet, geeft een compile error: https://github.com/esphome/esphome/issues/16163 Functies die niet geimplementeered zijn.
- Ik heb de hx711 load cell amplifier geprobeerd. Maar "die doet het niet". Met logging enabled logt die dat er geen data binnen komt. Aangesloten op een ESP32 C3 doet dezelfde YAML het wel. Ook als ik de hx711 op de 3.3V pin aansluit (docs van bordjes geven aan "5V", de nRF52840 heeft alleen 3.3V. Maar op de C3 lijkt die het prima te doen aan de 3.3V poort). Lijkt mij ook een ("dikke") bug in het nrf52 platform waardoor GPIO niet (goed) werkt.
Misschien dat iemand mij hier de goeie richting op kan wijzen. Sinds een paar dagen lees ik mijn Growatt omvormer uit met een Lilygo ESP32 met ESPHome erop (in plaats van de gammele Chinese cloud
)
Wat ik merk is dat elke avond, als de omvormer precies uitschakelt, de waarde van huidig vermogen enorm spiked:
Nu zijn die sensoren blijkbaar U32 registers (twee sequentiele 16-bit modbus registers):
). Iemand een idee hoe ik dit kan aanvliegen?
Wat ik merk is dat elke avond, als de omvormer precies uitschakelt, de waarde van huidig vermogen enorm spiked:
Nu zijn die sensoren blijkbaar U32 registers (twee sequentiele 16-bit modbus registers):
YAML:
Mijn vermoeden is dat de ESP geen volledig antwoord meer terugkrijgt (de omvormer schakelt uit tijdens het uitlezen), maar ik weet nog niet zo goed hoe ik dit kan bevestigen (of voorkomen 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| sensor: - platform: modbus_controller modbus_controller_id: modbus_pv name: "Growatt AC Output Power" address: 35 # Pac H (start van 32-bit waarde) register_count: 2 register_type: "read" unit_of_measurement: W device_class: power state_class: measurement icon: mdi:power-plug value_type: U_DWORD accuracy_decimals: 1 filters: - multiply: 0.1 |
Hier stond een dode link.
Omdat het bericht potentieel niet compleet is, zou je dat als vereiste kunnen stellen. Het is misschien wel erg interessant om vast te stellen wat de exacte data is bij normaal gebruik. Als niet alles afgeleverd of acknowledged wordt, dan is de data niet juist. Je wilt dit mogelijk gaan loggen om zeker van je zaak te zijn.strandbal schreef op maandag 13 juli 2026 @ 08:44:
Misschien dat iemand mij hier de goeie richting op kan wijzen. Sinds een paar dagen lees ik mijn Growatt omvormer uit met een Lilygo ESP32 met ESPHome erop (in plaats van de gammele Chinese cloud)
Wat ik merk is dat elke avond, als de omvormer precies uitschakelt, de waarde van huidig vermogen enorm spiked:
[Afbeelding]
Nu zijn die sensoren blijkbaar U32 registers (twee sequentiele 16-bit modbus registers):YAML:Mijn vermoeden is dat de ESP geen volledig antwoord meer terugkrijgt (de omvormer schakelt uit tijdens het uitlezen), maar ik weet nog niet zo goed hoe ik dit kan bevestigen (of voorkomen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 sensor: - platform: modbus_controller modbus_controller_id: modbus_pv name: "Growatt AC Output Power" address: 35 # Pac H (start van 32-bit waarde) register_count: 2 register_type: "read" unit_of_measurement: W device_class: power state_class: measurement icon: mdi:power-plug value_type: U_DWORD accuracy_decimals: 1 filters: - multiply: 0.1). Iemand een idee hoe ik dit kan aanvliegen?
De concrete eerste stap is wel om de boel eerst te controleren en 100% te zijn dat het inderdaad komt door incomplete data. Meten is weten.
1995: 486 AM5x86-p75@160 512kb L2, 64MB, S3 Stealth 64 3000 4MB VLB, AWE64 Value, 8GB CFµDrive
1998: K6-III 400MHz, 384MB, Voodoo4 AGP, AWE64 Gold!, Adaptec AHA-29160+2x 72GB 10krpm SCSI
Ik ben nog aan het zoeken hoe ik de logs van de ESP realtime ergens kan opslaan, bijvoorbeeld met HA, tot dusver vind ik nog niet hoe ik dat kan doen. Alleen log levels per sensor etc. Ik duik daar nog even in. Ben met je eens dat je wil zien wat er precies gebeurt, nu is het mijn aanname :)
Hoe zou je kunnen vereisen dat de data compleet is (beide registers bevat)? Ik vind dat ook niet in de documentatie van sensor parameters oid.
Hoe zou je kunnen vereisen dat de data compleet is (beide registers bevat)? Ik vind dat ook niet in de documentatie van sensor parameters oid.
Hier stond een dode link.
@strandbal
Je zou ook een filter op de sensor kunnen zetten die waarden boven een max value negeert:
Je zou ook een filter op de sensor kunnen zetten die waarden boven een max value negeert:
code:
https://esphome.io/components/sensor/#clamp-filter
1
2
3
4
5
| # Example configuration entry
filters:
- clamp:
max_value: 7500 #afhankelijk van wat je panelen max geven
ignore_out_of_range: true |
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
Mijn configuratie voor ESPHome met mijn Growatt omvormer, ik had ook problemen met spikes en heb filters toegevoegd.strandbal schreef op maandag 13 juli 2026 @ 08:44:
Misschien dat iemand mij hier de goeie richting op kan wijzen. Sinds een paar dagen lees ik mijn Growatt omvormer uit met een Lilygo ESP32 met ESPHome erop (in plaats van de gammele Chinese cloud)
Wat ik merk is dat elke avond, als de omvormer precies uitschakelt, de waarde van huidig vermogen enorm spiked:
[Afbeelding]
Nu zijn die sensoren blijkbaar U32 registers (twee sequentiele 16-bit modbus registers):YAML:Mijn vermoeden is dat de ESP geen volledig antwoord meer terugkrijgt (de omvormer schakelt uit tijdens het uitlezen), maar ik weet nog niet zo goed hoe ik dit kan bevestigen (of voorkomen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 sensor: - platform: modbus_controller modbus_controller_id: modbus_pv name: "Growatt AC Output Power" address: 35 # Pac H (start van 32-bit waarde) register_count: 2 register_type: "read" unit_of_measurement: W device_class: power state_class: measurement icon: mdi:power-plug value_type: U_DWORD accuracy_decimals: 1 filters: - multiply: 0.1). Iemand een idee hoe ik dit kan aanvliegen?
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
| esphome: name: growatt friendly_name: "Growatt omvormer" substitutions: esp_name: Growattmodbus esp8266: board: d1_mini # Enable logging logger: # Enable Home Assistant API api: encryption: key: "**********" ota: platform: esphome password: "*********" wifi: ssid: !secret wifi_ssid password: !secret wifi_password min_auth_mode: WPA2 # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Growatt Fallback Hotspot" password: "**********" captive_portal: time: - platform: homeassistant id: homeassistant_time uart: - id: uart_0 baud_rate: 9600 tx_pin: D1 rx_pin: D2 # stop_bits: 1 modbus: uart_id: uart_0 modbus_controller: - id: modbus_gw4200 web_server: port: 80 sensor: - platform: wifi_signal name: "${esp_name} - ESP WiFi Signal" update_interval: 60s - platform: uptime name: "${esp_name} - ESP Uptime" icon: mdi:clock-outline update_interval: 60s # sensor returning the currently set limit read from the register for showing it in HA - platform: modbus_controller modbus_controller_id: modbus_gw4200 name: "Limit %" id: gw4200_limit_set register_type: holding address: 3 unit_of_measurement: "%" value_type: U_WORD - platform: growatt_solar update_interval: 3s protocol_version: RTU2 inverter_status: name: "${esp_name} - Status Code" id: inverter_status phase_a: voltage: name: "${esp_name} - AC Voltage" current: name: "${esp_name} - AC Current" active_power: name: "${esp_name} - AC Power" filters: - filter_out: NaN pv1: voltage: name: "${esp_name} - PV1 Voltage" current: name: "${esp_name} - PV1 Current" active_power: name: "${esp_name} - PV1 Power" pv2: voltage: name: "${esp_name} - PV2 Voltage" current: name: "${esp_name} - PV2 Current" active_power: name: "${esp_name} - PV2 Power" active_power: state_class: "measurement" name: "${esp_name} - Output Power" filters: - lambda: |- if (x <= 5500 && x >= 0) return x; else return 0; pv_active_power: name: "${esp_name} - Input Power" frequency: name: "${esp_name} - Grid Frequency" energy_production_day: name: "${esp_name} - Today Gen" id: todaygen filters: - lambda: |- if (x >= 0) return x; else return 0; total_energy_production: name: "${esp_name} - Total Gen" accuracy_decimals: 1 inverter_module_temp: name: "${esp_name} - Temperature" switch: - platform: restart name: "${esp_name} - ESP Restart" text_sensor: - platform: wifi_info ip_address: name: "${esp_name} IP Address" ssid: name: "${esp_name} Connected SSID" bssid: name: "${esp_name} Connected BSSID" mac_address: name: "${esp_name} Mac Wifi Address" - platform: version name: "${esp_name} - ESPHome Version" number: - platform: modbus_controller modbus_controller_id: modbus_gw4200 # # creating a number entity and it's corresponding slider in HA # and writes it to the register on change # name: GW4200 Limit id: gw4200_limit address: 3 register_type: holding value_type: U_WORD min_value: 10 max_value: 100 step: 1 |
Wellicht even aangeven wát je hebt toegevoegd? Want je dumpt nu een volledige YAML.DyArt schreef op maandag 13 juli 2026 @ 09:23:
[...]
Mijn configuratie voor ESPHome met mijn Growatt omvormer, ik had ook problemen met spikes en heb filters toegevoegd.YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 esphome: name: growatt friendly_name: "Growatt omvormer" substitutions: esp_name: Growattmodbus esp8266: board: d1_mini # Enable logging logger: # Enable Home Assistant API api: encryption: key: "**********" ota: platform: esphome password: "*********" wifi: ssid: !secret wifi_ssid password: !secret wifi_password min_auth_mode: WPA2 # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Growatt Fallback Hotspot" password: "**********" captive_portal: time: - platform: homeassistant id: homeassistant_time uart: - id: uart_0 baud_rate: 9600 tx_pin: D1 rx_pin: D2 # stop_bits: 1 modbus: uart_id: uart_0 modbus_controller: - id: modbus_gw4200 web_server: port: 80 sensor: - platform: wifi_signal name: "${esp_name} - ESP WiFi Signal" update_interval: 60s - platform: uptime name: "${esp_name} - ESP Uptime" icon: mdi:clock-outline update_interval: 60s # sensor returning the currently set limit read from the register for showing it in HA - platform: modbus_controller modbus_controller_id: modbus_gw4200 name: "Limit %" id: gw4200_limit_set register_type: holding address: 3 unit_of_measurement: "%" value_type: U_WORD - platform: growatt_solar update_interval: 3s protocol_version: RTU2 inverter_status: name: "${esp_name} - Status Code" id: inverter_status phase_a: voltage: name: "${esp_name} - AC Voltage" current: name: "${esp_name} - AC Current" active_power: name: "${esp_name} - AC Power" filters: - filter_out: NaN pv1: voltage: name: "${esp_name} - PV1 Voltage" current: name: "${esp_name} - PV1 Current" active_power: name: "${esp_name} - PV1 Power" pv2: voltage: name: "${esp_name} - PV2 Voltage" current: name: "${esp_name} - PV2 Current" active_power: name: "${esp_name} - PV2 Power" active_power: state_class: "measurement" name: "${esp_name} - Output Power" filters: - lambda: |- if (x <= 5500 && x >= 0) return x; else return 0; pv_active_power: name: "${esp_name} - Input Power" frequency: name: "${esp_name} - Grid Frequency" energy_production_day: name: "${esp_name} - Today Gen" id: todaygen filters: - lambda: |- if (x >= 0) return x; else return 0; total_energy_production: name: "${esp_name} - Total Gen" accuracy_decimals: 1 inverter_module_temp: name: "${esp_name} - Temperature" switch: - platform: restart name: "${esp_name} - ESP Restart" text_sensor: - platform: wifi_info ip_address: name: "${esp_name} IP Address" ssid: name: "${esp_name} Connected SSID" bssid: name: "${esp_name} Connected BSSID" mac_address: name: "${esp_name} Mac Wifi Address" - platform: version name: "${esp_name} - ESPHome Version" number: - platform: modbus_controller modbus_controller_id: modbus_gw4200 # # creating a number entity and it's corresponding slider in HA # and writes it to the register on change # name: GW4200 Limit id: gw4200_limit address: 3 register_type: holding value_type: U_WORD min_value: 10 max_value: 100 step: 1
Wat me in ieder geval opvalt is dat je een aantal keren een lambda filter toepast die rucksichloss bij "foute" waardes 0 er van maakt. Dat is naar mijn idee sowieso fout. Foute waarden wil je negeren, niet iets anders willekeurigs van maken. De oplossing van @u_nix_we_all lijkt mij dan ook beter (puur de YAML lezende, ik kende de clamp filter nog niet, wel het concept clamping en de twee keys er onder zullen voor zich spreken incl dan "als out of range gebruik de oude, geldige, waarde i.p.v. de hoogst toegestane"
Dank voor jullie input! Geen idee waarom ik dit niet kon vinden, maargoed. Ik heb er nu een clamp filter op gezet die alles onder 0 en boven 3500 zou moeten negeren
Hier stond een dode link.
@strandbal De waarde die je ziet is heel specifiek. In Modbus is het nog wel eens gangbaar om 1 waarde te hebben die 'unknown' of 'ongeldig' aangeeft. Dus zou mij niets verbazen als dat hier dus 0x4DCCCCCD is. De HA modbus integratie kent hier de 'nan_value' parameter voor maar ESPhome lijkt dit niet ingebakken te hebben (dus moet je met een lambda aan de slag). Als je het alleen bij de power hebt en niet bij de energy dan is een range natuurlijk prima. Maar zou ik buiten de range 'NaN' gebruiken ipv 0. Dit komt dan mooi overeen met de correcte state in HA van 'unknown'.
@DyArt Gezien HA al weer een heel tijdje zelf de entities prefixed kan ik niet aanraden dat in je ESPhome ook te doen (${esp_name}). Gezien je dan dus iets hebt als "Growatt omvormer Growattmodbus - AC Voltage".
@DyArt Gezien HA al weer een heel tijdje zelf de entities prefixed kan ik niet aanraden dat in je ESPhome ook te doen (${esp_name}). Gezien je dan dus iets hebt als "Growatt omvormer Growattmodbus - AC Voltage".
@strandbal Kleine edit nog, de float komt natuurlijk pas na de multiply met 0.1. Je leest waarschijnlijk op dat moment dus gewoon 0xFFFFFFFF uit de modbus. Want dat is 4294967295, vermenigvuldigd met 0.1 geeft dat 429496729.5 maar dat kan niet weergegeven worden in een 32-bit float. Dichtstbijzijnde waarde die wel kan in 32-bit float is dus 429496736.0.
Je zou dus ook kunnen doen:
Je zou dus ook kunnen doen:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| sensor: - platform: modbus_controller modbus_controller_id: modbus_pv name: "Growatt AC Output Power" address: 35 # Pac H (start van 32-bit waarde) register_count: 2 register_type: "read" unit_of_measurement: W device_class: power state_class: measurement icon: mdi:power-plug value_type: U_DWORD accuracy_decimals: 1 filters: - lambda: |- if( x == 0xFFFFFFFF ) return NaN; return x; - multiply: 0.1 |
[ Voor 12% gewijzigd door Septillion op 13-07-2026 12:55 ]
Bedankt voor je reactie en tips, ik heb inderdaad deze YAML al een paar jaar draaien en werkt prima, maar neem wel jullie opmerkingen mee om het te verbeteren, ik zal de prefix eens weghalen en ook een clamp instellen ipv lambda's met 0 waarde. Wel even eerst uitzoeken dat mijn historie niet weg is na het verwijderen van de prefix.Septillion schreef op maandag 13 juli 2026 @ 12:41:
@strandbal De waarde die je ziet is heel specifiek. In Modbus is het nog wel eens gangbaar om 1 waarde te hebben die 'unknown' of 'ongeldig' aangeeft. Dus zou mij niets verbazen als dat hier dus 0x4DCCCCCD is. De HA modbus integratie kent hier de 'nan_value' parameter voor maar ESPhome lijkt dit niet ingebakken te hebben (dus moet je met een lambda aan de slag). Als je het alleen bij de power hebt en niet bij de energy dan is een range natuurlijk prima. Maar zou ik buiten de range 'NaN' gebruiken ipv 0. Dit komt dan mooi overeen met de correcte state in HA van 'unknown'.
@DyArt Gezien HA al weer een heel tijdje zelf de entities prefixed kan ik niet aanraden dat in je ESPhome ook te doen (${esp_name}). Gezien je dan dus iets hebt als "Growatt omvormer Growattmodbus - AC Voltage".
Dit klinkt zeer aannemelijk. Ik heb dit erin gezet, morgen eens kijken of 'ie zo is afgevangen :)Septillion schreef op maandag 13 juli 2026 @ 12:53:
@strandbal Kleine edit nog, de float komt natuurlijk pas na de multiply met 0.1. Je leest waarschijnlijk op dat moment dus gewoon 0xFFFFFFFF uit de modbus. Want dat is 4294967295, vermenigvuldigd met 0.1 geeft dat 429496729.5 maar dat kan niet weergegeven worden in een 32-bit float. Dichtstbijzijnde waarde die wel kan in 32-bit float is dus 429496736.0.
Je zou dus ook kunnen doen:YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 sensor: - platform: modbus_controller modbus_controller_id: modbus_pv name: "Growatt AC Output Power" address: 35 # Pac H (start van 32-bit waarde) register_count: 2 register_type: "read" unit_of_measurement: W device_class: power state_class: measurement icon: mdi:power-plug value_type: U_DWORD accuracy_decimals: 1 filters: - lambda: |- if( x == 0xFFFFFFFF ) return NaN; return x; - multiply: 0.1
NAN moest wel in hoofdletters overigens, daar kwam ik tijdens het compileren achter. Valideren werkte wel, maar validatie binnen esphome checkt de inhoud van de lambda dus niet
Hier stond een dode link.
@strandbal Ah, ja, correct. Eigenlijk beetje verwarrend dat ESPhome NaN verwacht in de yaml maar in C++ is de constante inderdaad NAN. En een lambda is puur C++, vandaar dat de ESPhome parser er niet naar kijkt en doorschuift naar de compiler.
Het werkt in ieder geval prima, ik heb het verschijnsel al twee dagen niet meer gezien
Dank!
Hier stond een dode link.
In de nieuwe release van ESPHome (2026.7.0) staat beschreven dat er een Flowmeter ondersteund wordt. Deze heb ik nog niet eerder gezien, het gaat om de UFM-01 Link.
Deze flowmeter ziet er veelbelovend uit, zijn er al mede Tweakers met ervaringen?
Deze flowmeter ziet er veelbelovend uit, zijn er al mede Tweakers met ervaringen?
Prijs gezien ergens?Stef012 schreef op vrijdag 17 juli 2026 @ 08:57:
In de nieuwe release van ESPHome (2026.7.0) staat beschreven dat er een Flowmeter ondersteund wordt. Deze heb ik nog niet eerder gezien, het gaat om de UFM-01 Link.
Deze flowmeter ziet er veelbelovend uit, zijn er al mede Tweakers met ervaringen?
Een CV-Ketel is een vlamkoeler en een radiator is een waterkoeler. :) Debiet is vermogen en niet de temperatuur.
Bij Digikey en Mouser is de prijs 50 - 60 euro
Dank. Ik had een serieus hogere prijs verwacht.Stef012 schreef op vrijdag 17 juli 2026 @ 10:19:
[...]
Bij Digikey en Mouser is de prijs 50 - 60 euro
Een CV-Ketel is een vlamkoeler en een radiator is een waterkoeler. :) Debiet is vermogen en niet de temperatuur.
Toevallig zat ik me deze week af te vragen of er iets bestond om te meten hoeveel water er effectief uit m'n beregeningspomp komtStef012 schreef op vrijdag 17 juli 2026 @ 08:57:
In de nieuwe release van ESPHome (2026.7.0) staat beschreven dat er een Flowmeter ondersteund wordt. Deze heb ik nog niet eerder gezien, het gaat om de UFM-01 Link.
Deze flowmeter ziet er veelbelovend uit, zijn er al mede Tweakers met ervaringen?
Showcase: Zehnder Comfoair E300 en Zehnder CO2 sensor uitlezen en aansturen.
Oude situatie:
Nu had ik wat tijd over en leek het mij leuk om eens te spelen met KiCAD, dus gebruik gemaakt om een simpel PCBtje te maken welke de verschillende componenten goed kan vasthouden:
/f/image/RZwCzPFIxEHKIxEoSIvhKDEA.png?f=fotoalbum_large)
De MAX3485 module via Aliexpress gekocht, de ESP32-C6 en de step down converter (12V => 5V) via Tinytronics aangeschaft.
Software configuratie:
Resultaat in Home Assistant:
/f/image/U9UrdzZECc80EOtjxqktrXmm.png?f=fotoalbum_large)
Ik ben een tevreden man
Mocht iemand anders ook interesse hebben: minimum bestelgrootte bij JLCPCB is 5 stuks, een buurman heeft ook al een printje, wil eentje houden voor hobby, dus heb er nog twee over
Oude situatie:
- Op de zolder hangt een Zehnder Comfoair E300 WTW welke de ventilatie van het huis verzorgd
- In de badkamer is een single push knop welke de WTW een halfuur op maximale snelheid laat draaien
- In de woonkamerkeuken hangt een CO2 sensor+controller welke op basis van CO2 op de begane grond de WTW aanstuurt
Nu had ik wat tijd over en leek het mij leuk om eens te spelen met KiCAD, dus gebruik gemaakt om een simpel PCBtje te maken welke de verschillende componenten goed kan vasthouden:
/f/image/RZwCzPFIxEHKIxEoSIvhKDEA.png?f=fotoalbum_large)
De MAX3485 module via Aliexpress gekocht, de ESP32-C6 en de step down converter (12V => 5V) via Tinytronics aangeschaft.
Software configuratie:
YAML:
Hardware installatie:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
| # VARIABLES ---------------------------- substitutions: device_id: "zehnder-e300" device_name: "Zehnder E300" tx_pin: GPIO2 rx_pin: GPIO1 update_interval: 15s # DEVICE DEFINITION -------------------- esphome: name: ${device_id} friendly_name: ${device_name} devices: - id: co2_sensor name: "CO2 sensor woonkamer" - id: controller name: "ventilatie controller" esp32: board: esp32-c6-devkitm-1 cpu_frequency: 80MHz framework: type: esp-idf # CORE SERVICES ------------------------ logger: level: INFO baud_rate: 0 api: encryption: key: !secret esphome_api_key ota: - platform: esphome password: !secret esphome_ota_pwd # NETWORKING --------------------------- wifi: ssid: !secret wifi_ssid password: !secret wifi_pwd fast_connect: true min_auth_mode: WPA2 ap: ssid: "${device_name} fallback" password: "12345678" captive_portal: # EXTERNAL INTEGRATIONS ---------------- packages: remote_package: url: https://github.com/CodedCactus/zehnder-comfoair ref: v2.2.0 files: [components/zehnder_fw2.yaml] refresh: 0s # GLOBALS ------------------------------ globals: - id: hrv_output_speed type: float initial_value: "0.0" restore_value: true # COMMUNICATION BUSES ------------------ modbus: flow_control_pin: GPIO3 # OUTPUT ------------------------------- output: - platform: ledc pin: GPIO20 id: fan_output # USER INPUT --------------------------- number: - platform: template id: hrv_min_speed name: "Minimum speed" device_id: controller min_value: 0 max_value: 100 step: 5 unit_of_measurement: "%" optimistic: true restore_value: true # INPUTS ------------------------------- sensor: - platform: template name: "Output speed" device_id: controller unit_of_measurement: "%" accuracy_decimals: 1 update_interval: ${update_interval} lambda: |- return id(hrv_output_speed) * 100.0f; # CO2 reading from connected Zehnder 0-10v CO2 sensor # Please see https://zehnder.picturepark.com/v/GScYd7oo/ # Ensure 'sensor mode', not 'controller mode' - platform: adc pin: GPIO0 name: "CO2" id: co2_ppm device_id: co2_sensor unit_of_measurement: "ppm" device_class: carbon_dioxide state_class: measurement accuracy_decimals: 0 attenuation: 12dB update_interval: ${update_interval} filters: - calibrate_linear: method: exact datapoints: - 0.64 -> 400 # 2V but 47k + 100k voltage divider - 3.2 -> 2000 # 10V but 47k + 100k voltage divider # some derivatives - platform: dew_point name: "Outdoor dew point" temperature: zehnder_outdoor_temp humidity: zehnder_outdoor_humidity - platform: dew_point name: "Supply dew point" temperature: zehnder_supply_temp humidity: zehnder_supply_humidity - platform: dew_point name: "Extract dew point" temperature: zehnder_extract_temp humidity: zehnder_extract_humidity - platform: dew_point name: "Exhaust dew point" temperature: zehnder_exhaust_temp humidity: zehnder_exhaust_humidity - platform: absolute_humidity name: "Outdoor absolute humidity" temperature: zehnder_outdoor_temp humidity: zehnder_outdoor_humidity - platform: absolute_humidity name: "Supply absolute humidity" temperature: zehnder_supply_temp humidity: zehnder_supply_humidity - platform: absolute_humidity name: "Extract absolute humidity" temperature: zehnder_extract_temp humidity: zehnder_extract_humidity - platform: absolute_humidity name: "Exhaust absolute humidity" temperature: zehnder_exhaust_temp humidity: zehnder_exhaust_humidity # CONTROL LOGIC ------------------------ interval: - interval: ${update_interval} then: - lambda: |- if (isnan(id(co2_ppm).state)) return; // 750ppm => minimum ventilation level // 1250ppm => maximum ventilation level const float target = std::clamp((id(co2_ppm).state - 750.0f) / 500.0f, 0.0f, 1.0f); const float delta = target - id(hrv_output_speed); const float alpha = delta > 0 ? 0.02 : 0.01; id(hrv_output_speed) += alpha * delta; const float min_speed = id(hrv_min_speed).state / 100.0f; id(hrv_output_speed) = max(id(hrv_output_speed), min_speed); id(fan_output).set_level(id(hrv_output_speed)); |
Resultaat in Home Assistant:
/f/image/U9UrdzZECc80EOtjxqktrXmm.png?f=fotoalbum_large)
Ik ben een tevreden man
Mocht iemand anders ook interesse hebben: minimum bestelgrootte bij JLCPCB is 5 stuks, een buurman heeft ook al een printje, wil eentje houden voor hobby, dus heb er nog twee over
Mooie oplossing! Ik heb zelf geen Zehnder co2 module, maar een losse co2 sensor die via de home assistent de ventilatie snelheid regelt.
Olla!
Onder het motto “omdat het kan” wilde ik mijn bestaande HomeWizard-watermeter vervangen door iets op basis van ESPHome. Daar zijn genoeg leuke projecten voor, en zelfs kant-en-klare meters. Tot ik me afvroeg: waar draait die HomeWizard eigenlijk op? Zou het toevallig…
HomeWizard-support wilde geen uitspraken doen over de hardware, dus wat doe je dan als Tweaker? Jawel, met gepast geweld de behuizing open slopen.
En hoezee: een ESP32-WROOM-32D 🥳
De USB-C bleek alleen voor de voeding aangesloten, dus geen UART. Gelukkig bleken een paar testpads gewoon TX, RX en GND te zijn. Dan komt natuurlijk de volgende vraag: is de bootloader beveiligd of zitten eFuses in de weg?
Joepie: neen 😬
Lang verhaal kort: na het nodige doormeten, wat draadjes solderen en wat gezonde dosis vibecoden draait er nu een eerste versie van ESPHome op de originele HomeWizard-hardware. Via de I2C-bus lees ik de Texas Instruments LDC1314 (inductor-to-digital converter) uit en gebruik de oscillatiewaarden om de passages van de watermetermagneet te detecteren. Inmiddels telt hij keurig de liters.
Kan ik er nu meer mee dan met de originele HomeWizard-software en de Local API?
Eigenlijk niet. Nog niet. Alles werkt, de twee drukknoppen kan ik uitlezen en de RGB led is netjes aan te sturen. En met een Home Assistant helper is de watermeter nu persistent (de ESP reset de liters nu naar nul bij een reboot, ik wilde niet constant naar flash schrijven). En ik ben van de HomeWizard software en cloud af (ja, ze hebben ook een local API).
Maar ik zei het al… Gewoon omdat het kan. 🥳😎
Nb: maak een backup als je het zelf gaat doen. En lees de eerste bootlog van de HomeWizard even, er zit cruciale info in die je gaandeweg in het projectje helpt qua LDC-initialisatie. Mocht iemand interesse hebben dan wil ik best alle Mitty gritty details en de YAML-met-lambdas delen.
Onder het motto “omdat het kan” wilde ik mijn bestaande HomeWizard-watermeter vervangen door iets op basis van ESPHome. Daar zijn genoeg leuke projecten voor, en zelfs kant-en-klare meters. Tot ik me afvroeg: waar draait die HomeWizard eigenlijk op? Zou het toevallig…
HomeWizard-support wilde geen uitspraken doen over de hardware, dus wat doe je dan als Tweaker? Jawel, met gepast geweld de behuizing open slopen.
En hoezee: een ESP32-WROOM-32D 🥳
De USB-C bleek alleen voor de voeding aangesloten, dus geen UART. Gelukkig bleken een paar testpads gewoon TX, RX en GND te zijn. Dan komt natuurlijk de volgende vraag: is de bootloader beveiligd of zitten eFuses in de weg?
Joepie: neen 😬
Lang verhaal kort: na het nodige doormeten, wat draadjes solderen en wat gezonde dosis vibecoden draait er nu een eerste versie van ESPHome op de originele HomeWizard-hardware. Via de I2C-bus lees ik de Texas Instruments LDC1314 (inductor-to-digital converter) uit en gebruik de oscillatiewaarden om de passages van de watermetermagneet te detecteren. Inmiddels telt hij keurig de liters.
Kan ik er nu meer mee dan met de originele HomeWizard-software en de Local API?
Eigenlijk niet. Nog niet. Alles werkt, de twee drukknoppen kan ik uitlezen en de RGB led is netjes aan te sturen. En met een Home Assistant helper is de watermeter nu persistent (de ESP reset de liters nu naar nul bij een reboot, ik wilde niet constant naar flash schrijven). En ik ben van de HomeWizard software en cloud af (ja, ze hebben ook een local API).
Maar ik zei het al… Gewoon omdat het kan. 🥳😎
Nb: maak een backup als je het zelf gaat doen. En lees de eerste bootlog van de HomeWizard even, er zit cruciale info in die je gaandeweg in het projectje helpt qua LDC-initialisatie. Mocht iemand interesse hebben dan wil ik best alle Mitty gritty details en de YAML-met-lambdas delen.
![]() | ![]() | ![]() |
![]() |
[ Voor 4% gewijzigd door Odie op 27-07-2026 15:31 ]
Heeft hier iemand nog een advies/workaround hoe ik de Tado X gemeten temperatuur in een ESP32 krijg met ESPHome. Ik krijg het gemakkelijk voor elkaar met HA maar ik zou graag HA willen vermijden.
Wat ik al heb is de Matterjs server onder docker draaiend (https://github.com/matter-js/matterjs-server) met daarin de Tado als commisioned node. Ik kan in deze matterjs server het endpoint localTemperature lezen: http://192.168.1.xxx:5580/#node/1/1/513.
Matterjs heeft een websocket connectie ws://192.168.1.xxx:5580/ws, deze kan ik met de Firefox Extensie ' Weasel websocket client' benaderen en uitlezen. Ik heb de gegevens dus lokaal toegankelijk maar weet niet hoe ik dat de ESP32 in krijg met ESPHome op hetzelfde netwerk
Met AI kom ik ook niet verder, heeft iemand een oplossing?
Wat ik al heb is de Matterjs server onder docker draaiend (https://github.com/matter-js/matterjs-server) met daarin de Tado als commisioned node. Ik kan in deze matterjs server het endpoint localTemperature lezen: http://192.168.1.xxx:5580/#node/1/1/513.
Matterjs heeft een websocket connectie ws://192.168.1.xxx:5580/ws, deze kan ik met de Firefox Extensie ' Weasel websocket client' benaderen en uitlezen. Ik heb de gegevens dus lokaal toegankelijk maar weet niet hoe ik dat de ESP32 in krijg met ESPHome op hetzelfde netwerk
Met AI kom ik ook niet verder, heeft iemand een oplossing?
[ Voor 3% gewijzigd door marnie op 27-07-2026 22:25 ]
2/1-kap 1988 | Extra vloer en muurisolatie | HR++ glas | WTW: Duco Energie Comfort 325 2-zones | WP: Adlar II 6kW | CV wonen: Jaga Strada Hybrid DBH, slapen: traditionele radiatoren | Solar: Enphase oost/west/zuid 4.2kVA | Homeassistant
@marnie Je kunt de http_request.get gebruiken. Vraag AI maar eens om "esphome http_request.get to get sensor data"
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
Danku_nix_we_all schreef op maandag 27 juli 2026 @ 23:58:
@marnie Je kunt de http_request.get gebruiken. Vraag AI maar eens om "esphome http_request.get to get sensor data"
2/1-kap 1988 | Extra vloer en muurisolatie | HR++ glas | WTW: Duco Energie Comfort 325 2-zones | WP: Adlar II 6kW | CV wonen: Jaga Strada Hybrid DBH, slapen: traditionele radiatoren | Solar: Enphase oost/west/zuid 4.2kVA | Homeassistant
Ik vroeg hier "laatst" (alweer bijna 3/4 jaar geleden zie ik) naar of ESPHome piepjes / tonen kan herkennen voor bv een afwasmachine die klaar is.RobertMe schreef op donderdag 4 december 2025 @ 10:27:
Is het mogelijk om met ESPHome piepjes te herkennen? Denk aan een afwasmachine die een piep patroon heeft als die klaar is. Volgens mij heb ik wel eens zo'n ESP projectjes gezien, maar ik denk "op maat" en niet met ESPHome.
Pluspunten als het met een gewone microfoon kan die tegelijkertijd ook voor voice gebruikt kan worden
Nou, nu kan het
Incl een web tool waar je audio in kunt uploaden en die vervolgens de YAML uitspuugt nadat je zelf "markeert" wat het patroon is.
Edit:
Overigens full disclosure, ik heb het (nog) niet gebruikt. Zag alleen de post op Reddit voorbij komen.
[ Voor 6% gewijzigd door RobertMe op 28-08-2026 11:50 ]
Let op:
Zet je code tussen [code=yaml] [/code] tags om het goed leesbaar te houden; ook makkelijker voor de eventuele foutopsporing.
Zet je code tussen [code=yaml] [/code] tags om het goed leesbaar te houden; ook makkelijker voor de eventuele foutopsporing.
:strip_exif()/f/image/uUKnGMvp3RPmQ2ufjwGPZ5zU.jpg?f=fotoalbum_tile)
:strip_exif()/f/image/d3UZjm2QKqPgsfNoqMJQHovw.jpg?f=fotoalbum_tile)
:strip_exif()/f/image/W6pkg5FBthSVuOXu6LMrb9SJ.jpg?f=fotoalbum_tile)
/f/image/QshKzAF1LL1ItJiwCxtBb6aV.png?f=fotoalbum_tile)