Skip to main content

Installing Home Assistant Supervised on an old 32bit HP laptop

 I've received a challenge from my former boss: an old HP laptop that was born in 2005:  an HP-Compaq NC6220 (https://www.pocket-lint.com/laptops/reviews/hp/68181-hp-compaq-nc6220-notebook-laptop/). The specs are abysmal:

So, i386, 1.7GHz single-core CPU (remember those?), 1G of DDR2 RAM (2x512M) and a 40GB ATA (not SATA!) drive. But hey, at least it has a serial port!

 The challenge is to install HomeAssistant (https://www.home-assistant.io/) on it so that he can monitor some Zigbee temperature sensors and relays (via a gateway).

The first hurdle was to remove the BIOS password - following this nice guide: https://www.youtube.com/watch?v=ZaGKyb0ntSg

Next-up - install HASSOS. Unfortunately, it doesn't support i386, but only x86_64...

So, I went the Home Assistant Supervised route, and installed Debian 11 i386 edition from a netinstall USB (https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-11.6.0-i386-netinst.iso). 

 Once Debian was up and running (didn't take that long), I tried this guide to install Home Assistant Supervised: https://community.home-assistant.io/t/installing-home-assistant-supervised-on-debian-11/200253

 The guide is pretty thorough, but it assumes you're running 64bit, so you need to make some adjustments.

For instance - in step 2.1 - you need to install docker from:


curl -fsSL get.docker.com | sh

Well, that won't work, because docker.com offers only docker builds for x86_64 on Intel. We need 32bit docker!

Fortunately, Debian has us covered!:

sudo  apt install -y docker.io

Next, in step 2.2 you need to install the latest os-agent release for i386 from here: https://github.com/home-assistant/os-agent/releases

 Step 3.1 is almost the last step. You now need to install Home Assistant via docker. The installation comes as a deb package that you need to download and install:

wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb

Unfortunately you won't be able to install it because it depends on docker, but you have docker.io installed instead. 

The elegant way to do it is to unpack the deb file, edit the dependencies and repack it (https://coderwall.com/p/hes3ha/change-the-dependencies-of-a-deb-package):

mkdir changed-deb

cd changed-deb

wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb
ar x homeassistant-supervised.deb
tar xJf control.tar.xz
sed -i 's/docker-ce/docker.io/' control
tar c {post,pre}{inst,rm} md5sums control | gzip -c > control.tar.gz
ar rcs homeassistant-supervised-dockerio.deb debian-binary control.tar.gz data.tar.xz
dpkg -i home-assistant-supervised-dockerio.deb
 

Now, the installation should work and after a while you'll be prompted to reboot. Do so now, and then wait for the docker packages to install and you should be able to access you new Home Assistant instance at http://homeassistant:8123/

But, for me, there's still a problem. I have 100% CPU load (on my single, underpowered CPU) and it's because of pulseaudio?!

docker stats confirms that one of the HASSIO containers is the culprit:

 Apparently there are several ways of working around the problem, and pulseaudio is known to be misbehaving... I implemented this fix: https://github.com/JJFourie/HomeAssistant-PulseAudio-Disable (with a few small changes for the file path and the user) and what is this I hear? Not the leaf blower sound made by the CPU fan anymore, that's for sure!

 Here's how the system looks once things have started up:

root@compaq-nc6220:~# docker ps
CONTAINER ID   IMAGE                                                    COMMAND   CREATED         STATUS         PORTS                  NAMES
27502e6f38bd   ghcr.io/home-assistant/i386-hassio-multicast:2022.02.0   "/init"   2 minutes ago   Up 2 minutes                          hassio_multicast
a0a5a10052ce   ghcr.io/home-assistant/i386-hassio-audio:2023.04.1       "/init"   2 minutes ago   Up 2 minutes                          hassio_audio
b0f7d5256909   ghcr.io/home-assistant/i386-hassio-dns:2022.04.1         "/init"   2 minutes ago   Up 2 minutes                          hassio_dns
63e0e8fbcacf   ghcr.io/home-assistant/i386-hassio-cli:2022.11.0         "/init"   3 minutes ago   Up 2 minutes                          hassio_cli
bc3027a7ac3c   ghcr.io/home-assistant/qemux86-homeassistant:2023.4.6    "/init"   24 hours ago    Up 2 minutes                          homeassistant
a8a3fc080bd7   ghcr.io/home-assistant/i386-hassio-observer:2021.10.0    "/init"   24 hours ago    Up 3 minutes   0.0.0.0:4357->80/tcp   hassio_observer
a730c28e210e   ghcr.io/home-assistant/i386-hassio-supervisor:latest     "/init"   24 hours ago    Up 3 minutes                          hassio_supervisor

Not bad for an aging piece of hardware, unfit to run Windows 7. Glad I saved another one from the dump.

I'd like to thank HomeAssistant devs and contributors, for keeping the i386 architecture alive. I assume there are still a ton of old devices which can be repurposed for a new "server" role and can live again.


 

Comments

Popular posts from this blog

Home Assistant + Android TV = fun

Here's a quick setup guide for controlling your Android TV from within Home Assistant. I've used it to control a genuine Android TV (Philips 7304) and an Odroid N2 running Android TV. For this to work you need ADB access. It can usually be enabled from within Developer Settings. The great part is - you don't need root access! The most important things are described in the androidtv component for Home Assistant: https://www.home-assistant.io/integrations/androidtv/ Make sure you go through the adb setup. My configuration is simple (inside configuration.yaml): media_player:   - platform: androidtv     name: TV Bedroom ATV     host: 192.168.1.61     device_class: androidtv Once Home Assistant restarts, your TV might require you to accept the connection (adb authentication). This happens only once (or until you reset your ATV to factory settings). Once running the integration will show you the current ATV state (on or off) and allows you to turn it on or off.

SmokePing + InfluxDB export + docker + slaves + Grafana = fun

I've been working for a while on this project - with the purpose of getting SmokePing measurements from different hosts (slaves) into InfluxDB so that we can better graph them with Grafana. The slaves run multiple Smokeping instances inside Docker so that they have separate networking (measure through different uplinks, independently). This will not be a comprehensive configuration guide, but a quick "how to" to handle setup and basic troubleshooting. It assumes you already know how to set up and operate a regular Smokeping install with or without slaves and that you are fluent in Smokeping configuration syntax, know your way around Docker and aren't a stranger from InfluxDB and Grafana (sorry, there's a lot of information to take in). 1. Getting Smokeping with InfluxDB support - you can get it either from the official page (most changes have been merged) - https://github.com/oetiker/SmokePing (PR discussion here: https://github.com/oetiker/SmokePing/issues/