Closed Nicxe closed 1 year ago
bluetooth documentation bluetooth source (message by IssueLinks)
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!
(message by CodeOwnersMention)
Looks like the device is actually broadcasting a whole lot of different mac addresses.
It is either a problem with the device itself or the bluetooth adapter or setup on the host system.
I'd try upgrading the kernel and BlueZ on the host system first.
Anything I should do on my system?
Having the same issue. Keeps discovering new Yale Access Bluetooth devices. I have the newest kernel update. Is there something else we can try?
Which bluetooth adapter are you using?
Also a diagnostics file would be helpful.
Using the bluetooth on a intel NUC. I do have a diagnostic but it has some mac addresses so dont want to post it here publicly. So should I send it via DM to you?
If you don't feel comfortable posting them, I'd edit them out as long as you replace them with the same value every time they appear it should still be helpful. I should point out they are already being broadcast publicly though and anybody with a bluetooth adapter that drives by can pick them up.
Good point. Here is the bluetooth diag.
config_entry-bluetooth-b62cd8321d26e0dd956ef628600aa0c5.json.txt
The diagnostics are really interesting as its showing different mac addresses for the device in D-Bus so we are looking at reporting a bug to BlueZ (http://www.bluez.org/)
The "dbus"
field in the diagnostics lists all the devices the bus is aware of.
There are three mac addresses for this lock registered on the bus.
L30E0TY - /org/bluez/hci0/dev_3A_66_CD_FF_15_DB L30E0TY - /org/bluez/hci0/dev_EC_A9_07_29_79_19 L30E0TY - /org/bluez/hci0/dev_78_9C_85_11_32_4D
If you are in a position to capture a wireshark or tcpdump on the bluetooth interface it might help narrow down where the bad data is coming from.
I can't seem to find it but I remember a similar issue with the intel bluetooth drivers and the end result was the bluetooth was disabled in the bios and replaced with an external adapter.
@Nicxe are you using a NUC as well?
Yes I am also using a Nuc
I have a BLE USB dongle laying around here somewhere, I can try to disable the built-in one and try to use that. Will try to do that during the day
However, I updated to 2022.09.01 and that seems to have fixed the issue for me. I don´t know if the update to ble made in that one made a difference or if it´s just temporary in my system. I will wait a couple of hours and see before I try the BLE USB thing.
There isn't any changes in 2022.9.1 that would address this. I think you just got lucky 🍀
Noted that now, it´s back to around 20 discoveries.
I will try to disable the onboard Bluetooth, however, that wasn´t easy. I don't have the option I BIOS where is supposed to be, so I need to look in a little bit more to that
I'm having the same issue. Also using the Yale Access integration on a NUC. I actually have two bluetooth adapters active (the built in one and a USB one), since the built in gave me issues way back and I just haven't gone ahead and disabled the internal one. I'll try that in a while and report back.
However, in the mean time I think we can rule out the lock being faulty or spamming multiple MAC's. It seems to me that the Bluetooth integration scans discover any BT devices in the area and then they are erroneously recognized as Yale Access devices. See the Hue lamp or the Fibaro sensor in my image, for instance.
The match for yale access bluetooth is manufacturer id 465. Are all those devices broadcasting with that id?
I don’t know how to check the manufacturer ID, but I have a hard time believing all those different products use the same ID.
Like for Nicxe, there’s no way for me to disable the built in BT adapter in the NUC bios…
Update on mine. I disabled the Bluetooth/wifi (had to pull the card since I could not disable it in BIOS) and added a usb bluetooth dongle and it seems to have fixed the problem.
So you actually removed the BT hardware from a NUC? I thought it was soldered/hardwired to the MB. Care to point a finger to what to remove in there?
I don’t know how to check the manufacturer ID
Enable debug logging for homeassistant.components.bluetooth
. You'll see all the advertisements. If I had to guess, it looks like bug in the driver were its mixing advertisements together.
I don’t know how to check the manufacturer ID
Enable debug logging for
homeassistant.components.bluetooth
. You'll see all the advertisements. If I had to guess, it looks like bug in the driver were its mixing advertisements together.
Thanks, I’ll do that and report back!
So, here's another one being detected after enabling BT debug logging.
Turns out the there is a 465 nestled in the manufacturer ID:
2022-09-12 15:51:42.095 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] hci0: 64:A9:59:BD:CD:0D AdvertisementData(manufacturer_data={6: b'\x01\t \x02<\x1e\xbd\xe1\x84\xf0\xae\xa4\xb1\xd85\xcf\xcc\xf2g\xcb\xd6\xb7\x0e\xdar\xc6-', 76: b'\x10\x05\x01\x14Q\x9c\xaf', 465: b'\x00'}, service_uuids=['0000fe24-0000-1000-8000-00805f9b34fb']) connectable: True match: {'yalexs_ble'} rssi: -69
EDIT: Now it also added my Apple Pencil (after first seeing it lots and lots of times without the 465 being present):
2022-09-12 16:10:12.690 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] hci0: REDACTED AdvertisementData(local_name='Apple Pencil', manufacturer_data={76: b'\x02\x15\xd13\x8a\xce\x00-D\xaf\x88\xd1\xe5|\x12HIf\x00\x01o\xa7\xc5', 465: b'\x00'}, service_data={'0000fe9f-0000-1000-8000-00805f9b34fb': b'\x029TJ-KT_CwgI\x00\x00\x01\x831\xff\xf1\xdc'}, service_uuids=['0000fe9f-0000-1000-8000-00805f9b34fb', '0000fe24-0000-1000-8000-00805f9b34fb']) connectable: True match: set() rssi: -56
>>> hex(465) '0x1d1'
It sure looks like something is getting confused at the driver level as it shouldn't have 465 in there as it belongs to August Home
>>> hex(465) '0x1d1'
It sure looks like something is getting confused at the driver level as it shouldn't have 465 in there as it belongs to August Home
Yes, I've now gone the slightly less nuclear path of disabling the hci0 BT adapter in HA. That'll probably solve it. Gonna reboot and wait it out.
https://gist.github.com/ariccio/2882a435c79da28ba6035a14c5c65f22#file-bluetoothconstants-ts-L457
It looks like we could also make the matcher a bit more strict and add this service_uuid but its appearing on your apple pencil so it won't solve that
yalexs_ble documentation yalexs_ble source (message by IssueLinks)
https://github.com/hbldh/bleak/blob/aa24332a39952880005705155629df423fbad1aa/bleak/backends/_manufacturers.py#L471
>>> hex(465) '0x1d1'
It sure looks like something is getting confused at the driver level as it shouldn't have 465 in there as it belongs to August HomeYes, I've now gone the slightly less nuclear path of disabling the hci0 BT adapter in HA. That'll probably solve it. Gonna reboot and wait it out.
So, to report back, disabling the internal BT adapter fixed the issue. Thanks for the help and the commit, bdraco!
disabling the internal BT adapter fixed the issue
How did you do that?
disabling the internal BT adapter fixed the issue
How did you do that?
Settings - Devices & Services - Click the three dots corresponding to your device under Bluetooth integration and select Disable.
Settings - Devices & Services - Click the three dots corresponding to your device under Bluetooth integration and select Disable.
Thanks, I didn´t know that disabled the onboard BLE.
Just came here to say that I'm having the same issue, except with Govee BLE sensors. I get discoveries of multiple Govee sensors, however they are different devices like you guys mentioned. So what would be the solution to this? I'm using a chromebox with the internal bluetooth adapter. I noticed @kattkaries disabled the device. Are you using a dongle instead??
Just came here to say that I'm having the same issue, except with Govee BLE sensors. I get discoveries of multiple Govee sensors, however they are different devices like you guys mentioned. So what would be the solution to this? I'm using a chromebox with the internal bluetooth adapter. I noticed @kattkaries disabled the device. Are you using a dongle instead??
That’s right. I’m using a natively supported USB dongle instead. I believe it’s an Asus one. The issue disappeared as per above.
Just came here to say that I'm having the same issue, except with Govee BLE sensors. I get discoveries of multiple Govee sensors, however they are different devices like you guys mentioned. So what would be the solution to this? I'm using a chromebox with the internal bluetooth adapter. I noticed @kattkaries disabled the device. Are you using a dongle instead??
That’s right. I’m using a natively supported USB dongle instead. I believe it’s an Asus one. The issue disappeared as per above.
Well, that sucks. I'd rather use the integrated bluetooth adapter and not have to buy a new dongle. I hope this issue gets solved soon.
I hope this issue gets solved soon.
The issue is at the driver/kernel level so its nothing something that can be fixed in Home Assistant core as the data is garbage before Home Assistant even sees it. Someone will need to pursue this with the hardware vendor to get it fixed.
I also have the same problem with Govee BLE sensor.
I see this option under system option for Govee Bluetooth integration and also under bluetooth integration. I can turn this off for bluetooth integration, will this stop auto discovering bluetooth devices?
When I want to add bluetooth device, I can enable this to enable discovery and then disable this again OR manually add the device. Will this work?
Is there a solution for this? I have removed the Yale integration (and instead use the August integration) but still get spammed with newly discovered Yale Access Bluetooth devices. I'm running HASS on a Intel NUC. I use the BT for other purposes so I can't disable BT. In previous versions with the new BT integration this didn't happen. Is it really a hardware issue that can't be fixed or ignored?
Is it really a hardware issue that can't be fixed or ignored?
Yes
Is it really a hardware issue that can't be fixed or ignored?
Yes
Even though the error didn't occur in previous versions?
Is it really a hardware issue that can't be fixed or ignored?
Yes
Even though the error didn't occur in previous versions?
It seems unlikely that a new version would generate a bug that would randomly generate bad bluetooth data considering other have already confirmed that the bad data is coming further up the Bluetooth stack before Home Assistant even sees it.
I can confirm that this issue started with HA 2022.09 as well, never happened before.
I tried to disable the "Enable newly added entities" option under the System Options for Bluetooth but the Yale Access Bluetooth devices still keeps coming... I really don't want to disable ALL Bluetooth function. Why can't we just ignore the integration like with other integrations?
@bdraco Rather than auto discovering devices, is it possible to add functionality where user has to enable discovery to add bluetooth devices. Something like permit join in zigbee2mqtt integration.
As I reported before, I see the same problem with my H5075 Govee thermo hygrometer. Even after ignoring the newly discovered device, it keeps finding the device.
I didn't have this problem when I used passive BLE monitor integration from HACS.
It’s not possible. The best you can do is disable Bluetooth in this case since it’s not going to work correctly until the os fixes the drivers
I can confirm that using an external Bluetooth dongle solved the problem I commented on #82373. It seems that there's a HW problem with the Intel Nuc internal BT.
Same result here, I ended up buying this external BT dongle (https://fr.aliexpress.com/item/1005002931530115.html) and disable the internal BT adapter by disabling the integration in Home Assistant and it worked perfectly now. And I have better signal coverage as well !
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/
Intel updated the linux-firmware files for these chips a few days ago. I'm not sure if anyone has had a chance to try it or see if the issue is fixed
I was seeing the same using an Intel Wireless-AC 7260. Airthings BLE kept finding multiple copies of my Shield TV. I updated the drivers yesterday, but they're a bit older than those new ones and seemed to still have the same problem. I plugged in a TP-Link UB400 I had sitting around and so far the issue appears to be resolved.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant 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.
The problem
Since the new Bluetooth integration, my Yale lock are discovered endless times spamming my integrations. This is just a couple of minutes after the restart. It doesn´t work to ignore, it keeps discovering the lock.
Is it supposed to be lite that?
What version of Home Assistant Core has the issue?
2022.9.0
What was the last working version of Home Assistant Core?
none
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
Bluetooth
Link to integration documentation on our website
https://www.home-assistant.io/integrations/bluetooth/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Using Intel Nuc with build in bluetooth