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.

[RobertMe]

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

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.

Nou, nu kan het Er is iemand die er een custom component voor heeft ge-vibe-code: https://reddit.com/r/Esph...me_tone_tools_bring_dumb/
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 ]

[RobertMe]

RobertMe schreef op zondag 1 februari 2026 @ 22:21:
Ik zit nog steeds een beetje te rommelen om een muziek speler / smart speaker te maken, maar loop nogal (snel ) vast.

Met een ESP32 (oud ding dus, zonder toevoeging) krijg ik met Arduino framework audio uit mijn MAX98357A. Switch ik naar esp-idf errort die met een not supported achtige melding. Voeg ik psram: toe dan errort die met een no memory error en bij boot ook dat er helemaal geen psram is. Op een ESP32-S3 (devkit-c-1 N16R8) met 16MB flash en 8MB psram krijg ik noch met arduino noch met esp-idf audio er uit. Geen errors (als ik psram.mode: octal gebruik), maar ook geen geluid.
Mijn config is nu als volgt:

YAML:

substitutions:
  name: "music"
  friendly_name: music

esphome:
  name: music
  friendly_name: music
  name_add_mac_suffix: false

esp32:
  board: esp32-s3-devkitc-1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_MBEDTLS_SSL_PROTO_TLS1_3: 'y'

logger:
  level: VERY_VERBOSE

api:

ota:
- platform: esphome

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

psram:
  mode: octal

web_server:

i2s_audio:
  - id: i2s_out
    i2s_bclk_pin: GPIO09
    i2s_lrclk_pin: GPIO08

speaker:
  - platform: i2s_audio
    dac_type: external
    i2s_audio_id: i2s_out
    i2s_dout_pin: GPIO10
    id: spkr
    sample_rate: 48000
  - platform: mixer
    id: mixer_spkr
    output_speaker: spkr
    source_speakers: 
      - id: announcement_spkr_mixer_input
      - id: media_spkr_mixer_input
  - platform: resampler
    id: media_spkr_resampling_input
    output_speaker: media_spkr_mixer_input
  - platform: resampler
    id: announcement_spkr_resampling_input
    output_speaker: announcement_spkr_mixer_input

media_player:
  - platform: speaker
    name: ESPHome I2S Media Player
    id: media_plyr
    media_pipeline: 
      speaker: media_spkr_resampling_input
      num_channels: 2
      format: NONE
    announcement_pipeline: 
      speaker: announcement_spkr_resampling_input
      num_channels: 1

En de logging vanaf de "play" in HA:

[...]

[small]Klein opvallend dingetje is de [mono]?u] op het eind van de URL in de logging van de "MediaPlayerCommandRequest", deze staat niet in de (HA) service call noch in de logging van de media_player component. Daarnaast, for better or for worse, als ik format: NONE weg haal in de ESPHome config dan gebruikt die een URL naar de HA instance (/ffmpeg_proxy/....), en deze URL kan ik prima openen / afspelen op mijn PC dus die transcode / proxy werkt prima (en maakt er een flac van die dus zou moeten werken).
Daarnaast heb ik ook al meerdere pinnen geprobeerd, dus het is geen slechte verbinding in het (eigen) soldeerwerk en zonder stroom er op ook al de multimeter er aan gehouden, alhoewel dat natuurlijk meer zegt over de kabel dan de daadwerkelijke soldeerbinding gezien het meten aan de bovenkant van de pin/soldeer wat niks zegt over of het soldeer ook met het PCB verbind. En de DAC werkt dus bewezen want op de ESP32 werkt die wel (incl. zelfde dupont kabel).

Heeft iemand dus een idee wat hier mogelijk mis zou kunnen gaan?

Edit:
De hele mixer + resampler(s) er uit gegooid en vervolgens ook bij de media player de media_pipeline er uit en de announcement_pipeline (verplicht) rechtstreeks aan de spkr speaker gehangen. Als ik dan een tts.speak doe werkt het nog (steeds) niet. Dus het lijkt ook niet in de mixer/resampler te zitten.

Godsamme. Maar sporadisch nog eens naar gekeken. Met nu uiteindelijk de conclusie..., het ESP32-S3 bordje levert geen 5V over de 5V poort, tenzij je twee pads aan elkaar soldeert waarmee een van beide USB poorten niet meer zou werken?. Zie bv ook op het HA forum.

Met een multimeter mete ik nu dus 0,3V of iets dergelijks op de 5V pin. De MAX98357A blijkt ook "maar" tussen de 2,5 - 5,5V nodig te hebben. En nouja, op de 3,3V poort werkt die prima. Nu met een kant en klaar ESP32-S3 media speler projectje, AtlasCube. Maar heb zo'n vermoeden dat als ik er weer iets met ESPHome op zet... het net zo goed werkt.

Edit:
Goh, ook ESPHome werkt Ik had dit projectje misschien al een half jaar af kunnen hebben, zonder deze faal met of er wel stroom "aan komt".

[Magnifique]

RobertMe schreef op maandag 14 september 2026 @ 15:30:
[...]

Godsamme. Maar sporadisch nog eens naar gekeken. Met nu uiteindelijk de conclusie..., het ESP32-S3 bordje levert geen 5V over de 5V poort, tenzij je twee pads aan elkaar soldeert waarmee een van beide USB poorten niet meer zou werken?. Zie bv ook op het HA forum.

Met een multimeter mete ik nu dus 0,3V of iets dergelijks op de 5V pin. De MAX98357A blijkt ook "maar" tussen de 2,5 - 5,5V nodig te hebben. En nouja, op de 3,3V poort werkt die prima. Nu met een kant en klaar ESP32-S3 media speler projectje, AtlasCube. Maar heb zo'n vermoeden dat als ik er weer iets met ESPHome op zet... het net zo goed werkt.

Edit:
Goh, ook ESPHome werkt Ik had dit projectje misschien al een half jaar af kunnen hebben, zonder deze faal met of er wel stroom "aan komt".

Begrijp ik het nou goed dat je deze 2 moet verbinden om 5v goed te krijgen?

De twee soldeer punten boven 11 en 12

[ Voor 6% gewijzigd door Magnifique op 14-09-2026 16:24 ]

[RobertMe]

Magnifique schreef op maandag 14 september 2026 @ 16:23:
[...]

Begrijp ik het nou goed dat je deze 2 moet verbinden om 5v goed te krijgen?

De twee soldeer punten boven 11 en 12

Zoals ik het lees: ja. Met de zeer belangrijke kanttekening: als je dus 5V output wilt hebben bij USB als stroombron. Waarbij je dus never nooit niet zowel 5V via de pinnen moet voeden als USB aansluiten, want iets gaat dan stuk (en dat kan ook de USB poort op PC/... zijn?).

In mijn geval ga ik dus gewoon voor 3.3V gebruiken aangezien de DAC dat ook ondersteund en prima werkt.

[AUijtdehaag]

Weer eens leuk een esphome projectje (bijna) afgerond te hebben.

Ik had een APC backups 650 die in overload kwam te staan.
Na zoeken op internet, informatie gevonden wat het kon zijn, en bleek aan slechte condensatoren te liggen. Tevens een schematje kunnen vinden.
Lekker wat condensatoren vervangen en de ups kwam weer tot leven.Nu vroeg ik me af, of ik de ups niet kon uitlezen met een esp en daarmee een soort testkitje te maken die ook voltage uitleest van de batterij.
Ik had nog een m5stack VA meter liggen.

Er zit een RJ50 op de APC die wat informatie doorgeeft over een status "on battery" en status "battery low" bij te laag voltage.
Dat zouden dan mooi 2 ingangen kunnen zijn voor de ESP.
Spanning meten op de ingang van de VA meter met 2 pennen die zich vastgrijpen
Vervolgens wat in elkaar gefrommeld met transistors en weerstanden op een breadbordje om te testen.
Mbv Claude.ai een esphome code geschreven (werkt echt goed en snel voor mekaar)



YouTube: VA meter m5stack

Werking:
Zodra de UPS batterij aanslaat bij wegvallen voedingspanning (on battery), gaat er een timer lopen.
Totdat de UPS in battery low alarm valt dan stopt de timer.
Bij een nieuwe test met voedings spanningsuitval, wordt de laatste waarde opgeslagen op een 2e pagina met de nieuwste waarde bovenaan. Tijdsduur + voltage. En reset de timer naar 0.
Zo hoop ik slechte batterijen er ook uit te filteren. Twee nieuwe batterijen zijn onderweg als nulpunt.

Via programmatje EasyEDA een connector bordje gemaakt met groove 4p naar RJ45 (buitenste pins van de RJ50 werden niet gebruikt)

Bij JLCPCB laten ontwikkelen. Had een foutje gemaakt (connector in spiegelbeeld) , maar ze waren zo coolant om het bedrag terug te storten en ik kon een nieuw juist ontwerp zo weer in sturen.I love it when a plan comes together (The A team)

[ Voor 3% gewijzigd door AUijtdehaag op 16-09-2026 18:00 ]

[RobertMe]

RobertMe schreef op maandag 14 september 2026 @ 15:30:
[...]

Godsamme. Maar sporadisch nog eens naar gekeken. Met nu uiteindelijk de conclusie..., het ESP32-S3 bordje levert geen 5V over de 5V poort, tenzij je twee pads aan elkaar soldeert waarmee een van beide USB poorten niet meer zou werken?. Zie bv ook op het HA forum.

Met een multimeter mete ik nu dus 0,3V of iets dergelijks op de 5V pin. De MAX98357A blijkt ook "maar" tussen de 2,5 - 5,5V nodig te hebben. En nouja, op de 3,3V poort werkt die prima. Nu met een kant en klaar ESP32-S3 media speler projectje, AtlasCube. Maar heb zo'n vermoeden dat als ik er weer iets met ESPHome op zet... het net zo goed werkt.

Edit:
Goh, ook ESPHome werkt Ik had dit projectje misschien al een half jaar af kunnen hebben, zonder deze faal met of er wel stroom "aan komt".

En intussen met hier en daar een uurtje verder prutsen een volledige smart speaker (op breadboard met dupont kabels aan elkaar bungelen).
Een voice pipeline had ik al eens op gezet ("speech to phrase" en piper. Draait op een Intel N5105 die "nu al" minimaal 0,2s doet over SST);
Music Assistant had ik ook al draaien. Maar nog wat gepruts om die gekoppeld te krijgen (laat ik het er op houden dat ik een heel rare netwerk setup heb , waardoor mDNS een issue was).
En nu nog een INMP441 er aan hangen (waarvan de eerste stuk is of niet goed gesoldeerd, ander gesoldeerd en deed het wel).

Echt bizar hoe je dan in "een paar regels" YAML ineens een smart speaker hebt incl wake word en al.

Nu alleen nog ducking toevoegen ("announcements" en media worden gemixt, logischer is natuurlijk als muziek dempt / op pauze gaat); Kijken of/wat naar PSRAM kan; Een case verzinnen en 3D printen; Iets qua feedback doen (iets met de RGB LED of...); Matrix display toevoegen dat ik nu aan een ESP32 heb als klok (waar evt nog ruimte op is om met (enkele) pixels aan te geven dat die luistert;

Edit:
Overigens ook onder indruk van "luisteren". Op een afstand verstaat die het nog prima. Ook als muziek op de speaker speelt.

Alleen sendspin? heeft soms hickups waardoor de muziek "stottert". Geen idee of dat is omdat ik potentieel wat zaken expliciet in het psram moet duwen, of wifi, of.... (En heel misschien dat het issue in MA / sendspin zelf zit en er uberhaupt niks aan komt?).,

[ Voor 8% gewijzigd door RobertMe op 19-09-2026 20:38 ]

[CDAAbeltje]

Hi allen,

Ik heb vrij recentelijk een tuinverbouwing inclusief bouw van een overkapping achter de rug. De overkapping bevat een overstek waar uiteraard een aantal GU10 spots in zijn gekomen. Ik heb de stoute schoenen maar weer eens aangetrokken en bij de lokale Action de LSC GU10 spots opgehaald om te zien welke mogelijkheden er zijn met deze nieuwe lijn GU10 spots.

De spots bevatten de nieuwere Tuya T1 (T1-C-HL) chips en worden sinds een tijdje ondersteunt door ESPHome. Uiteindelijk heb ik de de Tuya firmware backup uit kunnen lezen om zo de juiste current waardes naar de outputs te kunnen sturen.

Een gedetailleerde write-up is te vinden op mijn GitHub pagina. Wellicht heeft iemand er wat aan

https://github.com/AbeltjeNL/LSC-Smart-Connect-GU10-ESPHome

[Septillion]

@CDAAbeltje Leuk he, de LibreTiny ondersteuning

Alleen jammer dat het een pain in the *** is om ze te openen.

Ik zou alleen modernere UF2 packages gebruiken om te flashen. Wordt ook gewoon ondersteund door ltchiptool. En snapte ltchiptool de uitgelezen bin niet ook gewoon voor de pinout? En gebruikt de print nog een standaard Tuya module of direct de chip?

En nog tipje voor de naam van je light component, gebruik daar name: None om hem de naam van je device te geven ipv jezelf te herhalen.

Waarom heb je de light eigenlijk een on_turn_on gegeven? En de on_state is nodig omdat hij anders niet herstelt naar iets zinnigs als je een effect uit zet?

En gelukkig voor het flashen van ESP's en dit soort zaken een USB-Serial adapter gemaakt met een beefy LDO erop zodat ik het wel kan poweren

[CDAAbeltje]

Septillion schreef op dinsdag 6 oktober 2026 @ 14:46:
@CDAAbeltje Leuk he, de LibreTiny ondersteuning

Alleen jammer dat het een pain in the *** is om ze te openen.

Ik zou alleen modernere UF2 packages gebruiken om te flashen. Wordt ook gewoon ondersteund door ltchiptool. En snapte ltchiptool de uitgelezen bin niet ook gewoon voor de pinout? En gebruikt de print nog een standaard Tuya module of direct de chip?

En nog tipje voor de naam van je light component, gebruik daar name: None om hem de naam van je device te geven ipv jezelf te herhalen.

Waarom heb je de light eigenlijk een on_turn_on gegeven? En de on_state is nodig omdat hij anders niet herstelt naar iets zinnigs als je een effect uit zet?

En gelukkig voor het flashen van ESP's en dit soort zaken een USB-Serial adapter gemaakt met een beefy LDO erop zodat ik het wel kan poweren

@Septillion ja inderdaad, LibreTiny ondersteuning is heel erg leuk! Het biedt weer een breed scala aan mogelijkheden

Het openmaken lukt je alleen met veel geduld. Heb je dat niet, begin er dan ook niet aan. Van de eerste spot is het glas gebroken en de vijf daarna volgende is alles heel gebleven.

Ik heb het net even nagekeken en ik heb inderdaad de UF2 packages gebruikt. Ik heb de tekst gekopieerd vanuit een van mijn andere repo’s waarbij ik eind vorig jaar aan het flashen ben geweest met wel de .bin bestanden. Ik zal het even aanpassen. Thanx!

Nee helaas kon ltchiptool zelf niets met de Tuya T1 firmware vandaar dat ik opzoek ben gegaan naar andere tooling en uit ben gekomen op BK7231 GUI FlashTool. De LED print gebruikt de BP5758D driver en dit bordje wordt verbonden met de witte pin header aan de Tuya T1 (T1-C-HL) chip.

Dank voor de name tip. Dit geeft inderdaad een dubbele benaming overal in de ESPHome configuratie en in Home Assistant. Dit had niet in het yaml voorbeeld moeten staan, dit gebruik ik namelijk helemaal niet. Ook dit zal ik even aanpassen.

Ik heb de on_turn_on meegegeven omdat ik merkte dat in sommige gevallen de koud witte LED’s heel zacht oplichten. Dit dus om zeker te weten dat ze niet oplichten en pur sang alleen warm wit wordt aangeroepen. Daarnaast ook wel fijn voor de WAF factor dat de lampen altijd terug gaan naar warm wit als er gespeeld is met kleurtjes. In mijn situatie zijn het 5 spots die de lady vanuit HomeKit middels een groep bediend. Zet maar een keer uit en weer aan en dan is alles weer zoals het hoort. Veel gemakkelijker kan ik het niet maken voor mijn wederhelft.

on_state heb ik inderdaad meegegeven om te herstellen van een effect. Als ik dit niet doe krijg je lampen die letterlijk in het laatste lichtpatroon of kleur blijven hangen van het effect. Ik ben nog wat aan het rommelen met een van de aiaiai agenten om wat meer leuke effecten te creëren. Zodra dit goed en werkend getest is zal mijn GH repo geüpdatet worden.

Ik gebruik m'n oude vertrouwde regelbare voeding maar ik moet zeggen dat het flashen vaak ook wel goed gaat via de UART 3V3 vanuit de stick.

[ Voor 12% gewijzigd door CDAAbeltje op 06-10-2026 23:04 ]

[Bakema]

Ik kan er zo even niks over vinden, maar iemand ervaring met een thuisbatterij systeem icm een GTIL2, als ik zo zoek zijn hier opties voor icm een ESP32 'sun_gtil2'.

Ik was van plan dit met een Hoymiles omvormer te doen, maar helaas start deze niet op met mijn 24 v accu. Dus nu heb ik een ESP32 over, en een 24V 300Ah Lifepo4 accu Die ik graag in wou zetten als thuisbatterij. Nu is zon omvormer van in principe geschikt voor het totale plaatje, alleen een kabel trekken van de schuur naar de meterkast is niet echt ideaal(hele tuin op de schop) dus icm ESPhome zou dit perfect kunnen dmv de P1 uitlezen...maar kan nog niet vinden of er meer mensen zijn met een soortgelijk systeem hier?

[JBS]

Holmes schreef op zaterdag 10 oktober 2026 @ 21:11:
[...]

@JBS Thanks, ben er ook echt super blij mee hoe het nu zo werkt. :-)

Het scherm is een Guition/JCZN ESP32-S3 4848S040 (480×480). De basis draait op ESPHome en LVGL en communiceert via de native ESPHome API met Home Assistant. Home Assistant blijft daarbij de ‘source of truth’; het scherm is voornamelijk de bedienings- en statuslaag. Touchacties op het scherm sturen dus HA-helpers/scripts/services aan en de actuele status komt vanuit HA weer terug naar het scherm.

Ik heb inmiddels ook zo'n display en worstel wat met het touch gedeelte. Touch wordt wel geregistreerd, maar de plek correspondeert niet met de UI. Na het toevoegen van de on_touch: aan het touchscreen: gedeelte zoals hieronder, zie ik in de log de coördinaten bij aanraken voorbij komen. Analyse daarvan ook hieronder toegevoegd.

Rechtsboven:
[21:01:57.253][D][main:1327]: Touch geregistreerd op X=224, Y=0

Linksboven:
[21:02:14.263][D][main:1327]: Touch geregistreerd op X=0, Y=0

Rechtsonder:
[21:02:28.313][D][main:1327]: Touch geregistreerd op X=224, Y=383

Linksonder:
[21:02:43.455][D][main:1327]: Touch geregistreerd op X=0, Y=383

Heb jij ook calibration: moeten toevoegen aan je ESPHome YAML?
Hier zie ik dat namelijk niet: https://devices.esphome.io/devices/guition-esp32-s3-4848s040/

Het probleem is niet de oriëntatie, maar de resolutie (schaal) van het touch-paneel. Het scherm is 480x480 pixels, maar jouw GT911 chip is intern geconfigureerd om maximaal X=224 en Y=383 door te geven.

Als LVGL een knop aan de rechterkant van je scherm tekent (bijvoorbeeld op X=400), verwacht het een aanraking op X=400. Maar omdat jouw touch-paneel fysiek stopt bij 224, zal je vinger die coördinaten nooit bereiken, en reageert alles op de verkeerde plek.

Het goede nieuws: Linksboven is netjes 0,0. We hoeven de assen dus niet meer te spiegelen of om te draaien. We hoeven ESPHome alleen maar te vertellen dat hij de binnenkomende waarden moet 'oprekken' naar de volledige 480x480 resolutie. Dit doen we met het calibration blok.

YAML:

touchscreen:
  - platform: gt911
    id: tft_touch
    display: tft_display
    on_touch:
      - logger.log:
          format: "Touch geregistreerd op X=%d, Y=%d"
          args: [touch.x, touch.y]

[ Voor 8% gewijzigd door JBS op 22-10-2026 06:50 ]

[JBS]

JBS schreef op woensdag 21 oktober 2026 @ 21:16:
[...]

Ik heb inmiddels ook zo'n display en worstel wat met het touch gedeelte. Touch wordt wel geregistreerd, maar de plek correspondeert niet met de UI. Na het toevoegen van de on_touch: aan het touchscreen: gedeelte zoals hieronder, zie ik in de log de coördinaten bij aanraken voorbij komen. Analyse daarvan ook hieronder toegevoegd.

Rechtsboven:
[21:01:57.253][D][main:1327]: Touch geregistreerd op X=224, Y=0

Linksboven:
[21:02:14.263][D][main:1327]: Touch geregistreerd op X=0, Y=0

Rechtsonder:
[21:02:28.313][D][main:1327]: Touch geregistreerd op X=224, Y=383

Linksonder:
[21:02:43.455][D][main:1327]: Touch geregistreerd op X=0, Y=383

Heb jij ook calibration: moeten toevoegen aan je ESPHome YAML?
Hier zie ik dat namelijk niet: https://devices.esphome.io/devices/guition-esp32-s3-4848s040/

[...]

YAML:

touchscreen:
  - platform: gt911
    id: tft_touch
    display: tft_display
    on_touch:
      - logger.log:
          format: "Touch geregistreerd op X=%d, Y=%d"
          args: [touch.x, touch.y]

En toen kwam ik https://tessera-maxgramser.on-forge.com/ tegen waarmee ik binnen no-time kan maken wat ik wilde. Ik neem voorlopig even afscheid van LVGL (door AI laten) maken.

[RobertMe]

Hmm. Ik heb een Frankenstein DIY smartspeaker incl Sendspin gekoppeld aan Music Assistant.

In het ESPHome 2026.10 changelog staat mooi dat pairing nu nodig is en daarvoor is ook een MA versie nodig die ergens vorige week is uitgekomen (wel erg korte "overlap") dan.
Maar mijn conclusie is dat de boel nu ook stuk is en ik actief allemaal stuff voor de pairing moet toevoegen. De speaker komt niet online in MA, maar geeft wel een reconfigure knop. Vervolgens moet je de pairing code invullen, maar...? Geen idee. In de ESPHome Sendspin docs staat vanalles omschreven over het instellen van een statische pairing code (hardcoded in de YAML) of een dynamische pairing code, waarbij je óf een text sensor kunt maken waarin de pairing code wordt gezet (die je dan op een display kunt plaatsen / exposen naar HA / ...?). En in ieder geval de variant met een statische pairing code lijkt het er op dat je een action moet aanroepen om de pairing te bevestigen (oftewel zou ik een knop op basis van GPIO moeten toevoegen, incl dus "de hardware", dan een automation onder die GPIO maken, en daarin die confirm pairing doen). En het dynamische pairing code verhaal is net zo vaag w.m.b..

Oftewel: met de update is iets "stuk" gegaan, en hoe je het fixt mag je zelf uitzoeken, en wellicht moet je ook maar even de hardware aanpassen.
Kunnen ze niet gewoon by default een dynamische code gebruiken en die over de serial (en web) logs schrijven? Waarbij de logs volgens mij via de ESPHome builder ook encrypted zijn? En als je fysieke toegang hebt tot de seriële poort maakt een pairing code waarschijnlijk ook weinig meer uit.

Edit:
Overigens staat in de blogpost / aankondiging ook iets van pairing waarbij HA kan koppelen met MA. Als ik het goed begrijp kan ("vol automatisch") de pairing code over de ESPHome API worden gestuurd, en je vervolgens in HA een bevestig knop krijgt die de code doorstuurt naar MA. Daarvoor zal dan vast de MA integratie nodig zijn, en die heb ik ook, maar ik heb MA niet aan HA gekoppeld, wat wellicht ook nodig is? Maar ook daarvan dus geen documentatie te vinden (het staat als feature in de blogpost, maar dus niks over wat je ervoor moet installeren / instellen (MA integratie in HA? HA in MA?), niks over hoe je die bevestigsvraag in HA krijgt (automatisch? Moet je ergens op drukken?), etc.

Wel zie ik in HA bij het device een nieuw "Everything is set up" blok. Incl "Set up" knop. Wat vast komt uit die andere nieuwe feature dat vanuit ESPHome er een wizard in HA getoond kan worden. Als ik op "Set up" klik staat daar wel een "Sendspin" blok, maar met vinkje en alleen een uitleg, geen knoppen om "iets" te doen of zo. Hoogstens wellichtmisschien dat ik eens het apparaat in HA moet verwijderen en opnieuw toevoegen?

Edit2:
Blijkbaar was die wel "online" gekomen . unpaired_access is volgens de docs ook true by default. Wat het raar zou maken als pairing vervolgens alsnog verplicht is.

[ Voor 29% gewijzigd door RobertMe op 23-10-2026 19:47 ]