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.