Bluetooth error supervised-installer

nebulousman · December 9, 2022, 3:44am

I installed home assistant supervised using the supervised-installer method from this link on an old ThinkPad with Debian. Except for the bluetooth error everything works. Following the Requirements for Linux here and I can’t figure out how to make Dbus socket available because I don’t know how to run the command in the container. I don’t have docker-compose. Are there any instructions on how to make Dbus socket available or maybe complete tutorial on enabling bluetooth without docker-compose? bluetoothctl in Konsole terminal returns Agent registered

CentralCommand · December 9, 2022, 3:52am

Your terminology here suggests to me that you installed kde rather then vanilla Debian 11. This would likely explain why you are having issues.

Derivatives of Debian are not supported for supervised installs, only Debian 11 bullseye. Here’s the current list of requirements for a supported and healthy supervised install:

github.com

home-assistant/architecture/blob/2017fdae15d48f287f2398e3243a91ec7a34b161/adr/0014-home-assistant-supervised.md#supported-operating-system-system-dependencies-and-versions

# 0014. Installation method: Home Assistant Supervised

Date: 2020-06-03

## Status

Accepted

## Context

Define a supported installation method as per [ADR-0012](https://github.com/home-assistant/architecture/blob/master/adr/0012-define-supported-installation-method.md).

## Decision

This installation method provides the full Home Assistant experience on a regular operating system. This means, all components from the Home Assistant method are used, except for the Home Assistant Operating System. This system will run the Home Assistant Supervisor. The Supervisor is not just an application, it is a full appliance that manages the whole system. It will clean up, repair or reset settings to default if they no longer match expected values.

By not using the Home Assistant Operating System, the user is responsible for making sure that all required components are installed and maintained. Required components and their versions will change over time. Home Assistant Supervised is provided as-is as a foundation for community supported do-it-yourself solutions. We only accept bug reports for issues that have been reproduced on a freshly installed, fully updated Debian with no additional packages.

This method is considered advanced and should only be used if one is an expert in managing a Linux operating system, Docker and networking.

This file has been truncated. show original

As it says in the list

Debian Linux Debian 11 aka Bullseye (no derivatives)

Derivatives change all sorts of low level things that cause the installer and/or HA to break in unexpected ways.

nebulousman · December 9, 2022, 4:56am

sorry for the confusion - I’m ssh into the machine from another laptop running kde - the ThinkPad with HA is running Debian 11 bullseye

CentralCommand · December 9, 2022, 5:31am

Ah ok. Sorry for jumping to conclusions.

You shouldn’t need to do anything in the container, that part should all be done for you. You followed all the steps here right? There’s also a list of supported machine types, is yours in the list?

nebulousman · December 9, 2022, 3:20pm

I followed those instructions and the machine is ThinkPad X200 which I think would be x86-64 on the list. I thought what I was missing was the Requirements for Linux here and making Dbus socket available and I can’t figure out how to do that and run the command in the container but maybe there’s something else I’m missing.

CentralCommand · December 9, 2022, 6:04pm

So in a supervised system, a service on the host starts supervisor and supervisor manages all the other HA containers (core and addons). Supervisor always has a dbus socket available otherwise most of its features don’t work and you’d see a repair about that along with a lot of log errors. I assume you aren’t seeing anything like that? If not then supervisor has dbus access.

Supervisor is responsible for running the core container correctly. So that would be its job to start it with the dbus socket. And it does add that volume to the HA container right here:

github.com

home-assistant/supervisor/blob/ed778f09ee4976f0bb7a33b8a08a59341781f091/supervisor/docker/homeassistant.py#L69

    
      
                  + self.sys_hardware.policy.get_cgroups_rules(PolicyGroup.VIDEO)
                  + self.sys_hardware.policy.get_cgroups_rules(PolicyGroup.GPIO)
                  + self.sys_hardware.policy.get_cgroups_rules(PolicyGroup.USB)
              )
          
          
@property
          def volumes(self) -> dict[str, dict[str, str]]:
              """Return Volumes for the mount."""
              volumes = {
                  "/dev": {"bind": "/dev", "mode": "ro"},
                  "/run/dbus": {"bind": "/run/dbus", "mode": "ro"},
                  "/run/udev": {"bind": "/run/udev", "mode": "ro"},
              }
          
          
    # Add folders
              volumes.update(
                  {
                      str(self.sys_config.path_extern_homeassistant): {
                          "bind": "/config",
                          "mode": "rw",
                      },

Those instructions in the bluetooth documentation are really aimed at users doing a container install as they have to run the HA container themselves. Supervised and OS installs are considered appliance installs, after you run the installer everything is managed from within the HA UI and CLI. Direct docker CLI access is never required and using it to make changes outside of the HA UI and CLI isn’t supported.

So I would start with the supervisor log. If this is not being set up correctly there is likely something in there. You can see that by going to Settings → System → Logs and then changing to supervisor in the top right. Or by entering ha supervisor logs in the CLI.

nebulousman · December 9, 2022, 7:27pm

this was extremely helpful - thank you - In case someone else has a similar issue here’s how mine was resolved - I checked supervisor logs and there were no errors but in home assistant core logs I noticed homeassistant.config_entries no bluetooth found at a MAC address and when I checked my ssh terminal bluetoothctl it showed a different MAC address for the controller. I went to the bluetooth integration in HA which was showing the error to see if I can point it to the correct address when home assistant discovered the correct bluetooth controller with the correct address and I was able to configure it. I’m not sure why my controller was not discovered before and I do not know how I could have fixed this if home assistant hadn’t discovered the correct controller on its own but I know the problem was the MAC address. I did have home assistant on a rpi prior to switching to the thinkpad that was collecting dust and when I made the switch I did use the backup to restore my settings. I suspect the rpi bluetooth controller address probably made it to the new machine through the restore. A learning experience for me. Thanks again @CentralCommand for guiding me and your explanation of how it all works is new learning and much appreciated.

nebulousman · December 9, 2022, 7:40pm

after typing the message I went back to integrations and noticed the error with the bluetooth integration again - now every minute or so it goes to initializing for a few seconds then it shows retrying setup failed to start Bluetooth: [org.bluez.Error.InProgress] Operation already in progress. It is continuously cycling between retrying setup and the error

CentralCommand · December 9, 2022, 7:57pm

I think at this point I’d suggest submitting an issue here. It doesn’t sound like you’re doing anything wrong to me but I’m also not really an expert in how Bluetooth works in HA. It doesn’t seem like an obvious config problem so it would probably be best to collect all the debug info you have and post what’s going on there. That way one of the code owners of that integration can take a look at it.