Shelly devices keep turning off/on

Hi everyone
in a complete restructuring of my home network and IoT devices I switched all of my devices to ESPHome. I only reinstalled my Shelly 2.5s so far but I have noticed that they randomly power cycle the relays for a fraction of a second.
Only reason I noticed is because they switch my lights.

For other electronics this behavior could be deadly.
Does anybody have any idea what could be causing this? Is this some kind of known behavior?

The webUI logs don’t show anything interesting.

Thank you for your insights
Alex

Usually down to poor wifi.

If the connection drops the device reboots.

Everytime it loses wifi? That is crazy :smiley:

I am just doing rewiring and took my HA offline. Is it just wifi, i.e. connection to AP, or connection loss to HA?

I have similar problem with Shelly 1PM Mini Gen3, but my one is on stock firmware. There were few FW updates on the road, but issue did not disappeared. Once in a while it randomly switches off and then on after few seconds. It happens once every 2~4 weeks. Notrials in HA that it was initiated by any script or automation.

Is the device(s) overheating, current, voltage? Have you set the logs for the device(s) for those conditions. I only buy Shelly devices that support wired ethernet. Even if it has WiFi, I turn it off. WiFi has always been flaky for me.

Not in my case. Load is negligible in my case and temperature well within specification limits. Not sure about voltage spikes, but I guess I’d notice this with other lights not controlled by this specific module.

Well, 230 V and 6 Watts should not cause anything to fail :smiley:

It looks like it was the reboot_timeout which causes the devices to reboot when HA or wifi is unavailable. Testing again this evening when I need my lights on again.

Set timeouts for both to 0s to disable this strange feature. IMO this should be disabled by default. A lot of relays switch on power cycle.

It really depends on the goal. For your use case, disabled would prevent the lights switching when you didn’t want them to.

So, that begs the question why is the default the way it is?

I was not involved in making the decision, but I suspect it was made when reliability of Wi-Fi was much less than it is now. For whatever reason, devices would go offline (from Wi-Fi and/or HA) and the only way to get them back was to power cycle them. For some devices this could be incredibly hard to do. I suspect someone came up with the idea that rebooting the device was a good solution to this problem. If it fixed the connection everything would be good automatically. If it didn’t, it would bring attention to the more pressing underlying problem.

I don’t use a direct connection to HA, so I don’t run into this issue. My Wi-Fi is also incredibly reliable and all of my devices are easy to power cycle.

I read the docs and it is even clearer WHY this is the default.

reboot_timeout (Optional, Time): The amount of time to wait before rebooting when no client connects to the API. This is needed because sometimes the low level ESP functions report that the ESP is connected to the network, when in fact it is not - only a full reboot fixes it. Can be disabled by setting this to 0s. Defaults to 15min.

I understand the idea but weirdly no other firmware seems to need this. So either esphome has a crucial issue which needs fixing or this approach is outdated.

I understand why one would have this functionality, of course, but making it the default behavior when it is known that this causes a lot of relays to switch or causes state changes due to on boot settings, is very risky.

I woke up this morning with my garage door open. I can only assume that somehow one of my rf setups triggered the garage door. Not sure how or why, but one of the reboots seems to have toggled the door. Due to lack of logs when the device has no network, I cannot say for sure what happened last night, but if it is related to a reboot then this “feature” as default behavior is a security risk.

This issue appears to be related to the HA API. HA is definitely not the center of my automation world, so I have never seen this issue.

Feel free to file an issue on GitHub or talk to people on the discord server.