ESPHome devices showing an old last advertisement but still online?

[lnlyssg]

Not sure when this started but I've recently noticed that some of my ESPHome devices are in Bermuda with old last advertisement times even though the devices are still up and running OK. Here's one example from today:

A quick reboot gets it back into Bermuda but I'm struggling to work out why Bermuda is losing the connection when the device is up and running.

[agittins]

Bermuda doesn't connect to the proxies, it only works with the data that HA gathers from it. It could be something in Bermuda, but it's also quite likely that the device has stopped reporting bluetooth data, even though the device is otherwise still up and running. You can look in the Bluetooth integration, and see if that proxy is still reporting advertisements using the "Advertisement monitor".

If you still see adverts in the Bluetooth integration, but Bermuda is showing the device as not having reported in lately, can you take a "Download Diagnostics" from within Bermuda, and include a screenshot of the status screen showing the skull-and-crossbones as well so I can match things up. You'll need to do all this at a time that the proxy is in that state, of course - so it might take a bit of time before you'll have the chance to grab that data.

If the advertisement monitor doesn't show any recent adverts, then the proxy has probably stopped sending updates to HA. This can happen if it runs out of "slots" for bluetooth tasks, which can be caused by other integrations holding those slots for talking to other devices (like window blinds etc) which prevents esphome from being able to perform scans. Or it could be something going wrong along the path, within esphome, or the wifi network, or HA itself.

[lnlyssg]

Thanks for the pointers. It looks like it's the second case where the proxy has stopped sending updates even though it all seems to be up and running OK based on the logs. I think I'll just have to wait for #363 to get resolved.

[tbrasser]

This could be the actual reason for my ble presence sensors to be flakey!!! Following this thread!

[agittins]

If the bluetooth advertisement monitor does not show any recent adverts, I'd suggest:

Update esphome

• Update esphome on the proxy, almost certainly to whatever is newest (eg at time of writing, the last few releases have had significant performance and memory improvements - all of which benefit BLE proxying either directly or indirectly). These improvements have been coming out in both major and minor releases recently (Feb 2026) so it's well worth updating frequently at this time, particularly if having stability issues.

Check the connection slots

Settings -> Devices and Services -> Bluetooth -> Click-a-Cog

• In the Bluetooth integration after clicking the cog, it lists all the proxies, then the advertisement and connection monitor buttons. In that list of proxies, it shows you under each how many "slots" it has, and how many are used. If a proxy has no free slots it won't be able to proxy advertisements (as I understand it). If you note that the slots are full, you can click the "Connection Slot Allocations Monitor"(!) at the bottom of that page and it will show you which devices are using each connection. You might find that:
  • A faulty integration might not free up slots, and will hold multiple connections to the same device (not entirely sure if this is possible)
  • An integration might keep a constant connection open to every device it monitors, rather than making temporary connections. This might be due to some design constraints around the device, or maybe its a bug or maybe it's just a possibility that the integration author hadn't considered to be a potential issue.
  • You might have more devices that need open connections that you have available slots on the proxy.
• If the slots are being used up by other integrations...
  • You could see if the integration can be configured to not do that, or if it might be a bug
  • You could "reserve" certain proxies to be dedicated to just receiving advertisements and not doing outbound connections. You do this by setting active: false in the bluetooth_proxy section of the esphome config. Note that this is separate and different to the active property in the esp32_ble_tracker section, which is about scanning, not proxying. Actually, it might be better to think of this as reserving some proxies as "active proxies" where you need them, and leaving all your other proxies that used for Bermuda and passive things like BTHome to be configured with active: false in the bluetooth_proxy section.
• The TL/DR; for connection slots is throw more proxies at the problem (and dedicate some proxies to active proxying, leaving the rest to passive listening for adverts)

Check esphome yaml

bespoke configuration dot yaml files!

• Check that your esphome yaml looks good. Ideally, follow the config instructions in the wiki, but particularly...
  • Use the esp-idf platform, not the arduino platform. This is now the default, but you might have an explicit setting in there
  • (probably still relevant): don't have your window and interval settings the same, leave maybe 20ms of space for other stuff to happen. This may no longer be necessary, but might help.
  • the suggestions in the wiki include an automation to put in the api: block - I think this is a great idea to keep, as it should lighten the load a bit when the device is reconnecting, and might avoid any potential race conditions. With all the work on improving quality that esphome has been doing this might no longer be required, but I don't think it can hurt.

Check your WiFi

• The HA logs will show events from the esphome integration if proxies are regularly dropping their wifi connection.
• If the wifi signal strength is poor (-70dbm to -80dbm seems to be fairly ok, but in the -90s is definitely not good) then you can expect disconnections and drop-outs. Look at improving your wifi network (channel selection, more APs, better positioning of existing APs etc). Also make sure you updated esphome recently - 2026.1 includes important wifi latency fixes, and smarter wifi roaming / AP selection, among other things.
• Pinging your proxies (ie, ping prox-bedroom from a terminal) should result in 0% packet loss, and round-trip response times of 2ms to 200ms or so, depending on how busy it is, what chipset etc. (press Ctrl-C to stop the ping process after you've got a decent sampling, then it will show you the stats).

[agittins]

What's the situation with the advertisement monitor? Are there any log messages about esphome or blueooth?

Re wifi pings, packet loss is more important than response time, but at 6ms it's unlikely you're missing many.

You could try enabling debug logging on the esphome integration - it's quite the firehose though, 6 seconds of debug on my system gives me a 16MB file! It will show you every advertisement packet coming from every proxy, so you could confirm if the esphome is actually sending it back to HA or not.

That said, it looks like it's an issue with the proxy itself and it not shipping data back to HA, so I'd probably look there first. How often does it (or they?) go offline? Happy to take a look at your full yaml.

[lnlyssg]

No errors or messages in the logs at all. They seem to go offline almost randomly with no rhyme or reason - it could be days in-between issues or sometimes hours. Below is the YAML that I'm using for most of them:

esphome:
  name: esphome-web-back-door
  friendly_name: ESPHome Web Back Door
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxxxxxx"

ota:
  - platform: esphome
    password: "xxxxxxx"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-Back-Door"
    password: "xxxxxxx"

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    active: True
    interval: 320ms
    window:   300ms

bluetooth_proxy:
  active: true

button:
  - platform: safe_mode
    id: button_safe_mode
    name: Safe Mode Boot

  - platform: factory_reset
    id: factory_reset_btn
    name: Factory reset

  - platform: restart
    id: restart_btn
    name: Restart

binary_sensor:
  - platform: status
    name: "Back Door esphome Status"

sensor:
  - platform: uptime
    type: seconds
    name: Uptime Sensor

[lnlyssg]

Tried with the updated api: section with on_client_connected: earlier today but just had one device go dead again.

[agittins]

Bummer.

Assuming that the issue is not hiding in the network or HA itself, it looks a lot like you have an issue with either the hardware or with esphome itself.

Ahh... just found this issue in esphome's tracker esphome/esphome#13560

It looks like pinning esp-idf to version 5.5.1 might be a suitable work-around.

Given that the issue documented there (which looks very much like what you're facing) is upstream with Espressif's sdk, there needs to be an issue raised with espressif from someone who can reliably reproduce the problem - I'd encourage anyone encountering this to subscribe to the issue and also to raise it with Espressif so a fix can be made.

In the meantime, this snippet seems to be working for a lot of folk:

esp32:
  framework:
    type: esp-idf
    version: 5.5.1

[lnlyssg]

ESPHome 2026.3 has the fixed ESP-IDF 5.5.3 - https://www.esphome.io/changelog/2026.3.0/#memory-and-flash-optimizations