Slow response times after enabling BLE tracker

[lawrencecraft]

Home Assistant release (hass --version): 0.32.4

Python release (python3 --version): 3.4.2

Component/platform: Bluetooth Low-Energy

Description of problem: Enabling the Bluetooth LE tracker on HASS running on a Raspberry Pi 3 significantly slows the UI. Ordinarily light switching is near-instantaneous, but after enabling BLE I get delays of 2 to 10 seconds.

Note that it does seem to work: I can see my BLE device on the UI.

Expected: No significant performance impact.

[mihalski]

Are you using it over wifi? The bluetooth can SEVERELY impact the wifi signal. I basically had to stop using wifi and use a LAN cable in order to be able to use it.

[kolossboss]

I run into the same problem. With BLE, the response time is soo slow. I'm not using wifi. My Raspberry Pi 3 is cable connected.

Sorry not true ^^ --> I noticed the CPU used is very high 30-40 % if BLE is enabled. Normal is <2%

[lawrencecraft]

@mihalski Good point. I'll try hardwiring it when I get home from work. At the moment it's wifi.

In contrast to @kolossboss I didn't notice too much CPU impact. I ran htop while BLE was enabled and didn't see anything above single-digit CPU usage. Maybe slightly higher than normal but no more than 7%, iirc.

[kolossboss]

Ok. I have mistaken that. My CPU seems normal. Its "only" slow response.

Sorry for that

[fanaticDavid]

I am noticing the same performance hit within Home Assistant on my RPi 3 when the BLE tracker is enabled. My RPi has a wired connection, the wifi connection is not used. The CPU load does not increase (or barely at the most) when the tracker is enabled, so that is not causing the issue.

I have used the BLE tracker for presence detection as both my partner and I have a Fitbit Charge HR, but I had to resort to disabling it again. The performance hit is way too significant, to the point that even my automations wouldn't fire reliably anymore. I hope to see a fix for this...

[mnoorenberghe]

I happened to be reading the code today (I haven't used this component myself yet) and noticed that it seems like it's intentionally trying to scan at least 80% of the time with default settings (at least as I understand the code):

1. update_ble synchronously calls discover_ble_devices which by default scans for 10 seconds.
2. At the end of update_ble, the next call of update_ble is scheduled on a timer for 12 seconds after the time that step 1 started which means no more than 2 seconds (12-10) from the time it's being scheduled.

So for every 12 wall clock seconds (assuming track_point_in_utc_time works like I think), at least 10 seconds is spent scanning for devices + handling the scan results. 10s/12s = 83.3%.

@open-homeautomation: I'm not sure if was intentional to use a consistent schedule which allows for users to define interval_seconds < scan_duration or not? Is it the norm around hass to schedule this way rather than have interval_seconds start counting when the last update completes?

Please correct me if I'm wrong about the timing. Perhaps this isn't the main bottleneck but it may be a factor.

P.S. #3019 didn't document the BLE scan_duration option which can be tweaked like interval_seconds to possibly help the response time issues.

[ghost]

12 seconds scan interval is definitely too short for the BLE tracker. I would recommend at least 5 minutes. However, all device trackers share the same global scan interval configuration. I think it is still not possible to set separate scan intervals for different device trackers. The first configured option is used. Therefore I recommend to increase this to at least 5 minutes.

[mihalski]

Interesting.. My bad experience was with the standard BT tracker not the BLE one and now that I don't use Wifi it's not affected anymore. I wonder if that has a different set of issues that also stem from the same problem?

[mnoorenberghe]

Maybe, though I suspect there are also Pi hardware limitations at play in both of these. The regular BT tracker uses the same scheduling approach (wherein it doesn't take its own update time into account when scheduling the next update) but it uses a scan duration of 8 seconds (instead of 10 for BLE) which is still quite long for a 12 second default value of interval_seconds.

[mihalski]

The symptoms I had were Wifi completely cutting out, so that for example a remote ping would fail to return for extended periods over and over and ssh connections would drop. I couldn't find any error in the logs and it didn't occur to me until someone suggested it that the two could be interfering.. It's unfortunate because integrated Wifi/BT was the reason I got the RPi3 in the first place assuming it was an all in one solution that mitigated this sort of interference.

[MaKin211]

I have as USB connected BLE dongle on my Pi 2 and I'm struggling with exactly the same problem. The Pi is connected via ethernet and turning on lights takes about 10 seconds. I had to disable it in order to have HASS working. Using BLE devices for presence detection would be so great.

I hope we somehow find a solution. :(

Could you maybe rename your issue as it clearly is an issue for Pi2 as well.

[ZHumphries]

Same problem. HA: 0.32.4 / Python: 3.4.2

Wired Pi3 running jessie. Once bluetooth LE is enabled I get a delay of about 10 seconds. CPU sitting around 15%

[MaKin211]

Deactivate the BLE component. Afaik there is no solution.

Instead, get room-assistant and use MQTT. It works flawlessly and is also using hcitool lescan just like the BLE component without any delay.

[ghost]

I wonder, as I have seen this issue too and then just disabled it. Is there a way that the developers here can do some kind of tracing on the code / commands being executed here to see where the delay comes in ?

There must be some kind of api / command line call that is being run which is in some way stopping the execution of other HA code maybe ?

Thoughts ?

[moskovskiy82]

Facing the same issue. Ethernet connected RPi3. Using the built in BT module. After enabling the BT LE component everything slowed down. Taked 5-6 seconds to switch the light on or off.

[firefrei]

I'm facing exactly the same problem. An update to the newest release 0.37.0 did not solve the issue. With BLE Tracker enabled, HASS freezes for some seconds, then it executes all commands, then it freezes again. I enabled the Debug mode for the BLE tracker and it seems like HASS freezes when the BLE component is scanning for devices. HASS is completely wired and running on a PI3. CPU load is normal. Running HASS with disabled device_tracker component runs without any problems.

Are there already any ideas how to fix this?

[ghost]

maybe a noob suggestion but shouldn't the scan be done async like the other device scanners?

[firefrei]

Yes, I also think it should.

I just made some quick tests and it looks like gattlib is blocking during a discovery. I'm just about converting the BLE component to be handled async. It still feels like its blocking by some reason. I'll submit a PR if i finished testing and figured out which part is still blocking.

[ghost]

How did you get on?

[firefrei]

Well, I converted the BLE component to be handled completely async using asyncio. This part is done and works already! But, gattlib is still blocking and I haven't figured out why it is doing this.

The blocking part is the discovery devices = service.discover(duration). I changed it to be executed with an executor devices = yield from hass.loop.run_in_executor(None, service.discover, duration). This should actually prevent the task from blocking the loop (if I got it right).

Has anybody an idea what else I could try? The use of gattlib is encapsulated in an asyncio-coroutine, the blocking discovery itself (as shown above) is handled by an executor in this task.

I've also tried to create a new executor with 10 workers, same effect.

[pvizeli]

The problem are that gattlib is not asyncio compatible. You can't use gattlib in a asyncio context. But that is not a problem since homeassistant support sync and async. Please use only sync stuff and don't mix it with async.

If gattlib will going to support asyncio, you can migrate the hole platform to async.

[firefrei]

Okay, but just for my understanding of asyncio: Isn't run_in_executor meant for executing blocking stuff in an async task?

[pvizeli]

@FREImedia that is correct. But homeassistant do that on core for non async stuff. Only real asyncio library allow to run in async context from hass.

[firefrei]

@pvizeli Thanks for the info! Do you think there could be a solution for a workaround, until gattlib supports asyncio properly? Even if its not a beautiful solution, but like executing it with the real asyncio-libary for example (if thats possible in any way) or in an own thread next to hass with a callback? Because at the moment you can hardly use the BLE component, because hass is not able to execute any other stuff during a discovery...

[abmantis]

I'm not really into python but, couldn't we wrap the blocking stuff in some kind of thread or async task? Something like: http://stackoverflow.com/a/41081518/1054746

[firefrei]

Well, that's what @pvizeli explained to me. Normally you could run it async with run_in_executor. But they "changed the API" as they need the run_in_executor function for the HA legacy stuff. I already tried to do it in that way - of course without any success. The "standard" Python threading and processing lib also did not solve the issue (or I was too stupid to set it up correctly.. who knows :D)

Maybe I'll try my luck with an HA-AppDaemon script scanning for the BLE devices and see how well that works until anybody has the breaking idea!

[abmantis]

@FREImedia But is run_in_executor parallel? Or is just async on the main thread? If run_in_executor runs in another thread, I couldn't really understand @pvizeli explanation as to why it won't work...

I was thinking of having a small service doing ble scans and publishing to mqtt, but that is not as good as using the integrated ble component :(

[abmantis]

I've tried making the component async (with async_Setup_scanner and such), but still run_in_executor blocks...

[firefrei]

@abmantis Thats what I tried before. Normally it should work with run_in_executor as its meant for blocking stuff. But according to @pvizeli HA uses run_in_executor to execute all the non-async "legacy" HA stuff (so any HA-code not yet compatible with asyncio) to run it inside the loop. So of course, anything you run with run_in_executor will block the loop. That's the problem.

[abmantis]

Oh right! Makes sense then. Bummer :-\

[flowolf]

Having the same issue: RPi3, cabled, Raspbian kernel 4.4.13-v7+, HA: 0.39, python: 3.4.2

home assistant blocks when BLE tracker is enabled. doesn't matter which kind of light I want to switch (MQTT, zwave, RF)...

[balloob]

We should consider adding a warning to the startup of this platform that it heavily impacts performance on a Pi.

[fanaticDavid]

@balloob So there is no fix for this issue? Then I would avoid using the BLE tracker on a Raspberry Pi at all costs. It doesn't just impact performance, it makes Home Asssistant (automations) downright unreliable!

[balloob]

I don't use it but since there is no one in this thread with a fix, there doesn't seem to be one?

[michaelarz]

Hi! First of all, I run my HA not on Pi, but on VM with Debian 8 and 2 gb RAM. Performance should be much higher than Pi as it is a Xeon based ESXi host. So after implementing Bluetooth LE tracker also got longer response time and my log filled with only one message like this:

17-04-01 17:36:53 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:37:15 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:37:37 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:38:00 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:38:22 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:38:46 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting
17-04-01 17:39:09 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting

If I turn off BLE tracker, normal system behavior is back again. Sorry for posting in a thread about BLE problem on Pi, but I would like to point that BLE tracker may give you the problem on any platform.

[rytilahti]

You could try to experiment with scan_interval and scan_duration, starting with choosing a shorter duration like 1-3 seconds to see if it helps. Depending on the state of devices and how they advertise themselves they may not be detected during each cycle, but it may be better than blocking everything for 10 seconds?

This would also make the device available for other components trying to use BLE, which is not possible during the scanning (depending on the hardware?), I suppose.

[michaelarz]

Well maybe I did not try all 144 possible variants, but the changes pretty much give nothing. Still getting same error.

[michaelarz]

Solved with room-assistant. Thanks to @MaKin211 for advise. I don't like such workarounds which spread the installation, bit for now I just don't see any other option for BLE tracker. Hope this helps somebody.

[MaKin211]

@michaelarz glad I could help.

[SweAdelpha]

@MaKin211 @michaelarz So are you guys using the MQTT Device Tracker platform in home assistant with room-assistant?

[MaKin211]

Yep, exactly.

Am 15.05.2017 um 19:37 schrieb SweAdelpha notifications@github.com:

@MaKin211 @michaelarz So are you guys using the MQTT Device Tracker platform in home assistant with room-assistant?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[balloob]

@SweAdelpha do not use issues for support. Use the forums or the chat. I will remove any support related posts following this comment.

[balloobbot]

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 :+1:

[fanaticDavid]

Still relevant, as far as I know.

[younes200]

Yes, still relevant :(

[rytilahti]

A change to allow passive scanning just got merged to bluepy which to my understanding keeps to listening to advertisements without requesting more information from the devices, which could be interesting: https://github.com/IanHarvey/bluepy/issues/198

[Eina61]

Still relevant and doesn't work at all under HASS.IO from what I can see.

[MJP-76]

PI3, WiFi and Bluetooth addon enabled with Bluetooth tracking only, not BLE and still slow response from PI and device activation via Alexa

Disable the Bluetooth addon and all fine again with quick response via Alexa to turn on/off devices

[cexshun]

Still relevant. Also noticed during the BLE scan, the SSH session becomes unresponsive and I'm unable to type into the console until the scan is completed.

[ghost]

If you do this on a Raspberry Pi with WiFi network connection this is normal as WiFi and Bluetooth share the same interface.