Adding to the answer before: It could happen, that the OTA Update does not work, if the ESP does not run for 1 minute (or longer, if bad luck it depends on the ESP) after the update. Deep in my brain, I assume, that this was the reason, why I am fiddling with the awake time before I run an OTA update. But this is, what you should test, or keep in mind.
Juergen
The keyword here is “firmware”. The ESPHome dashboard is accurately reporting that the firmware is up-to-date, not the device. In the dashboard, click on the device and scroll down to “Version”. This is where you will see if the installed version is different from the compiled version.
I don’t use “awake time” at all. I don’t see the need for it. When I am finished with whatever the device needs, I put it back to sleep. If you use Awake Time, you risk going back to sleep before finishing whatever you are doing.
Perhaps my problem got a bit lost in the length of my description. Yes I did follow the instructions.
Basically the device does not go back to sleep when there is NO update.
Therefore your comment about the automation to trigger deep sleep after an update does not seem relevant (correct me if I have misunderstood). The description of that automation states that it is NOT called if there are no updates.
I would have though that my situation would be the most common one - wake up > send the sensor data > see there is no update > go back to sleep.
The integration can detect when a device comes on line which is necessary. It would appear that it then checks if an update is available and proceeds to do the update if there is, after which it calls the automation to return to deep sleep.
But that does not seem to support the workflow that I understand is needed for when there i no update.
So, if the integration does not support the ‘no update’ situation, is there a state (or whatever) I can check to see if the integration does NOT have an update available so that I can write my own automation that wakes on the device connection, check that no update is available and then trigger the ‘deep sleep’?
Susan
I see what you mean now, and you have a point, this is indeed a problem.
I’m working on a solution and will keep you updated.
UPDATE:
There is a new release (v1.11.1) and a new automation that addresses this issue.
You’ll need to configure the awake window in the automation (in your case 10 sec).
When the device comes online and there is no update pending, the automation will trigger deep sleep after 10 sec. In case of a pending update, the update will start, the device will reboot after the update and when back online it will go to deep sleep after 10 sec.
Thank you very much for the quick response.
Susan
Basically this is what I am doing as well: I generate my own “awake” time, I put the ESP to sleep if the program is done. This is what I call “awake” time.
I’ve noticed that one of my devices (that sleeps for 30 minutes before taking samples for 10 seconds) does not receive updates.
Looking at the automation trace, I see that it is triggered when the device comes on line, but from my limited knowledge of how to read the trace information, it does not seem to ever look to see if the device has a pending update.
What do I need to do to make sure that, where there is an update available, that this is applied when the device wakes up?
(I can provide any other information to help look at this.)
Susan
Hi Susan,
A few things to check:
- Check your
deep_sleep:block in the YAML, does it haverun_durationset (e.g. 10s)? If so, that needs to be removed. Per the README, the deep sleep block must not definerun_duration, the device needs to stay awake until the automation presses the deep sleep button, otherwise it goes to sleep on its own after that fixed time, regardless of whether an update is running. - Is auto-install enabled, and is the scope set to something that includes firmware updates (
Firmware onlyorFirmware + Project)? - Do you have a
statusbinary_sensor configured on the device? Without it, both online detection and the automation’s timing become unreliable/slow. - With
run_durationremoved,awake_window_secondsin the automation effectively takes over that role, it’s the time the device stays awake for its normal task (taking samples, etc.) before the automation puts it back to sleep. If an update is already running by the time that window elapses, the automation correctly keeps the device awake until it finishes, so the update itself isn’t limited to 10 seconds. The risk is in the timing of the start: if auto-install hasn’t kicked off yet by the time the automation checks (e.g. the update queue is busy with another device), the automation will see nothing active and put the device back to sleep before an update ever started. Try settingawake_window_secondsa bit above your normal 10s task time (e.g. 15-20s) to give auto-install a bit more margin to kick in. - Alternatively, you can select the device for Force Install in the panel while it’s offline, this queues it on the persistent pending list and works independently of auto-install. When it wakes up, the install will start automatically, but only after a ~15 second debounce window (so multiple devices waking up at once can be batched). Since the debounce and your
awake_window_secondsboth start counting from the same wake moment, settingawake_window_secondsto exactly 15s risks a race condition, the automation might check just before the install is registered as active. Give it a bit of margin above the debounce (e.g. 20s) so the check happens after the install is reliably active, you don’t need to add the install duration on top of that, since the automation keeps the device awake until it finishes once it detects it running.