How to wait for HA switch statuses on_boot

ESPHome
1

This is an odd one, I have device which works fine when running but I need to have it set the correct state on boot, depending upon the status of two binary sensors derived from HA switches.

However, on boot, I believe that the condition I’m trying to check has an “unavailable” returned, so it never sees the correct status. The logical (to my addled mind) was to have a wait_until for that waited for either on or off before performing the condition…

       - wait_until:
           condition:
             or:
               binary_sensor.is_off: x1c_power
               binary_sensor.is_on: x1c_power

However, this is rejected as bad syntax, saying that it (logically enough) conflicts.

Is there a way to force the on_boot to wait until the specific sensor has a true value?

NB - I have already set a priority of -100
NB(2) - setting a manual delay of 10s allows it to work, but that’s very inelegant.

2

Ignore that. I can now see where I went wrong. The plan was correct, the formatting was not!

I changed it to only wait for “on”, but with a timeout as it seemed to hit “off” first, before correctly recognising on. So, I changed it to the following, which works - in case this helps someone else:

    - priority: 200
      then:
        # - delay: 10s
        - wait_until:
            condition:
              or:
                - binary_sensor.is_on: x1c_power
                - binary_sensor.is_on: laser_power
            timeout: 10s
        - if:
            condition: 
              or: 
                - binary_sensor.is_on: laser_power
                - binary_sensor.is_on: x1c_power
            then:
              switch.turn_on: psu_switch
3

Ya… That condition is completely unnecessary and FYI, a binary_sensor only has 2 states available for its option and it will default to On/Off based on other factors so, that all needs removed to start with.

IDK what it is about so many of the newer people mostly but, they are just determined to always find some reason to think they need to use the on_boot configuration to manually update sensors/entities that for 1 dont require that and 2, all your entities are updated automatically on boot and on every single loop and 90% of stuff typically found in people’s on_boot configuration isnt needed at all and you can often make the argument that people cause additional problems from all that mess.

Dude, that sensor and every other entity is going to update and publish its most recent state as part of the default boot process and happens very quickly after it reboots without requiring any specific actions outside of unique circumstances which your’s is not.

Whatever the reasons you have for asking about delaying the on_boot untill a particular sensor state is known, i wouldn’t say that your far off and i have an idea of why you’d want that but, your real problem is your trying to deploy that automation/instructions in the wrong spot and you just need a little guidance.

The first thing that you need to fix is you need to fix your OP and please dont decide for others, which bits or pieces of the yaml configuration are necessary to share here. Just post it all so that people can gain an understanding of the contexts and to assist in following along with people’s thought processes which can be very useful because people dont dont know what they dont know and they may not even be asking the correct question to begin and we can’t determine all those things when people decide to create an OP and allow us as little details as possible… Please fix that and add fulll code so that people can actually help you instead of only answering the original questions that really aren’t the right questions in your situation. Thanks

4

Thank you for your response. I’m sorry that you found my question a little disconcerting. I believed that what I wanted to do was a legitimate process and, indeed, the change I outlined now make it perform as I’d wanted.

I simply wanted the device to correctly set up several parameters when it was booted (eg after a power failure). It does now do this.

I take your point about the lack of context, though. My rationale was to try to reduce the amount of unnecessary detail, of course, but I concede that that might also have been unhelpful

Sincerely, though, thank you for taking time to answer my post - albeit somewhat perjoratively :wink: