core: Bluetooth tracker does not work with newer python - Can't run HA Core on python 3.11.2 because of dependency to pybluez==0.22

The problem

I created new venv with python 3.11.2, installed HA Core 2023.3.1 there and run hass --script check_config I have a bluetooth tracker enabled in my configuration.

HA tries to install pybluez==0.22 and fails with error:

gcc -pthread -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -ljemalloc -DTHREAD_STACK_SIZE=0x100000 -fPIC -I./port3 -I/srv/homeassistant_3.11.2/include -I/usr/local/include/python3.11 -c bluez/btmodule.c -o build/temp.linux-armv7l-cpython-311/bluez/btmodule.o
      bluez/btmodule.c: In function ‘PyInit__bluetooth’:
      bluez/btmodule.c:2837:22: error: lvalue required as left operand of assignment
       2837 |  Py_TYPE(&sock_type) = &PyType_Type;
            |                      ^
      bluez/btmodule.c:2838:29: error: lvalue required as left operand of assignment
       2838 |  Py_TYPE(&sdp_session_type) = &PyType_Type;
            |                             ^
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

With python 3.10.9 I had no issue at all (currently running venv). I managed to install pybluez from source/github, however this did not solve the issue. Seems like device_tracker integration requires pybluez==0.22 and forces HA to install this version, which is not compatible with python 3.11. I failed to migrate to venv python 3.11 because of this issue.

What version of Home Assistant Core has the issue?

2023.3.1

What was the last working version of Home Assistant Core?

2023.3.1

What type of installation are you running?

Home Assistant Core

Integration causing the issue

Bluetooth Tracker

Link to integration documentation on our website

https://www.home-assistant.io/integrations/bluetooth_tracker/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

gcc -pthread -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -ljemalloc -DTHREAD_STACK_SIZE=0x100000 -fPIC -I./port3 -I/srv/homeassistant_3.11.2/include -I/usr/local/include/python3.11 -c bluez/btmodule.c -o build/temp.linux-armv7l-cpython-311/bluez/btmodule.o
      bluez/btmodule.c: In function ‘PyInit__bluetooth’:
      bluez/btmodule.c:2837:22: error: lvalue required as left operand of assignment
       2837 |  Py_TYPE(&sock_type) = &PyType_Type;
            |                      ^
      bluez/btmodule.c:2838:29: error: lvalue required as left operand of assignment
       2838 |  Py_TYPE(&sdp_session_type) = &PyType_Type;
            |                             ^
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

Additional information

No response

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 9
  • Comments: 67 (6 by maintainers)

Most upvoted comments

It’s also possible to use bluetooth integration with D-Bus API instead. Here’s a proof of concept if anyone wants to try. custom_bluetooth_tracker.zip

Caveats:

  • Discovery is not implemented, so trackable devices should already be present in known_devices.yaml
  • Bluez experimental features should be enabled (–experimental flag)

any news in 2024.2 version? in this release ships running on Python 3.12!

It’s also possible to use bluetooth integration with D-Bus API instead. Here’s a proof of concept if anyone wants to try. custom_bluetooth_tracker.zip

Caveats:

  • Discovery is not implemented, so trackable devices should already be present in known_devices.yaml
  • Bluez experimental features should be enabled (–experimental flag)

andriilahuta, this is working so far on my HAOS VM. Thanks!

It’s also possible to use bluetooth integration with D-Bus API instead. Here’s a proof of concept if anyone wants to try. custom_bluetooth_tracker.zip

Caveats:

  • Discovery is not implemented, so trackable devices should already be present in known_devices.yaml
  • Bluez experimental features should be enabled (–experimental flag)

Thanks! it works!!!

looks like xz-dev has moved the underlying component from pybluez to bleak - it’s just waiting on on a workflow approval - i’m currently stuck at 2023.5.4 …

@boggiano try lowering dbus-fast version in custom_bluetooth_tracker/manifest.json to 1.86.0.

It works! Thanks!

@boggiano try lowering dbus-fast version in custom_bluetooth_tracker/manifest.json to 1.86.0.

HI,

Andriilahuta - thanks for your custom component. I eventually tested it out and can confirm it works fine, both on my Pi4 and on my generic x86 instances of HA running HAOS

Home Assistant 2023.8.4 Supervisor 2023.08.1 Operating System 10.5 Frontend 20230802.1 - latest

Once again many thanks.

“‘Method “ConnectDevice” with signature “a{sv}” on interface “org.bluez.Adapter1” doesn’t exist\n’” Is this the problem?

Yes, that’s why it doesn’t work. I’m not sure when it was introduced into BlueZ D-Bus API, although this is still an experimental feature (here are the docs). I have BlueZ version 5.64 on Ubuntu 22.04.

I am still on Ubuntu 18.04 🤦 and my BlueZ version is 5.48. I have an upgrade planned to go to Debian 12, so hopefully that will fix things.

Thanks for your help.

UPDATE:
Spun up a test VM of Debian 12 and its BlueZ version is 5.64-2. At first it had the same methods as the previous screenshot, but when I enabled “–experimental” there are a bunch more, including the needed ConnectDevice Screenshot_2023-08-09_18-36-39 I am confident an upgrade to my HA system should make your custom_bluetooth_tracker component work as intended.| I guess my older version doesn’t quite do the “–experimental” flag properly. I just removed the flag and restarted, and it appears the “–experimental” flag does not add anything to the dbus methods.

HAOS has the experimental flag turned on by default so it should work for most people.

Ideally the dbus implementation would get moved into a lib and a PR could be opened to replace the pybluez implementation with a dbus based one which should make things work for the foreseeable future.

Support for 3.11 added in https://github.com/pybluez/pybluez/commits/master but pybluez hasn’t done a release that supports 3.11 yet so this isn’t fixable until a new released is available.

Hi, I am facing the same issue (pip 23.0.1 from /srv/homeassistant/venv_3.11.2/lib/python3.11/site-packages/pip (python 3.11)) I have tried to install directly in the venv but same error: Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple Collecting pybluez Using cached PyBluez-0.23.tar.gz (97 kB) Preparing metadata (setup.py) … error error: subprocess-exited-with-error

× python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [1 lines of output] error in PyBluez setup command: use_2to3 is invalid. [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed

× Encountered error while generating package metadata. ╰─> See above for output.

note: This is an issue with the package mentioned above, not pip. hint: See above for details.

Also is blocking the upgrade 😦