Bluetooth adapter showing on Yellow with CM4 without Bluetooth (OS 11.2.rc1)

[agners]

trafficstars

I'm not sure why, but as of OS 11.2.rc1 I have a bluetooth adapter showing up. Could be related to supervisor but I don't notice any changes related to that. It discovers hci0 but never inits on my HA Yellow (as my CM4 does not have wireless). I don't have a big understanding of how the OS works but I assume it might be related to #2931 by @sairon.

Host logs:

Nov 23 21:35:19 homeassistant kernel: Bluetooth: hci0: command 0xfc18 tx timeout
Nov 23 21:35:27 homeassistant kernel: Bluetooth: hci0: BCM: failed to write update baudrate (-110)
Nov 23 21:35:27 homeassistant kernel: Bluetooth: hci0: Failed to set baudrate
Nov 23 21:35:29 homeassistant kernel: Bluetooth: hci0: command 0x0c03 tx timeout
Nov 23 21:35:37 homeassistant kernel: Bluetooth: hci0: BCM: Reset failed (-110)
...

Core:

Logger: bluetooth_auto_recovery.recover
Source: runner.py:188
First occurred: 22:35:37 (5 occurrences)
Last logged: 22:38:24

Bluetooth management socket connection lost: [Errno 22] Invalid argument

Logger: bluetooth_auto_recovery.recover
Source: components/bluetooth/util.py:78
First occurred: 22:35:16 (21 occurrences)
Last logged: 22:38:40

Could not determine the power state of the Bluetooth adapter hci0 [00:00:00:00:00:00] due to timeout after 5 seconds
Could not cycle the Bluetooth adapter hci0 [00:00:00:00:00:00]: [Errno 110] Operation timed out
Bluetooth adapter hci0 [00:00:00:00:00:00] could not be reset:
Closing Bluetooth adapter hci0 [00:00:00:00:00:00] failed: [Errno 9] Bad file descriptor

Originally posted by @tjorim in https://github.com/home-assistant/operating-system/discussions/2940#discussioncomment-7655278

[agners]

I can reproduce this problem on my end. It seems that the kernel Bluetooth initialization creates an hci0 device in any case. I am not sure if we can prevent that though :thinking:

The Bluetooth daemon seems to correctly detect that there is no controller:

[bluetooth]# show 
No default controller available

To me it seems that the Core makes the assumption when there is a hci0 device that there is a Bluetooth controller behind it? We'll need to check what Raspberry Pi OS is doing in this situation, but I don't think they have something their code which disables the in-kernel/device-tree Bluetooth/HCI interface based on WiFi/Bluetooth chip availability :thinking:

/cc @bdraco

[agners]

For completeness, Yellow hciconfig reports this:

# hciconfig
hci0:   Type: Primary  Bus: UART
        BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
        DOWN
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:28 acl:0 sco:0 commands:4 errors:0

And that seems to be the case on Yellow as well:

pi@rpioscm4:~ $ hciconfig
hci0:   Type: Primary  Bus: UART
        BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
        DOWN 
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:14 acl:0 sco:0 commands:2 errors:0

[bdraco]

This is what I get if the CM4 has BLE.

Can someone post what shows up when it doesn't?

# docker exec -it homeassistant /bin/bash
homeassistant:/config# python3
Python 3.11.6 (main, Oct 22 2023, 22:02:45) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from bluetooth_adapters import get_adapters
>>> adapters = get_adapters()
>>> import asyncio
>>> asyncio.run(adapters.refresh())
>>> adapters.adapters
{'hci0': {'address': 'E4:5F:01:D0:EA:29', 'sw_version': 'homeassistant', 'hw_version': 'usb:v1D6Bp0246d0546', 'passive_scan': True, 'manufacturer': 'Raspberry Pi Trading Ltd', 'product': None, 'vendor_id': None, 'product_id': None}}

[tjorim]

Sorry for the screenshot but I seem to have some issues copying from the web terminal:

[bdraco]

Thanks. I think the simple solution might be to ignore 00:00.... on Linux

[sairon]

This should be resolved with #2948, no other fix/workaround should be needed, at least on RPi with HAOS. But it's worth noting it's still present on RPi OS (see the linked issue above).

[agners]

IMHO, #2948 is really a work around. It could even be problematic in cases a external connected Bluetooth adapter is used :cold_sweat: I guess the typical use case is a USB attached Bluetooth adapter, which I think should not be affected by removing the hci_uart driver. But this is a hack still.

So ideally, we should have Home Assistant Core check the state of the hci interface or similar before trying to use it. hciconfig reports DOWN, can this maybe used? On the other hand, we still might consider an interface which is temporary down :thinking: I'd say a MAC address of all zeros is a good indication that the Bluetooth adapter is unusable at this point, so ignoring such an interface seems reasonable to me :+1:

Once Core is able to deal with that device, or we/Raspberry Pi folks find a nicer way how to disable the Bluetooth interface when using krnbt on CM4's without a WiFi/Bluetooth module, we should get rid of the work around introduced in #2948. Until then, I'd like to keep this open as a reminder to get this properly fixed.

[agners]

@bdraco so there is another case where an hci device shows up with 00:00:00:00:00:00: Systems running HAOS with a newer Intel WiFi/Bluetooth adapter.

[bdraco]

So the idea is to ignore adapters with 00:00:00:00:00:00 on Linux only (on macos we want to accept them because they all show as 00:00:00:00:00:00 because of Apple's privacy features)

[mathieucarbou]

Hello, I upgraded to the latest HA OS / Suverviser / Core yesterday night and this morning a bluetooth adapter (hci0 - not hci`` with address 00:00:00:00:00:00) was wrongly discovered on my Home Assistant Yellow. And of course the integration was failing to start and cycle the adapter because there is no bluetooth on HA Yellow.

Core
2024.3.1
Supervisor
2024.03.0
Operating System
12.1
Interface utilisateur
20240307.0

So I guess that something has changed in the latest version ?

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.