ESP32 devices go offline after a few min

[TobiasPSP]

The problem

I cannot access ESPHome devices from the esphome dashboard a few minutes after they booted. They start normal, then regularly go "offline" and only come back after a hard reset. At any time, the devices continue to talk to HA and also continue to do their intended work, so this part is not affected and works as expected. It is just esphome dashboard that suddenly starts to not see the devices anymore when they have been running for a few minutes.

To illustrate the case, here a practical example:

I have a simple esphome toggle button device based on esp32 devkitc4. When I boot it, all works well. After a few min, it turns "offline" in esphome dashboard and can no longer install updates or view logs. In Home Assistant, when I go to "Developer" and examine the push button state, whenever I press the button, the state immediately changes as expected. To regain access to the device from esphome dashboard, I need to press the reset button on the board. Then again I have a few minutes where the device is online before it automatically goes offline again - while still happily providing its services to HA.

Identical behavior with a completely different SCD30 CO2 sensor.

I tried adding "power_save_mode: none" which made no difference.

I am puzzled: If WiFi is up, and if HA and the device can talk any time, and if ESPHome Dashboard can talk (initially), what is changing after a few minutes? Is this a new energy savings mode possibly? Everything used to work until yesterday when I updated to the latest esphome version. Unfortunately, I changed a lot of other things yesterday too so I can't say for sure.

If there is anything you want me to test or share, please let me know.

Which version of ESPHome has the issue?

2024.7.1

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2024.7.3

What platform are you using?

ESP32

Board

ESP32-DevKitCV4

Component causing the issue

any, in this case a simple push button

Example YAML snippet

binary_sensor:
  - platform: gpio
    name: Pushbutton1
    pin: 
        number: GPIO4
        inverted: true
        mode:
          input: true
          pullup: true
    filters: 
      - delayed_on: 10ms
      - delayed_off: 10ms

Anything in the logs that might be useful for us?

This is what I get when trying to view the log from esphome dashboard:
`
INFO Starting log output from push-button.local using esphome API
WARNING Can't connect to ESPHome API for push-button.local: Error resolving IP address: [Errno -5] No address associated with hostname (APIConnectionError)
INFO Trying to connect to push-button.local in the background

At this very time, the device is fully operational from "home assistant" perspective, and when I press the device push button, the HA developer tools immediately show the state change. Yet, for esphome dashboard, the device has vanished.

### Additional information

_No response_

[TobiasPSP]

I found that HA apparently uses a device IP which I can ping successfully. However, the mDNS name seems to be available only for a few minutes after device boot. Does that indicate a network config issue, or is publishing its mDNS name something the ESP32 actively controls, and may fail to do so after a couple of mins? My current assumption was that mDNS either works or fails, and fails most often when using different subnets, so I figured when mDNS initially works, the network config is alright. Is that assumption not true maybe?

[Statusbit]

logs_nspwohnzimmer_run.txt Same Problem ... Logfile after reboot over wifi (home assistant integration). After 10 minutes esphome offline, but still working.

[epiech]

I am seeing the same thing after I updated to ESPHome 2024.8.3. Have you had any success resolving this?

INFO ESPHome 2024.8.3 INFO Reading configuration /config/esphome/salt-level-sensor.yaml... INFO Detected timezone 'America/New_York' INFO Starting log output from salt-level-sensor.local using esphome API WARNING Can't connect to ESPHome API for salt-level-sensor.local: Error resolving IP address: [Errno -5] No address associated with hostname (APIConnectionError) INFO Trying to connect to salt-level-sensor.local in the background

[TobiasPSP]

I was hoping to get back an authoritative answer from the ESPHome team. Apparently they are currently busy. I

still see the behavior. Currently, I am resorting to resetting devices when I need to manage them via esphome. That’s unfortunately not possible for all device (some are inaccessible), so I‘d love to hear back from the esphome team what the recommendations are.

[Hiekkaharju]

Sorry, not the ESPhome team, but: Same used to happen to some of my nodes, long before 2024.7.1. My suggested solution is : use manual IP. The nodes may still show as offline in ESPHome, but e.g. wireless logging and fw updates will work. You might find that also some other things are improved. The mDNS problem may be related to the network. Then after initial TTL, mDNS won't resolve. It appears that at least some (mesh) networks do not by default route multicast IP, like mDNS, even within LAN. E.g. ASUS routers have a Web GUI setting LAN - IPTV - "Enable multicast routing" which is by default disabled.

[Statusbit]

Thank you for your solution.

I use fixed IP for everything. FritzBox, NS panel and HomeAssistant all show the correct IP. Only esphome has a problem with this.

[Hiekkaharju]

Thank you for your solution.

I use fixed IP for everything. FritzBox, NS panel and HomeAssistant all show the correct IP. Only esphome has a problem with this.

"Fixed IP" done in any other way than specifying manual_ip in Esphome yaml won't help with this issue.

[randybb]

I have 70 devices in my network and only 4 have a static address (router, HA, unifi controller and one of my servers). Everything works fine with mDNS inluding switches and AP's, even nspanel's running esphome are using mDNS name for MQTT. All esphome devices are in a separate VLAN with mDNS forwarding between all VLANs and no issues.

So the issue will be in your network.