Shelly BLU Door Window devices do not show the correct state (some state changes are missed)

[JBecker32]

The problem

Same problem again (reported on May 2nd (#116597, not sure how to 'activate' that issue again ...).

Using a (bluetooth) Shelly BLU door/window sensor, it takes between 8-15 seconds (on another system up to 30!) before a second state change can be registered. If it comes earlier, it is lost forever. The Shelly device itself works correctly, as a state change is shown immediately in the Shelly BLE debug app. That is really annoying as the state of a door or window which is opened for a shorter time is never correct. Open the door when you come home, state changes to 'open', close again within 8 seconds and the state stays 'open' forever.

This problem was existant (in my case!) with core-2024.5.0 and disappeared with core-2024.5.1. Now it is existant again with core-2024.6.3.

What version of Home Assistant Core has the issue?

core-2024.6.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

BThome

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @ernst79, mind taking a look at this issue as it has been labeled with an integration (bthome) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `bthome` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign bthome` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

bthome documentation bthome source _{^{(message by IssueLinks)}}

[JBecker32]

New information: after installation of an external (USB) BT adapter (Manufacturer: Actions, Vendor-ID: 10d7, Product-ID: b012) and deactivation of the internal BT adapter (Manufacturer: Realtek, Vendor-ID: 0bda, Produkt-ID: c821), reactions to state changes are immediate again! So, this modification kind of solved the problem for me for now. It is still strange that different HA core versions seem to have a big influence on the latency of BT messages.

[Ernst79]

This seems to be just bad reception of the internal BT transceiver. I’m not sure what changed in HA core, but if something changed that affects the reception, you should label this issue as an issue with the Bluetooth integration. But in my honest opinion, it’s often just the hardware. Internal BT isn’t as good as external BT

[home-assistant[bot]]

Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (bluetooth) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `bluetooth` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign bluetooth` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

bluetooth documentation bluetooth source _{^{(message by IssueLinks)}}

[JBecker32]

This seems to be just bad reception of the internal BT transceiver.

Yes, could be true. But, how can 'bad reception' cause a nearly fixed 10s delay? And, this delay is completely independent of distance. I see the exact same 10s delay in 10cm distance as in 10 meters! Very strange! And last time the issue (constant ~30s delay) was completely solved with a new core version???

[Ernst79]

I don't know what caused the issue. Sometimes, a full system reboot helps (power down power up). In that case, something in the FW/SW gets stuck, and the only solution is a full sytem reboot. This is often after an update (although especially FW updates in Home Assistant OS).

[JBecker32]

Thanks for the hint. But I have done this several times. And even tried three different mini-pcs (same BT chip afaik) with exactly the same result.

[airman84]

I am having the same issue with 2024.6.0, but already with earlier version. When the BLU Door Window device got opened, it showed instantly in HA with same timestamp as in the Shelly Smart App. I closed the door 1 minute later, but this time it took 15mins to get the change into HA. In the Shelly Smart App this was shown instantly. This happens often to me and always the opening works fine, while the closing is delayed for approximately 15mins. Any ideas maybe?

[JBecker32]

I am having the same issue with 2024.6.0, but already with earlier version. When the BLU Door Window device got opened, it showed instantly in HA with same timestamp as in the Shelly Smart App. I closed the door 1 minute later, but this time it took 15mins to get the change into HA. In the Shelly Smart App this was shown instantly. This happens often to me and always the opening works fine, while the closing is delayed for approximately 15mins. Any ideas maybe?

As I wrote above, for me it helped to install an external BT USB dongle. Or if you have that already, maybe try one from another manufacturer/with a different chipset?

[JBecker32]

I am a bit afraid that even as it works for me now, this might change again with a new core version (as it did last time!). As long as the real reason for this behaviour is not clearly found and fixed, there will be a bad feeling to use these BT devices ...

[besoiu]

I kind of figured it out... Bluetooth integration and Shelly gen 2 has issues with USB adapters. I have a TP-Link UB500 with which it did not work, both directly in the USB port and also with an extension cable with 10 cm from the sensor, but the dongle is only Bluetooth version 5.0. I gave up the Bluetooth dongle and activated the Bluetooth Gateway from another device I own, a Shelly Plus 2PM, and then for this device in HomeAssistant - Shelly Integration - Configure, I activated Passive mode. I also activated the Bluetooth gateway in the Shelly Web Interface (by entering its IP in the Address field of a browser). After pressing the button on the automatic door/window sensor, a new device appeared in HA which I added, it was put in BTHome integration. Now it works instantly, it updates the window status immediately... All the best!

[bdraco]

If you have a non-high performance adapter in the mix of bluetooth adapters, its expected that it will drop data.

The following requirements must be met for an adapter to be labeled as High Performance:

Establish a connection in about 1s or less Process at least one advertisement per second from a device without dropping data 95% of connection attempts are successful within two tries Meets the above requirements with Home Assistant Core 2022.11.1 or later and Home Assistant Operating System 9.3 or later Must be able to hold five (5) connections at the same time

The UB500 is an RTL adapter which has this note in the docs:

Known working adapters list adapters that do not meet high-performance requirements but will generally work. These adapters vary widely in performance and may take as long as thirty seconds or more to establish a connection. These adapters may also miss advertisements such as button presses or temperature updates.

[airman84]

For me the issue resolved by disabling the internal bluetooth adapter of my raspi4b+ and only keeping the shelly gen2 devices as bluetooth proxy. works fine now!