Bluetooth LE Tracker issues

I’ve configured the Bluetooth LE Tracker component and it works for a few hours (between 2 and 12), after which I get these kind of errors, any idea why they might be happening?

  1. Unexpected error when scanning:

  2. Error doing job: Future exception was never retrieved
    Traceback (most recent call last):
    File “/usr/local/lib/python3.6/site-packages/pexpect/spawnbase.py”, line 166, in read_nonblocking
    s = os.read(self.child_fd, size)
    OSError: [Errno 5] I/O error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/pexpect/expect.py”, line 111, in expect_loop
incoming = spawn.read_nonblocking(spawn.maxread, timeout)
File “/usr/local/lib/python3.6/site-packages/pexpect/pty_spawn.py”, line 485, in read_nonblocking
return super(spawn, self).read_nonblocking(size)
File “/usr/local/lib/python3.6/site-packages/pexpect/spawnbase.py”, line 171, in read_nonblocking
raise EOF(‘End Of File (EOF). Exception style platform.’)
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/pygatt/backends/gatttool/gatttool.py”, line 315, in scan
scan.expect(‘foooooo’, timeout=timeout)
File “/usr/local/lib/python3.6/site-packages/pexpect/spawnbase.py”, line 341, in expect
timeout, searchwindowsize, async_)
File “/usr/local/lib/python3.6/site-packages/pexpect/spawnbase.py”, line 369, in expect_list
return exp.expect_loop(timeout)
File “/usr/local/lib/python3.6/site-packages/pexpect/expect.py”, line 117, in expect_loop
return self.eof(e)
File “/usr/local/lib/python3.6/site-packages/pexpect/expect.py”, line 63, in eof
raise EOF(msg)
pexpect.exceptions.EOF: End Of File (EOF). Exception style platform.
<pexpect.pty_spawn.spawn object at 0x7f4a3dc9a5c0>
command: /usr/bin/hcitool
args: [’/usr/bin/hcitool’, ‘-i’, ‘hci0’, ‘lescan’]
buffer (last 100 chars): b’’

after: <class ‘pexpect.exceptions.EOF’>
match: None
match_index: None
exitstatus: None
flag_eof: True
pid: 2322
child_fd: 56
closed: False
timeout: 30
delimiter: <class ‘pexpect.exceptions.EOF’>
logfile: None
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.1
searcher: searcher_re:
0: re.compile(b’foooooo’)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/device_tracker/bluetooth_le_tracker.py”, line 96, in update_ble
devs = discover_ble_devices()
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/device_tracker/bluetooth_le_tracker.py”, line 58, in discover_ble_devices
devs = adapter.scan()
File “/usr/local/lib/python3.6/site-packages/pygatt/backends/gatttool/gatttool.py”, line 326, in scan
raise BLEError(message)
pygatt.exceptions.BLEError: Unexpected error when scanning:

Sorry I don’t have a solution, but I have something similar.

I am using just the non-LE Bluetooth tracker, and I too have a similar symptom, it works for a few hours then stops, but I don’t get any errors.

I was wondering, are you using this on a NUC and on the builtin Bluetooth hardware?

I have had Bluetooth issues ever since I migrated from a raspberry pi to a NUC and have no idea how to troubleshoot or fix, and was wondering whether your issue is the same and related to hardware if you are running on a NUC.

I am using a DELL PC with an ASUS BT400 USB Bluetooth device…sounds like a problem with the components, I guess :frowning:

Oh, there goes that theory. I guess they could be different issues then.

What scan interval are you using?

For interval_seconds I have 12

OK, then new theory: how many devices are you tracking?

I recall not getting the error in the first couple of days with only my Tile, it was only after adding my gf’s Tile that the errors started…I’ve removed hers and will see what happens.

Well, 16 Bluetooth devices, but 41 devices overall including Bluetooth and the netgear device trackers

But to add, this was working very reliably with the same setup on my raspberry pi, as soon as I migrated to my NUC this is when I started having issues
The raspberry pi is still running HA with just the Bluetooth device tracker for comparison and it still works flawlessly even when there NUC setup stops working
The other difference is that the raspberry pi is running an older version of HA

1 Like

Yeah, I think other BT adapters than the one in the Pi may not be particularly well supported.

So, the question arises whether it’s worth getting a Pi, all its relevant paraphernalia AND maintaining another HA instance only for this purpose…I’d really prefer trying to figure out what’s causing the tracker to stop working and maybe submit a bug and have it fixed by the component creator(s), then everyone with non-Pi BT would benefit.

just checked versions:
The Bluetooth working perfectly and very reliable on raspberry pi HA version 0.80.3
The Bluetooth unreliable very flaky NUC HA version is 0.86.4

yes, same.
I don’t really want to maintain the raspberry pi and somehow feed the Bluetooth device states in to my primary HA install on the NUC

No need to open a bug report, it is reported both here: https://github.com/home-assistant/home-assistant/issues/19592 and here: https://github.com/home-assistant/home-assistant/issues/19760

Let’s see if it can be resolved…

I am now wondering whether your issue and those logged in GitHub are different to mine as I am using the non le component and you are using the le component and this error is specific to that component
does the Bluetooth le component track non le devices?
also which version of HA are you running ?

I’m running 0.87.0, but also had this issue in 0.86.4.

I’m not sure if the respective components can track the other’s devices, haven’t tried yet, but assume they exist separately because they don’t.

Ultimately, to me it looks like an issue with accessing the Linux BT stack with anything other than the RPi BT chip…which makes some sense, since the components must have been designed with that chip in mind.

Your theory certainly makes sense, I am going with that too. Hopefully some clever soul can find a fix which will fix both platforms

Also makes sense that the le tracker would only track le devices and vice versa

I think I might try and install the latest HA on my raspberry on a spare sd card to see how reliable that is see if we can eliminate HA version from the equation

Good idea!

Unfortunately I got the error even with just 1 Tile after 8 hours :frowning:

Hopefully someone can fix the components, otherwise I guess I need to look into getting a Pi.

Well, I ended up using a pretty convoluted workaround for this, but it should be OK until hopefully the bug gets fixed:

In sensors.yaml:

  - platform: command_line
    name: "BLE Error"
    icon: mdi:bluetooth
    scan_interval: 30
    payload_on: 'on'
    payload_off: 'off'
    command: if grep -i 'BLEError' /config/home-assistant.log > /dev/null; then echo 'on'; else echo 'off'; fi

In automations.yaml:

- alias: Restart on BLE Error
  hide_entity: False
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id: sensor.ble_error
      to: 'on'
  action:
    - service: notify.telegram_florin
      data:
        message: 'HA is being rebooted due to BLE Error'
    - service: hassio.host_reboot

Also in automations.yaml:

- alias: Send alert when Florin is Away
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id: device_tracker.tile
      to: 'not_home'
      for:
        seconds: 45
  action:
    - service: notify.telegram_florin
      data:
        message: 'Florin is Away'

This achieves the following:

  • checks homeassistant.log every 30 seconds for the BLE error
  • notifies me and restarts HA whenever the error is found
  • the “Away” notification automation (but I assume any other automation would work the same way) doesn’t trigger until I’ve been Away for 45 seconds, thus not wrongly being triggered when I’m declared away because of the BLE error
1 Like

Ah interesting, I thought a service restart needed higher permissions than normally the service account had?

Thanks for sharing, although for me to bring Bluetooth only becomes fully operational (as much as it can be) after a full os restart. Which I can’t just do automatically as it is also my Plex server.

Playing around today I found that for some reason only the device first in the list of the knowndevices file was reliably tracked (whilst it was operational). The ones further down the file appeared to only be monitored when the first device in the file was home. Devices even further down the list were not tracked at all

All very puzzling. Tomorrow I will see if I get time to try the raspberry pi on the latest HA version and see how that performs with Bluetooth

The command does a full OS restart, my entire Ubuntu VM reboots when it’s triggered, but yeah, I get what you mean about restarting at uncomfortable moments.

Unfortunately, as described in the GitHub issue ( https://github.com/home-assistant/home-assistant/issues/19592 ), those 2 people have the same problem as me even with a Pi, so buying one might not be a definite cure-all :frowning:

It sucks, because Bluetooth + some kind of BLE tag provides perfect presence detection, way better than GPS or WiFi, I think also because the tags are very likely to always reside in the same place (keys kept near the door).