This didn’t work, because I knew from another thread that delay is asynchronous so it just goes to deep_sleep before the servo moves. I see from the log that the switch is triggered but not enough
time to complete it.
on_shutdown:
then:
- switch.turn_off: esp32_move_servo
- wait_until:
condition:
text_sensor.state:
id: esp32_current_time
state: 'This is for intentional timeout. Never goes TRUE.'
timeout: 5s
This wait_until condition didn’t work either.
The only way I can think of is to calculate the time to trigger this switch after wake up,
say like (run_duration - 5 seconds), before the deep_sleep process kicks in.
But is that the only way I can achieve it?
A fake 5s switch perhaps?
When the switch/servo then returns to the position you can tell how it that reported on HA e.g. closed. You could set up an automation to publish an mqtt message to topic esp32/servo_position to tell it to only go into deep sleep then.
Thank you so much for your help.
I would like to implement your idea, but the way I would like to move the servo is not to deep_sleep
after the servo moves, but at the time just before it goes deep_sleep.
It is different behavior because I still need to control the time when to move the servo, with your idea.
Please correct me if I am wrong.
For my case, run duration is constant for 5min, and I want 5 minutes to perform other tasks.
I think if you run deep sleep just before the servo moves then the esp will not be able to move the servo unless the servo can move back to the desired position without power. The esp can’t do anything while it is in deep sleep except wait until it wakes again.
Yes that is what is happening now.
Your idea makes me better think to issue the closed payload from an HA automation.
I wanted to script this locally at esp32, but seems feasible other way around.
I ended up using your idea and it is working great. Thanks!!
Now the whole timing is controlled via HA’s automation,
so that esp32 goes deep_sleep, after the physical move of the servo is completed.
The point I understood from this case is that HA’s delay parameter is synchronous,
so it would correctly wait before it fires the next command (deep_sleep).