All devices offline after 2024.5.1

[Kebo2r]

The problem

All my devices are offline after 2024.5.1. A couple when trying to update reference current version too old for version 3000.....I'm still new but lost on where to go for more diagnostics or troubleshooting

Which version of ESPHome has the issue?

2024.5.1

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2024.5.4

What platform are you using?

ESP8266

Board

Mostly Kauf but also Wyze

Component causing the issue

Kauf and Wyze

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[difful]

same problem

All my devices are offline after 2024.5.1

Which version of ESPHome has the issue? 2024.5.1

What type of installation are you using? Home Assistant os

Which version of Home Assistant has the issue? 2024.5.4

What platform are you using? ESP32

Board esp32 d1 mini esp32 S2 mini

Example YAML snippet No response

Anything in the logs that might be useful for us? No response

Additional information when i try to get logs : INFO Reading configuration /config/esphome/aquarium.yaml... INFO Starting log output from esp-aquarium.local using esphome API WARNING Can't connect to ESPHome API for esp-aquarium.local: Error resolving IP address: [Errno -5] No address associated with hostname (APIConnectionError) INFO Trying to connect to esp-aquarium.local in the background

i have restored my esphome save 2024.5.0 and all my device are up

[Kebo2r]

I can't even open the webUI of my devices now (Kauf Bulbs). How did you revert to previous?

[difful]

you can revert to previous in setting/system/backup/ for me the backup is named addon_xxxx_esphome_2024.5.0

[jpettitt]

The binary size for my athom presence sensors jumped from 612k to 660k withe the 5.1 release, this seems to be the cause of the failing menus etc I'm seeing and the inability to push further updates.

[bdleung]

The binary size for my athom presence sensors jumped from 612k to 660k withe the 5.1 release, this seems to be the cause of the failing menus etc I'm seeing and the inability to push further updates.

This happened for my athom presence sensors - I was able to flash directly via USB FWIW. Binaries are still too large to OTA from 5.2. I found that the included USB-C cable does not carry data to be able to flash so I had to swap the cable to flash directly.

Athom told me that the devices have 2M flash size however mine's only detecting as 1M.

[pgale]

All of my Athom presence sensors are now offline after failed updates too. (not enough space). Really annoyed if I have to go around the house and remove every sensor to flash with USB (if that even works).

[jens-markussen]

I have the same problem.. ALL ESPHOME devices offline and not able to connect. Not sure I'll be able to downgrade.... how to do that?

[pgale]

I restored ESPHome 2024.4.x and restarted/reflashed my devices and that worked ok. Might need to power cycle the devices though if they're not responding. What a mess.

[jens-markussen]

It is very, very strange. ESPHome tab in HA is reporting all ESPHome devices as offline. However, they seem to be reporting data and able to perform functions never-the-less.

When you press "log", it will start by stating that the IP address cannot be resolved. After some time, typically, it will connect anyway and display the log.

Doing a ping to the address works right off the bat.... very, very strange.

Most offline:

Asking for log for one of them (works immediately in this case, in the previous invocation, it was unable to initially resolve the IP):

Ping to same from Windows PC is just fine:

Very, very strange..

[pgale]

You're right - I saw the same with some of my devices. Some not responsive at all but some with the symptoms you describe.

[jens-markussen]

Hmm. Maybe the problems are related to resolving hostnames named as <hostname>.local. While ping works, nslookup does not. Reading https://community.home-assistant.io/t/change-local-domain/281135, I've tried adding domain setting under wifi section in the ESPHome Yaml files and this seems to cure things - see below.

Not sure why this is popping up right now...

Everything ok again after adding domain: (note some devices still offline because they actually are - test devices and stuff)

[Kebo2r]

Would that explain trying to manually navigate to the up address?Sent from my iPhoneOn May 21, 2024, at 14:08, Jens Vedel Markussen @.***> wrote: Hmm. Maybe the problems are related to resolving hostnames named as .local. While ping works, nslookup does not. Reading https://community.home-assistant.io/t/change-local-domain/281135, I've tried adding domain setting under wifi section in the ESPHome Yaml files and this seems to cure things - see below. Not sure why this is popping up right now... Everything ok again after adding domain: (note some devices still offline because they actually are - test devices and stuff) image.png (view on web)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[jcd420]

esp32 work, esp8266 does not for me

[jens-markussen]

Hmm. After about an hour, some of the devices are again reported as offline, even with domain set.

The are NOT offline. Pressing Logs correctly shows the logs. Also, they continue to perform their function ....

Hmm

[jens-markussen]

Just noting that this happens as well with 2025.5.2., devices, while in reality online show status offline in ESPHome tab

[jens-markussen]

Ok, maybe this is related to something else. I've now found https://community.home-assistant.io/t/offline-esphome-devices/543534/16 and studied https://esphome.io/guides/faq.html further. This suggest to change the method for detecting whether an ESPHome device in online from mDNS to ICMP/ping. There is a nice GUI option for this in the ESPHome add-on (aftern clicking "show all options" or similar)....

Sorry for any confusion caused. It just so happened that all this started with 2024.5.1 (and persisted in 2024.5.2). Whether it is at all related ..... not really sure

So, in conclusion. All good again (changing to ICMP/ping option)

[fir3drag0n]

Same problem here with docker config esp home, device are online, but seem to be offline in the dashboard

[shin10]

I had this problem for a while and just came back to it today:

• A lookup with avahi-resolve succeeds and anything else avahi in my container seems to be working correctly (browse, publish) .
• mDNS is correctly resolved when uploading or opening the logs.

The online status returned by https://esphome.[mydomain]/ping however, will always return a value of null (not false!) for all listed *.yaml keys in the json.

ESPHOME_DASHBOARD_USE_PING=true isn't working as expected. /etc/avahi/hosts doesn't resolve the issue either.

I'm experiencing this for way longer than others here. I'm running esphome in a docker container (and behind traefik).

I tested a lot of containers right now and the last working version is 2023.12.9. The issue comes up with 2024.2.0. Note: I did not test the January dev builds.

Dockerfile:

#FROM esphome/esphome:2023.12.9 # last version with correct online status
FROM esphome/esphome:latest

RUN set -ex \
 && apt-get update && apt-get install -y avahi-utils

docker-compose.yaml:

services:
  esphome:
    image: esphome--mdns-mod:latest
    build: .
    container_name: esphome-mod
    volumes:
      - ./.docker/esphome/config:/config
      - /etc/localtime:/etc/localtime:ro
      # mDNS
      - /var/run/dbus:/var/run/dbus:ro
      - /var/run/avahi-daemon/socket:/var/run/avahi-daemon/socket
    restart: unless-stopped

    environment:
      - ESPHOME_DASHBOARD_USE_PING=true
    networks:
      - esphome_net

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=${NETWORK}"

      - "traefik.http.routers.esphome-http.rule=Host(`esphome.${HOST}`)"
      - "traefik.http.routers.esphome-http.entrypoints=web"
      - "traefik.http.middlewares.https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.esphome-http.middlewares=https-redirect@docker"

      - "traefik.http.routers.esphome-https.rule=Host(`esphome.${HOST}`)"
      - "traefik.http.routers.esphome-https.entrypoints=websecure"
      - "traefik.http.routers.esphome-https.tls=true"
      - "traefik.http.middlewares.test-auth.basicauth.usersfile=/configuration/usersfile"
      - "traefik.http.routers.esphome-https.middlewares=test-auth@docker"
      - "traefik.http.routers.esphome-https.service=esphome-https-service"
      - "traefik.http.services.esphome-https-service.loadbalancer.server.port=6052"

networks:
  esphome_net:
    external: true
    name: ${NETWORK}

[redstorm1]

I have been suffering from the same issue for a while now also. I took a look today and found that the debian server hosting my HA Supervised install is able to resovle the mDNS queries no problem.

avahi-resove -n officehp.local etc

however shelling into the esphome docker container and trying to resovle the same fails. It appears that avahi daemon has been removed from the image for unknown reasons?

[Bert-R]

I have 6 ESP Home devices. If I click "Update all" after an ESP Home update, 4 of them update without issues and 2 of them fail. For the 4 successful ones, I see such log lines:

INFO Resolving IP address of <name>.local

For the 2 failing ones, I see this:

INFO Resolving IP address of <name>
ERROR Error resolving IP address of <name>. Is it connected to WiFi?

The two failing ones are Athom smart plugs, based on this package. Till the last ESP Home update these updated successfully.

It appears that the .local suffix got dropped in the last ESP Home update.

Interestingly, I can still update them, by selecting "Install" from the menu on the device.

[roblatour]

see post by HappilyOffensive at https://community.home-assistant.io/t/esphome-ota-configuration/730032/4

does that help you?

[Bert-R]

@roblatour It's not easy to test, as the problem only shows up when a there is an opportunity for "Update all" (e.g. an update of ESP Home). I have updated it in the clone of the repo that I maintain and let you know the result.

[Bert-R]

@roblatour I have tested it with the update that was released earlier this week: it does not fix it.