esphome should not anyhow reboot

[bilogic]

Describe the enhancement

No, I will describe the problem first: wifi, mqtt and api defaults have a very blunt reboot_timeout: 15min mechanism that is extremely disruptive especially when there are issues with the router or server

• Does rebooting help get the mqtt and api back into working order when the wifi is working (ping-able + connected)? - NO
• Thus, if the wifi is up and gateway is ping-able, do nothing even if mqtt and api are failing
• As for wifi, if wifi_info is able to get some results, please, also do nothing, who decided that rebooting will somehow bring the required SSID back in view?

Use cases

It is already quite stressful when the router (wifi) or servers (mqtt, api) are down, and the default behavior of ESPHome when any of the 3 are down is to reboot every 15 minutes. Please, there is no need to further contribute to the chaos.

The better behavior is to actually do nothing.

Visual examples

No response

Anything else?

1. If wifi connected, ping gateway/defined IP, if no response after 15 minutes, reboot
2. If 0 SSID detected, maybe our wifi is bad, proceed to reboot after 15 minutes
3. If >1 SSID detected, but cannot find ours, try reconnect every X seconds/minutes forever
4. Remove reboot_timeout for mqtt, if wifi is up, mqtt should try and reconnect every X seconds/minutes
5. Remove reboot_timeout for api, if wifi is up, just sit there and wait forever for the API to connect in

[swoboda1337]

You can disable the reboot?

[bilogic]

I have, but we still need it to reboot under 1 and 2, I'm proposing this be the default behavior of esphome, it makes more sense to me. And it also removes the need for restore_mode which causes wearing out of the nvram.

[bdraco]

The reboot timeout is a safety net for problems we can't predict, and that's why it's on by default.

All of the proposed checks assume the firmware can correctly figure out what's wrong with itself. The failures that actually strand devices are the ones where it can't. Wifi drivers sometimes wedge while still reporting connected. The TCP stack can get into a state where pings work but connections don't. An esp-idf upgrade can introduce a regression nobody saw coming, or a board can have flaky hardware. In those states a gateway ping check is just more code running on the same broken device, and it will tell you everything is fine while the device sits unreachable. Rebooting is the one recovery path that doesn't need to understand what went wrong first.

The cost of getting it wrong is also very lopsided. If the reboot fires when it didn't need to, you lose a few seconds on a device that was already unreachable for 15 minutes. If the device wedges and never reboots, someone has to physically power cycle hardware that might be in a ceiling, at a remote site, or in a relative's house. I'd much rather the default favor the failure that fixes itself.

Your scenario 3 is actually where the safety net matters most. An SSID that's visible but never finishes associating is a classic sign of wedged radio state on the client side. A reconnect loop will spin on that forever. A reboot clears it in seconds.

That said, the timeout isn't right for every setup, and that's fine. If you know your broker goes down for long stretches or you just don't want the behavior, set reboot_timeout: 0s and it's gone. But that's a choice someone should make knowingly. The default has to protect the user who doesn't know the option exists and whose only other fix is a ladder.

[bilogic]

I can understand all your points, but I also think the single default is dragging everyone down together because of the weakest link, user who doesn't know much.

I'm not sure if you have faced it, but when I'm dealing with the network/server issues and esphome turns off my lights and ventilation every 15 minutes, how am I supposed to reconfigure the esphome at that point? And I'm quite certain we can do better than to use restore_mode.

Do you think we can work on a 2nd set of official defaults that assumes the hardware is solid?

Official because it is hard for anyone to help each other if we all have to piece together our own "better" behaved esphome

as for the pings, I found a few liner that connects to a defined IP and port, I hope there really isn't a software issue where device wedges and can connect to IP A but not IP B