Het grote ESPhome topic

[InjecTioN]

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:

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

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 ). Iemand een idee hoe ik dit kan aanvliegen?

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.

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.

[strandbal]

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.

[u_nix_we_all]

@strandbal
Je zou ook een filter op de sensor kunnen zetten die waarden boven een max value negeert:

code:

# Example configuration entry
filters:
  - clamp:
      max_value: 7500 #afhankelijk van wat je panelen max geven
      ignore_out_of_range: true

https://esphome.io/components/sensor/#clamp-filter

[DyArt]

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:

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

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 ). Iemand een idee hoe ik dit kan aanvliegen?

Mijn configuratie voor ESPHome met mijn Growatt omvormer, ik had ook problemen met spikes en heb filters toegevoegd.

YAML:

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

[RobertMe]

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:

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.

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"

[strandbal]

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

[Septillion]

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

[Septillion]

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

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 ]

[DyArt]

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

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.

[strandbal]

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:

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

Dit klinkt zeer aannemelijk. Ik heb dit erin gezet, morgen eens kijken of 'ie zo is afgevangen :)
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

[Septillion]

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

[strandbal]

Het werkt in ieder geval prima, ik heb het verschijnsel al twee dagen niet meer gezien Dank!

[Stef012]

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?

[Seafarer]

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?

Prijs gezien ergens?

[Stef012]

Seafarer schreef op vrijdag 17 juli 2026 @ 09:59:
[...]

Prijs gezien ergens?

Bij Digikey en Mouser is de prijs 50 - 60 euro

[Seafarer]

Stef012 schreef op vrijdag 17 juli 2026 @ 10:19:
[...]

Bij Digikey en Mouser is de prijs 50 - 60 euro

Dank. Ik had een serieus hogere prijs verwacht.

[DjoeC]

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?

Toevallig zat ik me deze week af te vragen of er iets bestond om te meten hoeveel water er effectief uit m'n beregeningspomp komt Eens wat verder induiken en zien of er GeKa koppelingen aan kunnen en of het maximaal volume (133 liter/minuut voor de UFM-02) voldoende is.

[eiPionezero]

Showcase: Zehnder Comfoair E300 en Zehnder CO2 sensor uitlezen en aansturen.

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 kwam ik dit mooie project van @remon. tegen: https://github.com/CodedCactus/zehnder-comfoair. Met deze ESPHome config kan via een RS485 de WTW worden uitgelezen. Door de analoge input op de WTW vanaf de CO2 sensor over te nemen kan de WTW ook nog eens custom worden aangestuurd, bvb door ook met een CO2 sensor op de slaapkamer te sturen.

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:


De MAX3485 module via Aliexpress gekocht, de ESP32-C6 en de step down converter (12V => 5V) via Tinytronics aangeschaft.

Software configuratie:

YAML:

# 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));

Hardware installatie:


Resultaat in Home Assistant:


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

[remon.]

Mooie oplossing! Ik heb zelf geen Zehnder co2 module, maar een losse co2 sensor die via de home assistent de ventilatie snelheid regelt.

[Odie]

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.

[ Voor 4% gewijzigd door Odie op 27-07-2026 15:31 ]

[marnie]

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?

[ Voor 3% gewijzigd door marnie op 27-07-2026 22:25 ]

[u_nix_we_all]

@marnie Je kunt de http_request.get gebruiken. Vraag AI maar eens om "esphome http_request.get to get sensor data"

[marnie]

u_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"

Dank , dat was even het duwtje die ik nodig had, ik heb verbinding en data. Het geheel staat in een test om te kijken of de temperatuur sensor in de ESP netjes wordt geupdate na wijziging.