core: Bluetooth scanner conflict results in org.bluez.Error.InProgress

same here. BLE from HACS worked fine, but the new bluetooth integration doesn’t. the new integration will soon be way ahead the HACS BLE Integration. so why closing this issue? it’s a bug that needs to be fixed.

Right. I can think of 2 seperate things going on here.

So the current theory behind most of the problems in this thread is that there are sometimes “broadcast storms” (lots of BLE devices happens to send an advertisement at about the same time) and this is overwhelming a buffer in a kernel driver or bluez or something. Probably the kernel because this is most common in realtek devices. But this only happens when we are listening for advertisements (which we need to do for passive sensors). So if you never used BleakScanner your integration probably never triggered this bug in your bluetooth dongle/kernel before.

A newer kernel might fix it (we’ve had some reports of this but not enough to be confident). The best HA can do to fix this is some hacky auto-restarter job.

The other possibility in your case is that when you connect to a MAC address, bleak actually secretly starts a BleakScanner in the background to resolve the MAC address. You can actually only run a single scanner at once with BlueZ, so if the bluetooth integration is already running one, your integration can’t resolve the MAC address. That could explain why your integration gets an “Operation already in progress” error.

It might be enough for your custom integration to add a bluetotoh to its “dependencies” key in its manifest.json. This will make sure that the bluetooth integration has chance to set up its compatibility shims before your code runs. Failing that, you want to use the async_ble_device_from_address API (https://developers.home-assistant.io/docs/network_discovery?_highlight=bluetooth#fetching-the-bleak-bledevice-from-the-address). This will resolve your MAC address into a BLEDevice without starting an extra bleak scanner. Anywhere you pass a MAC address to Bleak, pass a BLEDevice instead. Bonus, this will be faster as HA will have pre-resolved the MAC address.

If you try this and have trouble with it please start another ticket to track it, as it is a seperate problem to the first one i describe.

As for rpi4 - we are actively encouraging people not to use onboard bluetooth because the range is known to be crap. As for reliability, I have no idea. I haven’t been able to get hold of one to use for HA testing.

@tonyt2975 @EvgenaNet I SSH’d in and used the command bluetoothctl scan on and restarted home assistant for it to work

2022.8.5 and still the same error:

Error stopping scanner: [org.bluez.Error.InProgress] Operation already in progress

The integration is incomplete and glitchy.

The Xiaomi integration is for firmware provided by Xiaomi or firmware written to broadcast exactly like Xiaomi firmware. If PVX firmware is the same thing as ATC firmware, thats known to not be supported. Every parser in ble monitor will eventually be converted to a full integration in HA but that requires people to do the work. I did a MiBeacon one (i.e. xiaomi_ble) because I have a bunch of Mi Flora plant sensors.

The stock firmware for LYWSD03MMC has a very slow broadcast rate. It might be as slow as once every 20 minutes? Certainly no faster than once every 10 minutes. Unfortunately i don’t have one, so it only works at all thanks to one very helpful beta tester. One of the things the ATC firmware does is massively increase the transmission rate. Not only does that mean quicker updates, but if some packets are lost because you are barely in range, you don’t notice because there are plenty more. I.e. if there is only 1 broadcast every 10 mins and you miss it… Your graph is a mess.

I.e. this guy is right next to my bluetooth:

But this plant is really out of range:

Like i said, this was probably masked for you by ATC ramping up the broadcast rate. Right now you are probably better sticking with BLEM until someone makes an ATC integration.

Update: as suggested here power cycling solved everything in my case

On bluetoothctl commands I get for power on or power off org.bluez.Error.Busy for scan on org.bluez.Error.NotReady

Also, if I run sudo rfkill unblock all (or any rfkill command) I get Operation Not Permitted

Any suggestions what to do?

https://www.usb.org/sites/default/files/327216.pdf

Sometimes I have to use bluetoothctl to run power off, power on, scan on to unstick bluez on the host wen I get that error. However I think (haven’t proven) that bluetoothctl stops the scan when it exits. I also have to do this when i restart HA.

I currently think I have a buggy version of bluez OR something else is fighting for control of bluetooth. I haven’t had time to dig in yet though.

I am on debian bullseye. My bluez version is quite a few versions behind the latest upstream release, but there isn’t an official route to upgrade it. Anyone using Home Assistant OS, what version are you running? And what bluetooth adaptor are you using? Are you on Arm or x86_64?

@tonyt2975 @EvgenaNet I SSH’d in and used the command bluetoothctl scan on and restarted home assistant for it to work

after rebooting HA the problem comes back

Hmm, I didn’t reboot my machine after. I’ll have to figure out how to enable scan on boot. I’ll look into it again tomorrow night.

after rebooting HA the problem comes back