Hi,
I successfully installed Debian 12 and HA Supervised on Raspberry Pi 4 using this guide. Thanks a lot. Still I have an issue with Raspberry Pi Power Supply Checker. When I try to add this integration in HA I get an error:
Can't find the system class needed for this component, make sure that your kernel is recent and the hardware is supported
So the sensor binary_sensor.rpi_power_status is missing in HA. Could you advise where I should look for logs to troubleshoot the issue please?
After update using this manual: ALL works, thanks
Thank you for confirming 
Does anybody have a similar issue with Raspberry Pi Power Supply Checker? Trying to understand if it’s a common/known issue or I need to dig into my Raspberry Pi 4 deeper…
I have been running through the install process quite smoothly till 2.1, unfortunately I am not able to get connected to “get.docker.dom” see command and response below.
root@rpi4-20230612:~# curl -fsSL get.docker.com | sh
curl: (6) Could not resolve host: get.docker.com
root@rpi4-20230612:~#
Would you be able to resolve this issue?
I am running Debian 12 on Rasberry PI 4 on SSD 256 GB.
Were you ever able to figure out the DNS issues? I tried the reply below your comment by Tamsy but no luck.
Hi Tamsy, apparently there seems to be an issue with “systemd-resolved” on my machine.
Please find below the string I have copied into the terminal:
“apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y”
Once I replaced the string by:
“apt-get install
apparmor
jq
wget
curl
udisks2
libglib2.0-bin
network-manager
dbus
systemd-journal-remote -y”
I was able to continue the installation with internet access.
Btw I kept on receiving errors in the Home Assistant Supervised version so I have decided to go with a Ubuntu / docker / docker compose / home Assistant (regular) setup which is working fine as we speak.
Thanks and regards,
Allard
Hi Slog,
As far as I am concerned the issue has been driven by the code. See my response to Tamsy a minute ago.
DNS has been working fine.
Regards,
Allard
Whats going on here? I make a clrear installation on my raspberry pi 4 8gb debian 12
and when i reach that part:
curl -fsSL get.docker.com | sh
i get that errors:
xxx@xx:~$ ping google.com
ping: google.com: Temporary failure in name resolution
xxx@xxx:~$ ^C
xxx@xxx:~$ cat /etc/resolv.conf
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
xxx@xxx:~$ curl -fsSL get.docker.com | sh
curl: (6) Could not resolve host: get.docker.com
xxx@xxx:~$ ^C
xxx@xxx:~$
Its connected via Ethernet on network i also tried with sudo but nothing!
I fixed the above problem and now stuck on prepairing home assistant i get that log and go to loop:
23-09-06 23:59:21 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state running
23-09-06 23:59:21 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
23-09-07 00:01:20 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant
23-09-07 00:03:20 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API!
23-09-07 00:03:20 ERROR (MainThread) [supervisor.misc.tasks] Home Assistant watchdog reanimation failed!
and on command promt i get this:
sudo dpkg -i homeassistant-supervised.deb
(Reading database ... 42254 files and directories currently installed.)
Preparing to unpack homeassistant-supervised.deb ...
[warn]
[warn] If you want more control over your own system, run
[warn] Home Assistant as a VM or run Home Assistant Core
[warn] via a Docker container.
[warn]
[warn] ModemManager service is enabled. This might cause issue when using serial devices.
Leaving 'diversion of /etc/NetworkManager/NetworkManager.conf to /etc/NetworkManager/NetworkManager.conf.real by homeassistant-supervised'
Leaving 'diversion of /etc/NetworkManager/system-connections/default to /etc/NetworkManager/system-connections/default.real by homeassistant-supervised'
Leaving 'diversion of /etc/docker/daemon.json to /etc/docker/daemon.json.real by homeassistant-supervised'
Leaving 'diversion of /etc/network/interfaces to /etc/network/interfaces.real by homeassistant-supervised'
Unpacking homeassistant-supervised (1.5.0) over (1.5.0) ...
Setting up homeassistant-supervised (1.5.0) ...
[info] Restarting NetworkManager
[info] Restarting docker service
PING checkonline.home-assistant.io (104.26.4.238) 56(84) bytes of data.
64 bytes from 104.26.4.238 (104.26.4.238): icmp_seq=1 ttl=59 time=16.4 ms
--- checkonline.home-assistant.io ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.371/16.371/16.371/0.000 ms
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
[info] Within a few minutes you will be able to reach Home Assistant at:
[info] http://homeassistant.local:8123 or using the IP address of your
[info] machine: http://192.168.1.15:8123
root@Raspi:/usr/local/src#
Is there any special reason why you want to switch from Home Assistant OS to HA Supervised?
Obviously not really.
This guide works well if one strictly sticks to the guide. You seem to have missed paragraph 1.5) and you have missed paragraph 1.6) for sure.
BTW, no need to append
sudo
to cli-commands if you are doing all as root user anyway. In contradiction to what this guide says.
It’s not exactly like that. To understand, it got fixed after 15 minutes. Up to 2.1, everything was done by the book, and the commands I’m entering are definitely remote via SSH. Everything broke after the command , the change ip and reboot fixes the problem with ping the only step that i skipped is the section 4.
Also the main reason I use home assistant supervised is that I want to have all the features of HA (add-ons) and also utilize the raspberry for other things and not “choke” it with only one function. This has been discussed many times, I think, and the reasons are obvious.
Suppose I install Home Assistant OS, can I run Unify Controller simultaneously? Can I set up a VPN Server? Can I have a docker environment for development that requires Debian?
:
apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y
Things messed up and this wasn’t working:
curl -fsSL get.docker.com | sh
The issue is that something is off when I do a ping, and this might be causing many of the problems I’m encountering. I restarted the raspberry again and, while I can normally access the Home Assistant, when I try SSH, I get:
:~$ ping google.com
ping: google.com: Temporary failure in name resolution
It’s as if every time it’s activated, the network manager breaks.
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa ult qlen 1000
link/ether d8:3a:dd:33:4f:fa brd ff:ff:ff:ff:ff:ff
altname end0
inet 192.168.1.15/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 80826sec preferred_lft 80826sec
inet6 fe80::da3a:ddff:fe33:4ffa/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qle n 1000
link/ether d8:3a:dd:33:4f:fb brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gr oup default
link/ether 02:42:0a:63:44:fa brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe63:44fa/64 scope link
valid_lft forever preferred_lft forever
5: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gro up default
link/ether 02:42:0a:1f:44:a8 brd ff:ff:ff:ff:ff:ff
inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe1f:44a8/64 scope link
valid_lft forever preferred_lft forever
7: veth621e7ed@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue mas ter hassio state UP group default
link/ether 52:36:27:a5:be:76 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::5036:27ff:fea5:be76/64 scope link
valid_lft forever preferred_lft forever
9: veth0cf35fa@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue mas ter docker0 state UP group default
link/ether 82:4b:1f:c4:8b:3e brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::804b:1fff:fec4:8b3e/64 scope link
valid_lft forever preferred_lft forever
11: vethda82419@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 86:72:ed:73:4b:20 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::8472:edff:fe73:4b20/64 scope link
valid_lft forever preferred_lft forever
13: veth3f3b8b9@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 06:3e:82:4b:09:63 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::43e:82ff:fe4b:963/64 scope link
valid_lft forever preferred_lft forever
15: vetha5f8663@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 8e:77:76:9a:92:44 brd ff:ff:ff:ff:ff:ff link-netnsid 3
inet6 fe80::8c77:76ff:fe9a:9244/64 scope link
valid_lft forever preferred_lft forever
17: veth34b5d9c@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 6a:4e:d7:7f:ad:1e brd ff:ff:ff:ff:ff:ff link-netnsid 4
inet6 fe80::684e:d7ff:fe7f:ad1e/64 scope link
valid_lft forever preferred_lft forever
19: veth3cc95b9@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether e2:64:7f:d6:dd:cc brd ff:ff:ff:ff:ff:ff link-netnsid 5
inet6 fe80::e064:7fff:fed6:ddcc/64 scope link
valid_lft forever preferred_lft forever
21: vethc1531e3@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 3a:d9:6a:5d:c6:ee brd ff:ff:ff:ff:ff:ff link-netnsid 6
inet6 fe80::38d9:6aff:fe5d:c6ee/64 scope link
valid_lft forever preferred_lft forever
Nope.
With HA Supervised installed but not following ADR0012 / ADR0014 be prepared to run into that “Unhealthy” and “Unsupported” states with your HA installation.
Maybe. But not as that unpriviledged user you are supposed to go from here but you continued directly as the root user as your edited/non-edited log snippets show.
Anyway, you can try the following.
Firstly disable ModemManager from starting after reboots:
sudo systemctl status ModemManager
If modem manager is running stop and disable it:
sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
Now make sure the latest NetworkManager is installed:
sudo dpkg -s network-manager
The output should show:
Package: network-manager
Status: install ok installed
If not, install NetworkManager:
sudo apt install network-manager
Now reboot the host:
sudo systemctl reboot
To prevent /etc/resolv.conf is getting overwritten with every reboot do the following:
Using the CLI edit /etc/NetworkManager/NetworkManager.conf
Search for the [main] section in this file. It should look something like this:
[main]
dns=default
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
Now change dns=default to dns=none just after the [main] tag like this:
[main]
dns=none
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
Save the file and restart NetworkManager.service:
sudo systemctl restart NetworkManager.service
Edit /etc/resolv.conf and add the DNS-server(s) of your choice.
If you haven’t already screwed-up your installation you should be able to continue with:
sudo -i
curl -fsSL get.docker.com | sh
which should finally bring you to the next level.
Finally everything works again!
i made all steps correctly without problem one notice:
after reboot i run again the:
:~$ ping google.com
ping: google.com: Temporary failure in name resolution
Something overwrites settings after reboot , what can cause that problem?
Look one post up:
Check your /etc/resolv.conf after a reboot. If the definition for the DNS servers you configured in there before are overwritten to something else you have not followed the steps correctly.
/etc/NetworkManager/NetworkManager.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
GNU nano 7.2 /etc/NetworkManager/NetworkManager.conf
[main]
dns=none
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
[keyfile]
unmanaged-devices=type:bridge;type:tun;driver:veth
[logging]
backend=journal
[connection]
connection.mdns=2
connection.llmnr=2
[connectivity]
uri=http://checkonline.home-assistant.io/online.txt
[device]
wifi.scan-rand-mac-address=no
/etc/resolv.conf
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
Maybe is something else because as you can see the setup didnt change after reboot but ping doesnt get response.
Is NetworkManager running?
sudo systemctl status NetworkManager.service
If NetworkManager is not running start it with:
sudo systemctl start NetworkManager.service
followed by:
sudo systemctl enable NetworkManager.service
What is
sudo ha dns info
telling?
systemctl status NetworkManager.service
@Raspi:~$ sudo systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; prese>
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (ve>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (ve>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (ve>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (>
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (ve>
lines 1-20/20 (END)
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (vethcc2f29d): ca>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (veth838a45a): >
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (vethceefdc0): >
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (vethceefdc0): ca>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (vetha7e8c55): >
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (veth9fb97f0): >
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (veth9fb97f0): ca>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (vethb65a8e8): >
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (veth607a23d): >
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (veth607a23d): ca>
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (vethcc2f29d): carrier: link connected
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (veth838a45a): new Veth device (/org/freedesktop/NetworkManager/Devices/17)
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (vethceefdc0): new Veth device (/org/freedesktop/NetworkManager/Devices/18)
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (vethceefdc0): carrier: link connected
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (vetha7e8c55): new Veth device (/org/freedesktop/NetworkManager/Devices/19)
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (veth9fb97f0): new Veth device (/org/freedesktop/NetworkManager/Devices/20)
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (veth9fb97f0): carrier: link connected
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (vethb65a8e8): new Veth device (/org/freedesktop/NetworkManager/Devices/21)
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (veth607a23d): new Veth device (/org/freedesktop/NetworkManager/Devices/22)
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (veth607a23d): carrier: link connected
ha dns info
Raspi:~$ sudo ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals: []
mdns: true
servers: []
update_available: false
version: 2023.06.2
version_latest: 2023.06.2
@Raspi:~$