I have a new Home Assistant installation (Core: 2024.1.5 Frontend: 20240104.0) that run in a container environment. The host have no bluetooth adapter. HA is running correct and have a bluetooth error (correct bluetooth not exist).
I also have an ESPHome device (ESP8266) in the Network. the ESPHome device does not appear in the discovered list (UPnP devices are listed).
When I want to add the ESPHome device manually (see HA-ESPHome-Docu), then I get an error: Unable to set up dependencies of ‘esphome’. Setup failed for dependencies: bluetooth
What am I doing wrong? Does ESPHome only work with Bluetooth?
I have the same configuration and it works fine. Not sure where the Bluetooth error is coming from…All I can suggest is to check that you don’t have an incorrect integration installed. The other thing to confirm is that your container has been installed with host networking. You can get it to work with a private container network but you lose mDNS so you have to specify ip addresses for everything and you lose auto discovery.
After that when I go to Settings → Devices & services → add integration → ESPHome an than I get this error: Error: Config flow could not be loaded: Failed dependencies bluetooth
There is an error in the error log:
Logger: homeassistant.setup
Source: setup.py:333
First occurred: 6:38:58 PM (1 occurrences)
Last logged: 6:38:58 PM
Error during setup of component bluetooth
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 333, in _async_setup_component
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/bluetooth/__init__.py", line 152, in async_setup
await manager.async_setup()
File "/usr/src/homeassistant/homeassistant/components/bluetooth/manager.py", line 132, in async_setup
await super().async_setup()
File "src/habluetooth/manager.py", line 217, in async_setup
File "/usr/local/lib/python3.12/site-packages/bluetooth_adapters/systems/linux.py", line 36, in refresh
await self._bluez.load()
File "/usr/local/lib/python3.12/site-packages/bluetooth_adapters/dbus.py", line 39, in load
self._packed_managed_objects = await _get_dbus_managed_objects()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bluetooth_adapters/dbus.py", line 103, in _get_dbus_managed_objects
bus = await MessageBus(bus_type=BusType.SYSTEM).connect()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/dbus_fast/aio/message_bus.py", line 225, in connect
await self._authenticate()
File "/usr/local/lib/python3.12/site-packages/dbus_fast/aio/message_bus.py", line 492, in _authenticate
response = self._auth._receive_line(await self._auth_readline())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/dbus_fast/auth.py", line 99, in _receive_line
raise AuthError(f"authentication failed: {response.value}: {args}")
dbus_fast.errors.AuthError: authentication failed: REJECTED: ['EXTERNAL']
I don’t understand why it’s trying to load the Bluetooth integration, what type of device are you specifying the IP address of when you try and add the integration?
I didn’t have to add the integration, it was auto loaded when the first ESPHome device was detected on the network. Are you sure your ESPHome device is connected to the network and has the API enabled?
I have also been seeing this issue. I don’t use the bluetooth integration and don’t have the bluetooth radio enabled on my NUC. I got tired of the error spamming my logs though… so I did some additional digging.
For me, the issue was that I am running in a container (Ubuntu 22.04 LTS) without providing the privileged flag (I try to avoid this when possible). I did a test with turning on the privileged flag and confirmed the error went away. Further digging into that post above indicates it is an issue with the AppArmor policies running on Ubuntu. There is a docker ble policy that can be added to AppArmor and passed to start your container. Example here: GitHub - edgexfoundry-holding/device-bluetooth-c.
I have not seen the error since running with this AppArmor policy in place.