ESPHome fails to update sensor state in HA when using > 4 second delay filters. Workaround?

ESPHome
1

Given the following code, after program upload or device reset, HA will not show the on/off state of the binary sensor “Dev-(+3v3_U)”. Change the - delayed_on: 1min to something less than 5 seconds, and it works fine. Using the API. Anyone else dealt with this behavior or have a workaround?

  - platform: gpio
    pin:
      number: GPIO36
      mode: INPUT_PULLDOWN
    name: "Dev-(+3v3_U)"
    id: util_power
    filters:
      - delayed_off: 4s
      - delayed_on: 1min
    on_release:
      then:
      - switch.turn_on: dev_genstartstop_ssr
      - switch.turn_off: dev_vsns_3v3
      - logger.log: "Dev-(+3v3_Util) LOW > 4 seconds - Generator Starting"
    on_press:
      then:
      - switch.turn_off: dev_genstartstop_ssr
      - switch.turn_on: dev_vsns_3v3
      - logger.log: "Dev-(+3v3_Util) HIGH > 1 minutes - Generator Stopping"

Capture

2

If i understand correctly then your setup should show state “on” in HA not sooner than 1 minute after reset, since 1 minute is delay for “on” state. Did you wait that long to see state change?

3

Correct. On boot or after program upload, GPIO is in a HIGH (ON) state. Expected behavior is that HA should reflect that, but shows OFF. If we pull the input LOW (Release) for 4 seconds, ‘then’ code properly executes in ESPHome, and of course HA still shows LOW. If we take the pin HIGH (Press) again for 1 minute, the sensor in HA will then properly catch up and display properly. Any way to make ESPHome report the sensor starting value on boot?

4

I think that with current setting behaviour is correct in HA.
If you want immediate result inside HA… well, i’m not an expert, but one of options is to remove delay in ESPHome and do it with automation inside HA.
However, if you want to run even when module is not connected to HA, i think that it’s also possible: you make your input without filters, but you rather use delays inside “on_press” and “on_release” functions.

Like i said, i’m no expert, so i’d have to experiment to get a result, but it’s just a thought to go further…

5

Hey thanks for responding Pavel and giving this some thought.

Unsure about comment ‘current setting behavior is correct in HA’. If you keep the delays under 4 seconds for any of the options, then HA reliably shows the initial state on boot. Go over 5 seconds, and the bug appears, so I’m still thinking that’s not correct. Have created an issue report at Use of delayed_on_off filter in Binary Sensor Component breaks HA sensor updates · Issue #2537 · esphome/issues (github.com) with more info.

I do need to keep core functionality on the ESP32, as this application is controlling a Caterpillar Olympian Generator for mains power. One failure mode may be that the ESPHome loses WiFi communication with HA for a time, so needs to operate independently. Actually the boot up status shown in HA is more of an annoyance since the running code and timings on the ESP32 continue to work, even if HA does not show the proper state initially.

I did look at your suggestion to use delays inside “on_press” and “on_release”, but I would lose the inherent brown-out detection of the delay filters. I.E. when we lose grid power for only a moment or under a few seconds, we don’t want the generator to fire up. More importantly, when grid power returns, we don’t want the generator and associated breaker switching to happen until grid power appears stable, after say 4 or 5 minutes.

6

If you define filter “delayed on” inside esphome then esphome won’t publish “on” state to HA until this filter is ended/fullfilled, in your case this happens after 4 minutes. That is what i mean by “is correct behaviour in HA”. If you use “on press” then state is immediately sent and only then delay begins.
I hope that someone else will be able to help you…

7

I think I am starting to narrow down where the problem is. I created a simple test of one pin and a long on/off filter and uploaded it to a new ESP32 Feather. I noticed in the log that after the filter delay, the log showed:

[05:27:45][D][binary_sensor:034]: 'test-devnode-switch': Sending initial state ON

This is not appearing in my longer production code, and is obviously where the ESP is supposed to be sending the initial pin states up to HA. I will focus on that and report back when / if I can find out why.