Log message "Advert from [scanner-name] for [device-name] lacks stamp, unexpected"

[agittins]

I've seeing these errors:

Logger: custom_components.bermuda
Source: custom_components/bermuda/bermuda_advert.py:136
integration: Bermuda BLE Trilateration (documentation, issues)
First occurred: 10:42:40 AM (126806 occurrences)
Last logged: 3:55:54 PM

Advert from Apollo MSR-2 BR for HB-00131167 lacks stamp, unexpected.
Advert from Apollo MSR-2 BR for Aranet4 19AB1 lacks stamp, unexpected.
Advert from Apollo MSR-2 BR for Sab82093de6fe23fcC lacks stamp, unexpected.
Advert from Apollo MSR-2 BR for Aranet4 0B281 lacks stamp, unexpected.
Advert from Apollo MSR-2 BR for iO Sense lacks stamp, unexpected.

Edit: I believe these started after I updated ESPHome, not after I updated to Bermuda 0.8.2.

Originally posted by @drothenberger in #580

[RDADevelopment]

I cannot reproduce this issue with 0.8.3.

Yesterday, I turned off the BT support on this "Apollo MSR-2 BR" device due to all the logging. Today, I updated to 0.8.3 and turned on the BT support again on this device, but the logs have not appeared again.

Weirdly, the errors appeared for only this one device. I have another Apollo MSR-2 device with BT enabled and that device did not produce the same errors, even though it has the same ESPHome configuration as the BR device.

[drothenberger]

Sorry, I was logged in with the wrong account. The comment from RDADevelopment above is actually from me.

[agittins]

Wow, that is weird! My only guess is that maybe something happened between updates with the esphome api between the device and HA - there's a few layers there, and it's an active area of changes. It's usually pretty solid but perhaps for a brief instant you hit some magical combination of versions or something.

From Bermuda's view, it expects to see timestamps recorded by anything that implements the BaseHaRemoteScanner interface, which includes esphome and Shelly, but expects to not see it from local scanners like usb adaptors or other things using the BlueZ interface.

Maybe this was just a transient thing - I'll close it off but feel free to re-open if it crops up again!

[drothenberger]

I see this has been reopened. I have experienced this a few times since I posted. Each time it has reported different proxies having the problem.

Each time, restarting Home Assistant solved the issue.

I'll try to collect some diagnostics the next time it happens.

[agittins]

I see this has been reopened. I have experienced this a few times since I posted. Each time it has reported different proxies having the problem.

Yes, Eric reported the same problem in #593 so I'm re-opening this one as the original issue. BTW, Eric found that just reloading Bermuda also cleared the issue (rather than a full HA restart), which may be a less disruptive way to (temporarily) clear the issue.

I suspect that Bermuda is using a stale copy of the hascanner object or something similar (maybe when a proxy reconnects or something else happens to re-initialise the internals of the backend), so hopefully a fix will not be long in coming.

[erkr]

In my case I have 6 identical (HW and SW) proxies, where one triggers this issue. I can only see that particular proxy lives in a weak WiFi area reconnection now and then:

Logger: aioesphomeapi.connection
Source: runner.py:154
First occurred: May 26, 2025 at 22:59:53 (3 occurrences)
Last logged: May 26, 2025 at 23:08:53

bluetooth-proxy-d00904 @ 192.168.178.41: Connection error occurred: [Errno 104] Connection reset by peer

[agittins]

@erkr do you know if your diagnostics were generated at a time that these log messages were still being emitted?

This error originated from a custom integration.

Logger: custom_components.bermuda
Source: custom_components/bermuda/bermuda_advert.py:136
integration: Bermuda BLE Trilateration (documentation, issues)
First occurred: 11:40:14 (23011 occurrences)
Last logged: 14:45:08

Advert from BT-Proxy-4 d00904 for bermuda_64_16_66_36_8b_fa lacks stamp, unexpected.
Advert from BT-Proxy-4 d00904 for samsung_electronics_co_ltd_38_68_a4_28_a3_1b lacks stamp, unexpected.
Advert from BT-Proxy-4 d00904 for samsung_electronics_co_ltd_00_7c_2d_e9_d3_47 lacks stamp, unexpected.
Advert from BT-Proxy-4 d00904 for samsung_electronics_co_ltd_50_fd_d5_e8_0b_4b lacks stamp, unexpected.
Advert from BT-Proxy-4 d00904 for samsung_electronics_co_ltd_a4_30_7a_e2_33_7d lacks stamp, unexpected.

[erkr]

I collected them afterwards

[agittins]

I've looked through the code and I think it's doing things correctly, and it will always grab a fresh stamps dict on each update.

Given your experience, @erkr I suspect that what's happening is that sometimes (typically, when a scanner restarts, or maybe when its scanning is restarted) it's entirely valid to have previously seen an advert from that scanner, but for the backend to now have no memory of it having happened, and thus no stamps for it.

I think this might be particularly relevant if the scanner in question is currently too far away to hear those adverts. Note that a scanner might restart its proxy duties at any time, not just a scanner reboot.

I haven't been able to reproduce this, but I suspect I can probably reduce the log message to debug only, as I think there might be valid cases where this can occur.

@ all, does it sound reasonable that this might be happening in cases where the proxy:

• used to be able to see the device in question
• restarted (either in full or just reloaded its proxy tasks)
• can no longer see the device in question

If this is the case, I'd also expect the log messages to stop if the device comes back into range of that scanner.

If either of you could verify that I can fairly easily just back off the logging level - but I am hesitant in case Bermuda is truly missing the presence of adverts due to some weird corner-case.

A diagnostics at the time that the log messages are being emitted will help verify things, as would knowing if moving the stamp-lacking-device close to the proxy stops the logs from happening.

[erkr]

I changed the log level back and will persist diagnostics while it happens.