Sync ESPhome entity to HA on startup

ESPHome
1

New to the forum and newish to HA/esphome

I have an esphome entity representing an indicator LED. It is of course reflected in HA.

This LED reflects availability of AC for a home device. It is updated by another esphome module connected to the device.

So, all is fine and dandy and works as it should, UNTIL the esp controlling the indicator LED loses power or otherwise disconnects. Upon its restart, the LED indicator does not resynchronize to the value in home assistant.

How do I force this synchronization on startup (or re-connect) ?

Thank you

2

First question is how you have configured things? Any yaml’s of the status quo you can provide for example :point_down:

3

OK, this is the relevant part of the LED display yaml:

substitutions:
  name: wall-sw
  ip: 10.0.2.30

esphome:
  name: $name
  friendly_name: $name
  build_path: "../config/esphome/build/${name}"

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:
    level: DEBUG


# Enable Home Assistant API
api:
  encryption:
    key: "redacted"

ota:
  password: "redacted"
  platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: ${ip}
    gateway: 10.0.2.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${name} Fallback Hotspot"
    password: "redacted"

captive_portal:
    
web_server:
  port: 80

# LEDS ***************************************
light:

  - platform: fastled_clockless
    rgb_order: GRB
    chipset: WS2812B
    pin: GPIO32
    num_leds: 6
    name: "SWL2"
    id: SWL2

    
  - platform: partition
    name: "L1"
    id: L1
    default_transition_length: 0s
    segments:
      - id: SWL2
        from: 0
        to: 0

  - platform: partition
    name: "L2"
    id: L2
    default_transition_length: 0s
    segments:
      - id: SWL2
        from: 1
        to: 1


# SWITCHES ****************************
....
# IR receiver ****************************

....

And this is the second part (which activates the Led via a HA/nodered automation)
– this is a macro called from another yaml from a different esphome —

# switch pin
switch:
  - platform: gpio
    pin: GPIO$pin_n
    id: sw${cardsw}
    name: sw${cardsw}
    on_turn_on:
      - lambda: pinMode($pin_n, OUTPUT);
      - delay: 100ms
      - switch.turn_off: sw${cardsw}
    on_turn_off:
      lambda: pinMode($pin_n, INPUT);

#sense pin
binary_sensor:
  - platform: gpio
    pin:
      number: GPIO$pin_s
      inverted: true
      mode: INPUT_PULLUP
    name: sns${cardsw}
    filters:
      delayed_off: 75ms

Calling yaml (again, relevant parts)

substitutions:
  name: lt12
  ip: 10.0.2.212

esphome:
  name: $name
  friendly_name: $name
  build_path: "../config/esphome/build/${name}"

esp32:
  board: esp32dev
  framework:
    type: arduino

 
# Enable logging
logger:
    level: VERBOSE
#   baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: "redacted"

ota:
  password: "redacted"
  platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: ${ip}
    gateway: 10.0.2.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${name} Fallback Hotspot"
    password: "redacted"

web_server:
  port: 80

captive_portal:

 
packages:
  b1: !include {file: .lt_inc.yaml, vars: {pin_n: 15, pin_s: 13, cardsw: 1}}
  b2: !include {file: .lt_inc.yaml, vars: {pin_n: 04, pin_s: 12, cardsw: 2}}
...
4

I would skip ha/nodered automation for this task completely and just use the native home assistant “import function” on the second esphome node :point_down:

This should be mitigated as well by the default behavior. Guess beside on and off their might also be an unavailable which could be used to blink the led for example to identify malfunction :rotating_light:

5

Thanks a lot. I will try to wrap my head around what you wrote

6

Unfortunately, use of home assistant sensors does not seem to mitigate the problem. It seems they do not update their counterparts when the esphome node reboots.

There are awkward workarounds using on_client_connected or using heartbeat indicators, but in the end, I think it should be expected that reflected entities will synchronize when one of the 2 sides restarts. Or perhaps I missed something.

7

FYI, its really frustrating when someone posts a question and then decides which parts of config or which details are pertinent information. If your here asking for help then you definitely dont know which information is pertinent or not. Even if you 100% know it isn’t related, you need to include it anyway. Its easier to help you if we can see what your doing or what your trying to do and if its not relevant the people taking their time to help you, they can decide if it is or isnt pertinent. People will either decide its not relevant and move on or it is relevant and now they can help you and you never know, maybe someone can off you tips on improving it.

When you do this, its like trying to read a book with 2 chapters missing. Things dont make sense and instead of having answers for you, now people have questions for you, like I do.

Please just provide all information whether you think its relevant or not.

We cant see any of the automations/actions that control the lights. What are you using to determine “availability of AC”? The purpose of second config/esp board, its essentially a generic template with a file included. Where is the condig for the file? What does this file do? I could probably look at your config and answer most of this but, you decided it wasnt relevant for me to know…

Also,

Is 100% right. Theres no reason to be mixing such a simple automation up between Esphome, HA, and NodeRed. Your significantly increasing the complexity which you dont need to do and increasing the risk of a failure. Now if either of those 3 have a problem your automation wont run. Ideally, you want to keep everything in esphome or esphome w/HA, especially for such simple tasks. Your much less likely to have little problems that cause huge problems down the line.

Please post ALL your config and maybe briefly explain what each switch/sensor is for or its purpose. We need information and details to help you. Without them, rhe best your going to get is a bunch of people theowing out guesses and wasting your time.

8

Any logs and configs you can provide that mach your thoughts? :thinking:

Never experienced this problems and I use such functions since many years :spiral_calendar:

binary_sensor:
  - platform: homeassistant
    entity_id: binary_sensor.remote_esphome_float_switch
    id: ha_remote_esphome_float_switch
    internal: true
    on_press:
      then:
        if:
          condition:
            - switch.is_on: auto_stop
          then:
            - switch.turn_off: relay

this is the relevant (esphome) yaml part I use on a water pump that automagically :magic_wand: stops when a float switch on second esphome node triggers :checkered_flag:

9

Am i the only one going to ask about this? A gpio switch that when turned On does a 100ms delay and then turns itself Off?

What is the intended purpose of this? What is wired to this gpio? Is it a momentary button? Latching button/switch? Some sort of sensor?

10

@ Fallingaway24

Yes, this is a momentary switch wired in parallel with a hardwired device-mounted momentary switch which turns on and off the device. The device state is only knowable by sensing AC via a optocoupler

11

@ orange-assistant

In your configuration, what happens if the float switch triggers while the first node is temporarily unpowered and then reboots while the float switch is still on

12

Nothing, if the first node is unpowered the load will be off and not turned on again after restart. :white_check_mark: