I am new to HA and haven’t yet had the frustration of stuff breaking like the OP but suspect it will come to me at some point. So far, I have been pleasantly surprised by the stability of the platform and the extent of the integrations available.
I have lighting (Rako), music (Nuvo) and alarm (Texecom). These are all stable platforms in terms of the Vendor API - the Nuvo is legacy serial integration the other two are over IP but established and unlikely to change anytime soon. I also have Shelly via MQTT and various zigbee devices which I suspect have broader use and therefore support/testing as part of the HA release process.
It does seem a reasonable goal to have HA at a point where the integration architecture is stable and things like the (Rako/Nuvo/Texecom code) survive an upgrade without breaking and needing the original devs to update their code (assuming they haven’t moved on to something else). I don’t have a good feel for how close we are to this point but sense that recent changes have broken things and therefore we aren’t quite there.
New security vulnerabilities are exposed all the time. This was discovered back in January, Developers have had 5 months to fix their integrations and chose not to do that. Many times HA is blamed for community developer apathy or laziness.
Running HA supervided in Docker on Ubuntu 20.04.2 LTS
(Yeah, i know, Debian is advised, but i just did not succeed installing it on this machine, when i started. And I’m 100% sure, al the annoyances I had, are not related to the OS, before a discussion on this starts and the topic get’s lost…)
If you are using Home Assistant OS, or Home Assistant Supervised, it employs the Supervisor which is part of the Home Assistant project but maintained by far fewer people. Should you encounter an issue with Supervisor, or disagree with some aspect of the way it works, the feedback you get will make you feel like you are using OH again.
Unlike Home Assistant, Supervisor updates itself without your consent, each release comes with unannounced changes, and configuring its operation is extremely limited. It’s the most un-Home Assistant part of Home Assistant if you get my meaning.
With a different username, I was here for quite a while last time. I was the one who wrote the 23 step process to move to a new Python3 version that was not officially released at that time.
I also followed the thread where the developers here were going to remove Home Assistant Supervised on Debian until there was a user outcry and compromise to only support a vanilla Debian installation. That discussion would not have happened in openHAB land. I have had several private discussions with the project head over there.
I know, I only use a zigbee cc2531 which communicates over tcp (usb2ser), but if i really need usb i’ll switch to vmware, virtualbox or proxmox
Before i had the usb2ser, i ran the mqtt broker on W10, but i wanted everything under hyperv, so i could use snapshots of the complete HA setup .
Yeah sometimes you just can’t avoid breakage, like when manufacturers change their APIs without forewarning. That’s just the cost you pay for supporting every proprietary or obscure cloud tech under the sun. But sometimes HA also comes with some breaking changes that would have been completely avoidable with a little bit more work.
Personally I have managed to keep my system very low maintenance by following some simple rules:
Use the most simple bare to the metal install method, Home Assistant Core. The less HA you install, the less can break. Focus on central HA functionality.
Keep away from the Supervisor at all costs. The perceived ‘easy’ click’n’play comes with so many drawbacks, it’s just not worth the trouble. You can install custom stuff manually if you really need to. And addons like zwavejs or Mosquitto are going to be more manageable and stable if you install them separately anyway.
Try to keep your hardware ecosystems consistent. Instead of buying a hodgepodge of random cheap devices left and right, focus on two or three core technologies across your home. Try to use established standards (Zigbee, Zwave, MQTT controllable devices for example).
Keep everything as local as possible. As soon as you introduce cloud devices, you will introduce code rot that will eventually bite you.
For every custom integration you use, think about if you really need it. These are typically the first to break.
Update only when you need to update. It’s better to set aside a day installing a new HA version once or twice a year than to do this every month. If you use consistent ecosystems, you will have less problems with breakage anyway.
Following these steps I managed to keep a very stable system running up to this point. With one exception, the RFXCOM integration that introduced a totally avoidable breaking change to make it easier for the developer, but that created a lot of work for users. This made me so angry that I removed the integration and reprogrammed it myself from scratch as a daemon running independently from HA over MQTT. But besides that, things are really smooth right now.
@HeyImAlex just made the perfect summary of rules if what you are after is the closest to a set and forget setup. I didn’t mention his first three points but I do comply them.
I would add. If you can’t avoid a cloud, have duplicated automations with different integrations for each one if possible (for example, if requesting playlists through the Spotify integration breaks, I achieve the same result requesting those playlists with the Alexa integration: “Alexa, play X playlist”). If one integration fails, disable one automation and enable the duplicated and wait.
Hi HeyImAlex, I agree with you, RFXCOM integration is a nonsense and what was simple has become complicated. It is now a black box to which we do not have access.
I’ve an issue with Rfxcom not able to control devices/switchs subtype PT2262 packet type Lighting4 after update to 2021.2.0.
Problem was reported to github but still waiting for a solution. I’m going to put another system in place that I can change by myself. I don’t understand why a problem introduced by an integration update isn’t fixed quickly.
The main thing I’ve learnt over the years with HA is have as many items as possible use WiFi + MQTT, they just don’t break. I very rarely purchase items now that don’t work in this way.
I’ve also tried to limit the number of integrations and add-ons I use to minimize the possibility of problems and keep the ones I do use to ones that seemingly always work and I never read issues with.
I use Zigbee (Zigbee2mqtt) for some non-essential items like temp and lux sensors, but no Z-wave due to (seemingly) constant issues with it.
It’s not a solution for everyone, but my Home and Business are almost bulletproof running in this way.
I’m sorry I spoke about it without knowing. From that point I share that I too install manually all my custom stuff. You should ask HeyImAlex about Supervisor trouble.
Home Assistant & Home Assistant Supervised have a supervisor Docker container to manage Home Assistant. that is where you get access to the Add-on Store and other features. currently, my supervisor is alerting me to a new patch version of home Assistant Core.I can create a snapshot & update from the Supervisor UI. This is the developer recommended way to run home Assistant.
I know about Home Assistant & Home Assistant Supervised. My question was pointing to the troubles and drawbacks ment by HeyImAlex. I never ever had any troubles with it and Addons like MQTT or Samba I install seperately on my Home Assistant Supervised as Docker Containers anyway.
I was taken aback by the bullet point about Supervisor, too.
There are many ways to slice and dice HA. I don’t want to discourage anyone from setting up an environment they’re comfortable supporting. But for pure simplicity, I’d recommend going with, well, what the developers recommend:
Home Assistant Operating System: Minimal Operating System optimized to power Home Assistant. It comes with Supervisor to manage Home Assistant Core and pre-installed add-ons. Recommended installation method.
I know it’s always going to be supported with minimal effort on my part. I like to tinker as much as the next guy, but when it comes to a system I’m depending on to monitor my home when I’m away, tinkering isn’t a good thing.