SPDX-License-Identifier
CC-BY-SA-4.0
I have a small set of smart switches (Z-Wave) controlling mostly lamps. I'm currently using Domoticz (version 2.0.2276) as the control software. This is seriously back version, because the Z-Wave integration was kicked out of version 3.x due to a political issue, which I take to be that Z-Wave is proprietary and its library is not 100% open source. However, modern (2022) Domoticz once again has Z-Wave support.
One of my switches died. I was not able to get the replacement to be recognized by Domoticz, i.e. paired with the Z-Wave controller. [In hindsight, this was my fault, not Domoticz's.] I have been meaning to replace Domoticz with something upgradable and I decided that now is the time. After research I decided on Home Assistant.
These jargon words are used in Home Assistant documentation:
Home Assistant. The package basename and the core executable program are
hassabbreviating Home Assistant.
Devicesalso occur such as a weather reporting service.
onor
off. Must be binary, or at least an enumerated type.
home automation hub.
Protocolrefers to the frequency, modulation, packet format, etc. of the particular communication Device. Presently popular protocols for home automation include Wi-Fi (IEEE 802.11 family), ZigBee (IEEE 802.15.4), Z-Wave (proprietary), and Bluetooth (IEEE 802.15.1).
The probable market leading home automation software packages are Amazon's Alexa, Google Home, Apple's HomeKit, or various other closed source items. I'm rejecting them out of hand due to privacy concerns; specifically:
So a hard requirement for jimc is open source software with local hosting
of everything. A Google search for home automation comparison
in 2022
reveals that current interest is focused on: (product names link to their
home sites)
Home Assistant.
I'm using the abbreviation 'H-A' frequently, and Hass
is the
name root of the package.
September 7, 2021, by JOSNA on ElectronicsHub.
OpenHAB is in Java. Inception 2010. Advantages: It has a lot of extensions. It supports zillions of devices, communication protocols, etc. It runs on all kinds of UNIX, and Microsoft Windows. Among the comm protocols are ZigBee (IEEE 802.15.4) and Z-Wave (proprietary). The author rates positively the documentation and user community.
Drawbacks: Because OpenHAB does so much, the user needs to do a lot of
work to learn it all. The author warns that you need prior
knowledge
for hassle-free usage. Updates require the command line.
It's a memory pig; a Raspberry Pi 3 (1Gb RAM) may run out of memory.
Home Assistant is in Python-3; Apache-2.0 license. Inception 2013. Advantages: It can federate with Google Assistant and Alexa. (Jimc believes OpenHAB can do this also.) Software distribution from GitHub. Flexible and customizable automation rules. One click updates. Good documentation. Active user community.
Drawbacks: Case sensitivity and configuration syntax can trip you up.
New users may find it overwhelming at first.
Author's evaluation point by point:
| Aspect | OpenHAB | Home Assistant |
|---|---|---|
| Configuration: | OpenHAB takes 20-30 minutes, good documentation. | H-A during setup can discover all existing devices. (Jimc says: configure Z-Wave radio first.) One-click installation, so they say. Good docs. |
| Updates: | OpenHAB is complex and time consuming; looks like the update is installed like an add-on package. | H-A: just click a button on the UI. |
| Supported devices: | OpenHAB supports 792 kinds of devices from 111 vendors. | H-A has about 1400 componentspresumably meaning supported devices. |
| Automation rules: | OpenHAB extension language. | H-A has a choice of 2 extension languages. |
| User Interface: | OpenHAB has one. | H-A is praised by the author for having a UI that is more user friendly and less complex than OpenHAB. |
| Mobile App: | OpenHAB has them for iOS and Android; it is
easy to use and user-friendly. | H-A is similar but the author says it's slightly less developedthan OpenHAB. |
| Add-ons: | OpenHAB has extensive add-ons, e.g. Twitter notifications. It can use several databases including MySQL but not PostgreSQL. | H-A has fewer, and the only ones I recognize are the DHCP server and Git puller. Other articles mention a lot more add-ons for H-A. No database engine is mentioned. (From docs: SQLite is the default but MySQL/MariaDB can be used for big systems.) |
| Conclusion: | OpenHAB is more customizable at the cost of a steeper learning curve. | H-A is easier to use and to set up, particularly for the beginner. |
Jimc's conclusion: I should give serious consideration to Home Assistant.
By Alex Brice, February 28, 2018, on Smart Home University.
We have selected Home Assistant as the overall winner. This is due to
a number of reasons, but more powerful automation engine, friendlier UI,
more powerful integrations and stronger community being the main ones.
Saying that, OpenHAB has a number of winning aspects and the victory was
only by a thin margin.
(In 2018.)
Updated in 2022-05-xx: He has continued with H-A and has $2K of smart devices and over 100 automation routines.
He has a lot of very detailed comparisons of different aspects such as the automation languages (Xtend vs YAML). His overall winner is still H-A.
By Lewis Barclay, Aug 20, 2020, on Everything Smart Home.
This author's take on the two programs is similar to previous authors. They have good and bad points, but H-A's ease of use makes it the winner for him. As for stability, H-A has never failed him (in about 2020-2022, 1.5 years) except once he filled up his disc with something. He doesn't have the long term history with OpenHAB so he can't really rate its stability.
He gives a link to his set of articles Getting Started with Home Assistant. Their main focus is on deploying the pre-stuffed image on Raspberry Pi.
by David C, 2020-04-16, on SmartHome Blog.
He recommends putting the winning software on a Raspberry Pi. Jimc is not taking that advice; Jacinth, my main router, an Intel NUC6CAYH (Celeron), runs 24/7 and does a lot of this kind of service in my house.
Installation: OpenHAB is very easy, particularly on the pre-stuffed
RPi image called OpenHabian. 20-40 minutes work. H-A is also easy, only
10 minutes using their image. Domoticz is slightly less
straightforward
because there's no image.
Configuration: A pox on all their houses! For OpenHAB and H-A both, you will be stuck editing files, so he says. Domoticz can be configured with the web UI, but it's not very intuitive, he says. [Jimc note: I got my Home Assistant configured without editing files, only snooping to see what they were doing.]
Flexibility: Similarly, he rates all three poorly.
Community of Users: OpenHAB's community is the most active and most helpful. H-A's community is growing (jimc says: likely this comment is from before 2020). Domoticz has substantially fewer users than the other two.
Pace of development: Author concentrates on adding new devices.
OpenHAB is quite slow
because of a rigorous approval process, which
helps stability. H-A is much faster (and sometimes the integrations have
bugs). Domoticz definitely lags behind.
Automation: OpenHAB can do anything you want, but the Xbase syntax
is not the easiest one to deal with.
H-A's YAML is by far
worse
. Domoticz uses LUA which I find very clean and powerful.
But he says learning Python is probably a lot more practical than
learning LUA.
Conclusion: Domoticz users are moving to OpenHAB or H-A. H-A is developing fast and the UI is going to have a good WAF (Wife Acceptance Factor). OpenHAB is amazingly flexible. If you don't mind a slightly steeper learning curve, OpenHAB is the way to go.
From the first posted comment that caught my eye, by Philip
(2020-03-21): Hi There! I have tried OpenHAB some times ago, and the
main thing that makes me change to another one is: JAVA. If all is going
nice it's OK don't touch the f…ing working thing! But it's always so
complicated, so heavy, so hard to tweak, so hard to understand why it's not
working.
I think I have a feel now for the available products, and can stop reading blog posts.
Years ago I installed Domoticz-2.0 for OpenSuSE Tumbleweed off a SuSE community repository, and I was planning to do the same this time. Available packages for Tumbleweed on OpenSuSE at the time of writing (2022-12-xx) are:
My evaluation of the three candidates goes like this:
To install Domoticz you just install the package and its dependencies. H-A is not so simple; it is designed for both security and maintainability, and the kind of cowboy programming that I followed with Domoticz is not going to cut it. H-A has four levels of installation, ordered from easiest to hardest, all but one of which I tried (in reverse order):
Home Assistant Operating System: You have a dedicated chassis, typically a Raspberry Pi or an Intel NUC, or you have a dedicated virtual machine (first item from the Linux option on the install page). You install their image on it. In ten to twenty minutes you have what amounts to a network appliance analogous to the controller hubs of the commercial products. You can now proceed to add your home automation Devices. Hacking the operating system is discouraged.
This is the mode I ended up using.
Home Assistant Container: They have images for these virtual
machine frameworks: VirtualBox, KVM (what I use), and VMware. They
also have an image for any
OCI compatible runtime
,
of which Docker has the most name recognition. The image includes Home
Assistant Core (and has the same limitations). This is the only
mode I didn't try.
Home Assistant Core: It does not run in a container or a virtual machine. You create a Python Virtual Environment into which you install the Home Assistant Core. (Here's a good tutorial on Virtual Environments. Basically special or back-version modules and tweaks are visible only in the Virtual Environment.) This looks like the best fit for me, because I can use my preferred distro (OpenSuSE Tumbleweed) and maintenance methods, yet can adapt to their special package requirements and version control. Also I don't have to deal with importing USB devices into a virtual machine. [Famous last words…]
On the Installation page, click on Linux
, then scroll down
to Home Assistant Core. I got it working
, until I started
configuring Entities.
The problem here is that Home Assistant Core can't do add-on packages, and Z-Wave support is an add-on. The key issue appears to me to be that add-ons are like daemons, running in a separate thread, which are started and controlled by the H-A Supervisor (similarly to how it supervises H-A Core), so you need to use the first or fourth installation modes, that include the Supervisor.
Home Assistant Supervised: You run their Supervisor on your OS. Which must be Debian; Ubuntu and Raspberry Pi OS (formerly Raspbian) are not supported, and neither is SuSE. This is basically what I was trying to do, failing. I'm not sure how strict is the Debian dependence, but they will not consider bug reports unless they can be reproduced on an unhacked Debian OS.
I found this useful discussion comparing the major communication protocols for home automation: ZigBee vs Z-Wave vs WiFi (OP CO_4x4, 2021-12-xx). He's doing an upgrade and refurb campaign on his IoT Devices, and wonders if changing the communication technology might be a good idea. He got 130 responses. The consensus is that each has its strengths and weaknesses, and the environment makes a difference too. Almost nobody uses a single technology. But here's kind of the majority opinion:
ZigBee is the least expensive. But this sometimes means that you're getting low quality implementations. ZigBee uses the least power of the three, so people prefer it for battery powered Devices. ZigBee communication is more stable than the others (different people's mileage varies a lot though). But it suffers from interference from Wi-Fi (both are in 2,4GHz), which can be mitigated if you pick the two services' channels so they don't overlap, e.g. Wi-Fi channel 11 doesn't overlap ZigBee channel 11 (actually 11-17). Also Wi-Fi channel 1 doesn't overlap ZigBee channel 19-26, and Wi-Fi channel 6 misses ZigBee 11-12 and 24-26.
Z-Wave is older technology and available Devices are declining. (Insteon is even older and more faded.) It has a lot more rigorous certification requirements, so interoperability between vendors is almost 100%. But the products are the most expensive. They use more power, so people tend to go with ZigBee for battery powered Devices. People with a lot of Z-Wave Devices say that their net has slowed down and become less reliable. The operating frequency is 908.42MHz in the USA, 868.42MHz in Europe, and various others elsewhere. Watch out that you get a product compatible with your regulatory domain. This frequency range penetrates walls better than 2.4GHz Wi-Fi.
Wi-Fi generates a lot of strong opinions pro and con. Jimc noticed that the vast majority of IoT devices on Amazon are Wi-Fi, ZigBee is second, and there were only 3 or 4 Z-Wave Devices. It needs more power than ZigBee so people avoid battery powered Wi-Fi. Older access points and NICs have a small peer table, a problem if you buy a big swarm of Devices. An advantage is that everyone already has a Wi-Fi NIC, access point, or both, while with the other two you need a dedicated NIC for each protocol. ZigBee and Z-Wave use mesh technology, giving better coverage to the whole house, but Wi-Fi doesn't unless you put in dedicated repeaters. Many Wi-Fi Devices connect to a cloud server, which the controller also connects to, and many respondents discussed cases where the cloud server got discontinued. Cloud entanglement is also a privacy issue. (Jimc: my Honeywell thermostats are like this, though not discontinued yet.) There is a new standard called ESPHome which enables local control. The Tuya product line was also mentioned as easily controlled locally.
Only one response mentioned Bluetooth. Jimc has seen Bluetooth door locks, but that's all.
There's a new technology on the horizon called CHIP/Matter which will supersede all of these, so some people say. In 2022-12-xx (a year after this forum post) there are actual Devices available that use it.
The article doesn't say anything about layer 1 protocols, i.e. the operating frequency, but the presence of ZigBee in the alliance suggests that 2.4GHz Wi-Fi and IEEE 802.15.4 are likely to be included. Several devices including hubs were mentioned as having received firmware updates that added support for the Matter protocol.
The first step is to configure a virtual machine (KVM) for it to run on. Why don't I use the H-A Container image, you ask. Because I absolutely require add-ons: all my Devices are Z-Wave, with an Aeotec Z-Stick Gen5, which has official and community drivers in the form of add-on daemons, and H-A Container can't do add-ons. In forum posts, respondents often point out that add-ons frequently are available as Docker images and this is the way to go if you're running the Docker image of H-A Container. But I have no experience with Docker and I'm already leery of H-A Container on Docker, and I'm even more leery of add-ons on Docker. Therefore the next try is going to be H-A Operating System in a VM .
Here is the generic procedure to set up the VM. The following is From the H-A Installation page; follow the Linux link. Steps:
The new VM's name will be Dragon.
Do the research to pick the chipset and firmware of your VM. Which chipset should I use? See Virtual Win10 — i440FX vs Q35 by Gordan Bobic (2022-01-05): QEMU supports these two for x86_64. i440FX is from 1996 while Q35 is from 2007, but there's an urban legend of bugs in GPU passthrough on Q35. Gordan tested CPU usage on both (but not the urban legend). Windows being idle used about 3/4 the CPU on Q35 vs. i440FX (7% of elapsed, oink). Other forum posts describe working VMs involving Q35 doing GPU passthrough. Jimc is going to stick with Q35.
About the firmware: QEMU — Which Firmware to use, OP kitman (2021-07-xx) has a
good discussion of which one to use. The ones including the string
ms
include Microsoft signing certs, opensuse
is for
Tumbleweed and Leap, and suse
has SLES certs. The ones without
a vendor name have no certs and will fail Secure Boot unless you import
your own cert. The KVM image already has Secure Boot turned off. If
the kernel is signed at all, it's by either a Debian or a H-A cert,
neither of which you have. So don't confuse yourself with Microsoft or
SuSE certs.
In a previous failed attempt during UEFI booting, I got a message:
BdsDxe: failed to load Boot0001 UEFI Misc Device
from
PciRoot(0x0).Pci(0x2,0x3)/Pci(0x0,0x0): Access Denied
I tried pressing any key to enter the Boot Manager Menu.
We have a Standard PC (Q35+ICH9, 2009), pc-q35-7.1, 2.0GHz, 2048Mb RAM.
Under Device Manager, the first category is Secure Boot Configuration.
Current Secure Boot State: Enabled. Not a good sign if we have no
certs. Next item is Attempt Secure Boot; I un-checked this. It says,
please reset the platform to take effect!
Hit escape until back
on the main page. Reset
is the last item. And the sucker
booted! (But there were other issues and I had to start over from
the beginning.)
Download https://github.com/home-assistant/operating-system/releases/download/9.4/haos_ova-9.4.qcow2.xz (use the link on the Linux install page to get the current version). 0.34Gb, download took 71sec. Decompress it: xz --decompress --keep haos_ova-9.4.qcow2.xz ; Output 0.97Gb, took 20 sec. Rename to dragon-disc1.qcow2 .
Start up the virt-manager GUI (no command line arguments).
Import Existing Disk Image.
Current Memoryto 1024Mb.
I hit Begin Installation
. It started virt-viewer, The
TianoCore logo was shown (Intel's open source EFI booter). Wonder
of wonders, it booted promptly (evidently Secure Boot is turned off
in the image), showed reasonable messages, and
started the H-A CLI and the supervisor, which started H-A core. It
got its assigned IPv4 address, but an aleatory IPv6 address. (I
expect I'm going to have to jailbreak the master instance to fix this.
Update: rather than fixing it, I statically assigned the correct IPv6
address in the Settings page for System/Host.)
It has opened HTTP service on ports 8123 and 4357. The
latter is labelled the Observer URL
. 8123 has the expected
H-A screen to create the administrator account. 4357 has a simple
health monitor display: supervisor connected, configuration supported,
system is healthy. On the console you can type commands to the CLI,
which supposedly can do everything the GUI can, and possibly more.
It took about 3 minutes from the start command until port 8123 was
giving HTTP service.
Now with Dragon booting, I need to make progress on two items:
Steps to set these up:
In a previous attempt I started the VM and got this error message:
qemu-system-x86_64: -device
{"driver":"usb-host","hostbus":1,"hostaddr":14,"id":"hostdev0","bus":"usb.0","port":"2"}:
'usb-host' is not a valid device model name.
Arch Linux forum post about the same problem (OP ghost82, 2022-05-05). V1del (moderator) says it's likely in an add-in package; try qemu-hw-usb-host.
qemu-hw-usb-host is also the name on OpeSuSE. (But in the SuSE package searcher you need to specify qemu-hw; plain qemu didn't match it for some reason.) I installed it. Now the error message is gone.
URL of a tutorial on how to pass through a device. I'm going to use virt-manager to do this. Steps:
Exiting from virt-manager. Starting the VM (virsh start dragon). I wonder if the USB passthrough happened? For that, I'll need root access. There's an add-on package for this in H-A. [Confirmed later that the Z-Stick is visible to the guest because the Z-Wave integration is able to talk to the Devices.]
Now that we have a domain definition that can be booted, we need to save the domain XML and the NVRAM. To do this (in /s1/kvm/dragon/):
If you need to undefine and redefine the domain, this is the
procedure. undefine
needs the --nvram
option to give it
permission to toss the former NVRAM contents.
Onboarding: Configuring Home Assistant
Follow the Onboarding link to start configuring. (Except the Home Assistant Core section doesn't have one; follow from another section, or use the link here.)
It wants you to create an account for your administrator. This
is not a system account; it's by and for H-A. I'm assuming that
Name
is like a full name and Username
is like a loginID.
Google search for Does Home Assistant hash passwords?
shows
a statement in the docs that it does so. I'm going to use H-A
Administrator
as the Name and homeauto as the Username, and
something random (which I'll keep in Bitwarden) as the password.
Later I'll create a different user account, shared by everyone in the
family.
The next page is to set your locale. I was successful using their button to detect it. It correctly identified my country, language, timezone (America/Los_Angeles), unit system (peasant) and currency.
On the map it showed me the point of physical presence of my ISP
(in San Francisco). To get the correct sunrise and sunset times,
which I use, you need to move the pin. The map can be zoomed;
diagonally drag the desired zoom center (the pin) to show a (much)
larger area. Drag
means here to move the cursor to the desired
center, hold down the left mouse button, then move the mouse. Now
double click on the pin, holding the left button down after the second
click, and drag it near your actual location. With a similar double
click or two finger drag in the map background, re-center the pin.
Re-zoom the map, showing a smaller area. Repeat until the pin is in the
living room of your house: the map is that detailed.
When you hit Next it takes about 15 secs to get to the next page.
Next it asks about (anonymized) information sharing. I'm a paranoid troglodyte: no basic analytics, no usage, no statistics, yes diagnostics (crash reports).
Next it shows integrations that could be relevant for you.
They say don't be alarmed
if you don't have very many. You can
configure them here or do later (recommended by jimc). I had these
integrations:
Moreand waited. It greyed out everything. It might be doing network auto detection (or might not). I gave it 10 mins; no action. Still nothing. So I rebooted Dragon.
Rebooting takes about 3 min until the webserver gets alive.
I'm taking some recommendations from
Getting Started with Home Assistant (part 2)
by Lewis Barclay (2019-09-21). Click your username in the lower left
corner, opening your profile, and give yourself administrator
privileges, called Advanced Mode
in H-A.
Yes we are using Hass.io and need SSH. Here's how to install an
add-on. Evidently since Getting Started with H-A
was written,
the GUI has been reorganized; here's a modern translation of the
procedure for version 9.4 (2022).
Add-On Store(lower right corner).
Getting Started with H-Ashows the Repositories section; if you need this (I didn't) you can open it via the dotdotdot menu, upper right corner.
Officialadd-ons are maintained by the H-A developers whereas
Communityadd-ons are from outside. Specifically the
officialAeotec Z-Wave add-on is in the Community section. But we're doing SSH now.
Terminal and SSH. and the community one titled
SSH & Web Terminalby Franck Nijhof, The official one has security features which, in my case, prevented it from starting up. In forum posts reporting this issue, the consensus is to use the community version. It includes various net tools such as curl and wget. Default shell is ZSH. It's advertised to give real root access (which the official one doesn't).
echo dragon > /proc/sys/kernel/hostnamebut we're running in a Docker container and it's mounted readonly.
jailbreakthe host system.
Next is going to be installing the Z-Wave add-on. But which one,
the official
one or the one from Aeotec? This
H-A Community Guide about Z-Wave Integrations (by Petro,
2021-02-xx, updated 2022-09-xx) looks useful. These schemes are or
were available:
He/they recommend the official add-on and integration. The Aeotec
add-on has a GUI that lets you do various actions that the H-A
Zwave JS integration cannot perform.
The one with MQTT integration
is listed after these two. Comments seem to suggest that if you have
the MQTT broker installed and are using it for something else, using
it also for Z-Wave makes sense, but otherwise don't add this
complexity.
I think I'll use the official add-on and integration, until I hit some problem that requires the GUI to unscramble, not likely on my simple net. (Famous last words.)
Continuing with activating Z-Wave:
Success!and a list of cards for Entities some of which have believable names, starting with the Z-Stick. Each could be assigned to an area. Evidently it's using security keys stored in the Z-Stick. The next challenge will be to figure out which is which, and to rename them. Close this box.
Interruption: How to pair and un-pair a device from the Aeotec Z-Stick Gen5. See the Users guide for Aeotec Z-Stick Gen5+ (very similar to Gen5). To pair a device:
onbutton once on the device. (But some devices have unusual rituals like double tap.)
My goal in this step is to change the names of the Devices to match their functions.
Switch 1. Click Update when finished. There is a confirmation box asking if you want to similarly update the names of its Entities. Generally you would say yes.
Re-Interview. In my first attempt the resulting box said
Re-interview failedafter 1-2 minutes. Nodes 5+6 took a long time (1-2 mins) to fail; nodes 7+8 failed in 15sec, suggesting that they are actually on the net while 5+6 are missing.
Remove-Failedon all the dead nodes. Node 5 would not go away because it was responding to ping. The rest are gone. I tried to Add Device (from Settings - Devices & Services - Devices tab) - Add a Z-Wave Device). It circulated for quite a while but found no new devices. The message says
Make sure the device is active and in inclusion mode.
remove failed, and plug it in again. But Add Device didn't find it. Wrong! It has appeared! I renamed Node 5.
Creating automations: The ones I want are:
How to create an automation: All of these are similar, and simple.
You can make really complicated ones, like If jimc's cellphone is
pingable (because it's at home and is on Wi-Fi, implying that jimc
himself is at home), and if it's less than half an hour to sunset (or
after sunset), at 18:00 turn on all the kitchen lamps
. Steps to
create the circulating pump turn-on automation:
Home Assistant Core Integration Generic Turn-on, a script, or a switch. Of these, the generic turn-on and the switch worked.
It's stupid to try to jailbreak H-A OS; I really should make H-A Supervised work in my own context. I'm sure there's no actual dependency on Debian, just that the developers can't deal with a zillion idiosyncratic distros with version skew on everything.
Orion is my name, IP addresses, etc. for a machine that I'm setting up. My plan is to create a new VM on Jacinth under this name, install H-A on it, (shut down H-A OS on Dragon), restore my backup and see that it works, and then rename it to Dragon replacing the old one. The first step is to clone Dragon's VM as Orion. documented in a separate writeup,
Home Assistant installation on Linux. Find the Home Assistant Supervised section at the bottom. Check out the requirements, then proceed to the installer documentation. Remember that we have (or should have) SuSE's tweaked home-assistant package already installed.
Bullseye(no Ubuntu, Raspbian, etc). Bug reports are not accepted when it's installed on other OS's. Blow this one off.
They require these additional items:
The H-A-Supervised installer. Following along in the instructions:
Install these dependencies using apt-get. All are installed or
available in the official Tumbleweed repo, and have acceptable versions
(indicated in parens). '*' (including on need to install
notes)
means that this item is now installed.
network-manager.
Bullseye. Need to install*.
However, overnight the OpenSuSE H-A repo got out of sync between the home-assistant's version required for python310-bcrypt and the available version of that package. I'll continue with a shotgun wedding of versions, but will sync this up as soon as the repo is straightened out.
systemd-journal-remote is installed. It's an official part of systemd. It provides systemd-journal-gatewayd, including systemd units for its socket and its service. hassio-supervisor.service starts both when the supervisor is started up. docker.service has to be started separately, i.e. not as a dependency of hassio-supervisor. These units need to be added to /m1/custom/scripts.extra .
Likely firewall involvement: systemd-journal-gatewayd.socket uses port 19531/tcp. There's a manpage. However, H-A wants to write journal records to the socket, not the port.
Supported hardware is generic x86_64; qemu for arm, arm-64, x86, and x86-64; Raspberry Pi 2 to 4, and various other ARM boards including odroid, Get the image appropriate to your architecture: in my case, generic x86_64.
Configuration data is in /usr/share/hassio . In Debian this can be tweaked, but I don't think you can do that in SuSE (RPM).
I should be able to just start it up, but the H-A package
does not provide a pre-made systemd unit. I'm pretty good at writing
systemd units, but it's best to use theirs because I won't know all the
run-time dependencies. I downloaded the DEB package,
used alien
(package alien
) to convert it to a TGZ file,
and discovered three
systemd units: /etc/systemd/system/hassio-supervisor.service ,
/etc/systemd/system/hassio-apparmor.service ,
/usr/lib/systemd/system/systemd-journal-gatewayd.socket .
Snooping further, I found /usr/lib/systemd/system/home-assistant.service
(from the H-A package, with an alias of hass.service) but nothing like
hassio-supervisor. After inspecting, I copied hassio-supervisor.service
and hassio-apparmor.service into /etc/systemd/system/ and added them
to /m1/custom/scripts.extra. I also found
/usr/lib/systemd/system/systemd-journal-gatewayd.{socket,service}
from package systemd-journal-remote. I didn't overwrite these with
the one from the deb package. However, they do have differences:
gatewayd.socket: Debian listens on 19531/tcp while SuSE opens
/run/systemd-journal-gatewayd.sock; Debian doesn't have gatewayd.service
while SuSE does.
Instructions about configuring systemd-journal-gatewayd per the Requirements page: it should listen on /run/systemd-journal-gatewayd.sock which SuSE's systemd-journal-remote already does. And hassio-supervisor should have permission to write on this socket. But there's got to be some way to tell it where to send the log messages to. My preference is dom0 of Orion/Dragon, i.e. the operating system outside of Docker.
Following instructions in the Requirements page to configure Docker. They say it should use overlayfs2 storage, journald as the logging driver with Container name as the Tag, and cgroup v1. The SuSE package puts basic setup info in /usr/share/doc/packages/docker/README_SUSE.md .
I found these items in the docker package: /etc/docker/daemon.json
What is a Docker Image? An Image has a name. A Container is a running Image; it has an ID. A Tag is a string associated with an image, e.g. designating a specific version of that image.
Docker security is described here.
libvirt includes libvirt-daemon-driver-lxc which should enable you to manage Docker containers with libvirt tools like virsh.
To set the storage driver (they want overlayfs2), edit
/etc/sysconfig/docker, value of DOCKER_OPTS, and insert
-s overlayfs2
. The storage ends up in /var/lib/docker .
The docker service (daemon) should start at boot. They provide a systemd unit for it. Root, and members of the docker group, can communicate with this daemon over a socket.
When containers communicate on the net, this is considered to be forwarding to the host (dom0), so the host's net.ipv4.ip_forward needs to be true (in sysctl). Look on Xena for how to make this work with NetworkManager. About Docker's bridge networking. Each (net-connected) container has an IP address (which it gets from where?) There is a default bridge, but it's recommended to configure a separate bridge explicitly. A newly started container connects to the default bridge, unless suppressed or directed to a user-defined bridge.
Docker has a lot of man pages, but e.g. man docker-config
tells you to run docker config --help
to see the help, which
is skimpy.
Both overlay and overlay2 are currently unsupported on btrfs or
any Copy on Write filesystem and should only be used over ext4
partitions.
You should use the btrfs driver instead. So what
should I do? First, dig into the H-A OS image and find out what they
are doing, specifically what filesystem is on the root. I'm
probably going to have to revert Orion to ext4 after all that work
activating btrfs. If I want to keep a demo system with btrfs,
let's convert Petra to become a clone of Orion.
And we have to switch from Wicked to NetworkManager.
Once you have H-A running and listening to its web port, you can proceed to Onboarding (the link points to that section earlier in this document). This procedure includes a step to upload the backup of the existing H-A.
I made progress in the effort to get H-A Supervised running on Orion, but as they warned, that project was turning into a time sink. When I found by accident during a software update of H-A OS that it was doing a Debian update as well, that dispelled my major objection to using H-A OS, and I decided to live with that (and turn my attention to another high priority item). H-A OS is performing reliably for me, and my needs are modest, so Dragon with H-A OS now has a permanent place on my main router Jacinth.