I would like to spend my time on things funnier (for me) than maintaining a HassOS fork.
This seems “almost” what HassOS already does. “Almost”, but leaving me free to add my Linux software and scripts. It seems a good alternative to an Alpine HassOS addon - or “Alpine as a Service”.
IMO this is less funny than 1.
Thanks again, I will report on Alpine + docker + Hass* experiments on my PI4, trying to spot pros and cons vs the HassOS precooked solution.
Do you think copy and pasting one line of code once a month or so if difficult? It seems you are going to a lot of extra work to avoid doing a monthly update of the underlying OS.
If you wanted to avoid the 30secs it takes to copy/paste the one line of code you need to perform an update, you could set a cron job to run instead.
@kanga_who
in my experience updates/upgrades are critical steps, there isn’t guarantee they go always flawless. And this is why I stay away from automatic updates if there isn’t some automatic fallback.
They may work without a glitch for months then fail unexpectedly, as in the world there aren’t other Linux installations identical as mine.
I knew top-salary corporate SysOps who, after a dramatic Vulnerability Assessment, prefer to not update some critical systems to avoid the risk of outages and domino-effects. They may be wrong, the net is full of debates on this topic.
Until I organize some High Availability that just works, the HASS server is a critical single point of failure of the whole home security, safety, automation.
Willing to avoid failures as much as I can, in the first post I proposed a pseudo High Availability (rsync+keepalived) backed up by a quick manual recovery solution (rpi-clone).
Paranoic? Lazy? Maybe yes, but I would like to spend my time on funny things, not OS troubles.
Piero
@kanga_who
I fully agree, but it’s my house, not a corporation, so I accept some compromises.
My HassIO setup, together with other servers, is now running on a couple of I7 notebooks I’ve laying around, using a replicated+redundant HA file-system (GlusterFS).
I tried the GlusterFS file-system also on a small pile of PI4, and it was acceptable.
Meanwhile those i7 are fruitlessly excessive and noisy.
I’m trying the PI4 and even if its CPU is 100x slower than an I7 (BogoMIPS), I’m impressed by the fairly good HassIO performances on it. That’s thanks to the huge increase of RAM (1G->4G) and decent performances of the PI4-4GB loaded with almost only HassIO. HassOS performs even better, thus my interest on it.
Before someone asks, I don’t do 4k-streaming/encoding/decoding, and would not do it on a SBC.
Yes, sure enough, I woud use at least 2 PI4
Joking aside, maybe I will choose NUC instead of SBC.
However, wIth a passive heatsink PI4 are quiter, use less 24*7 energy, costs less than a single I7/NUC (and for a minimal backup I would need at least two), and give to me a similar user experience.
My old Raspi2 are still running after years, so I’m trusting them for home usage. Anyway any PI can be substituted rapidly and spending only few bucks.
I understand who feels too tight on a PI3 and evaluated a NUC. I even tryed a simple k3s cluster, but IMO the PI4-4GB opens new possibilities.
Just my 2 cents…
Piero
EDIT: Now I’m confused by the premise of this thread. Someone would want to run HASS directly on top of HassOS? Is that what we’re talking about? No docker layer?
I’d like to use HassOS instead of Hassio setup but I can not do that because I’m using Odroid XU4 with eMMC module which I believe is more reliable than SD card. But there is no HassOS image for eMMC setup and solutions that I’ve found did not help.
HassOS is an easy to update HassIO software appliance, which indeed includes HASS. I like this concept. It works and it can gain a great value with the inevitable transition to 4GB or more SBC, while being compatible but enabling new possibilities over the 1GB or 2GB SBC season. The Raspi4 fits perfectly this area.
As per OP, my wishlist to migrate my PI4 cluster to HassOS is:
Option to keep the most updated files out of the SD.
Failover, even in the simplest form (rsync+keepalived).
Option to rpi-clone a nightly incremental SD backup, just to have also a “day after” simple manual emergency recovery at hand.
iperf3 client+server, low priority but IMO very easy to include and not memory hungry.
These can be obtained just now by a custom HassOS buildroot, I tried it but I don’t want to run after each HassOS new release.
This thread is meant to help devs, and all HASS fans like me.
Just my 2 cents.
Piero
Then you need to submit FEATURE REQUESTS for these things. That allows people to vote for what they want. A simple thread discussing what you would like to see is worthless without some action taking place.
I want a better way to retain HA logs after a crash in HassOS. I’m dealing with weekly crashes on one of my rPi3s with HassOS right now, but I can’t read the error logs right before the crash happens since unplugging and replugging the rPi power will reset the HA logs.
I have no way (that I know of) to access the logs since Hass.io add-ons aren’t functional during the crash. SSH and Samba add-ons that I use to access files on the SD card aren’t working.
I’m contemplating moving to installing Raspbian on an SSD, then installing Hass.io via Docker on top of it.
