I have been thinking about this issue with broken integrations.
Each time a new HA is released we have a storm of people reporting that xxxx.xx.x has made their integration stop working.
I know Paulus once talked about (in some Youtube interview or Podcast - cannot remember) changing the way Home Assistant is distributed making all integrations pluggable (don’t shoot me if I express it wrong).
I think a lot of stability could be obtained for the individual user if an update of Home Assistant means that you updated a core and the front end and a number of generic integrations. But any integration that relates to interfacing 3rd party products would be something you pick as required and load.
The advantage of this is that you can upgrade each individual integration when there is a reason to.
With individually released integrations you can
Update each integration when you want a new feature or there is a bug to fix
Downgrade an integration to previous version when the new breaks something without being forced to revert the entire HA to previous version
Developers of an integration can fix and release a new version without having to wait for next HA release
There is way too much bundled into a HA release today. It would also relief the core team as they can focus on the core HA and the front end.
In Foswiki where I have been release manager years ago we shipped with around 15 plugins that we declared core plugins and the core team had the ownership of those. And then there were hundreds of contributed plugins you could download and install with a UI not very different from HACS.
We maintained an API and if the plugins only used the API calls to the core Perl code then the plugins would run no matter what. The users quickly learned that some plugins were well maintained by active community member and others were cruft that never got finished. I really think plugins should have release cycles independent of the core.
My daily experience with the few HACS things I use is that they are usually fixed much faster then the core integrations and I can up or downgrade as I see fit.
A full plugin centric architecture can work very well, but only if the core API is very stable. Because as soon as you start changing the core API, you’ll either break all plugins or you need to keep lugging a lot of backwards compatibility cruft along the way, which can make maintenance a nightmare in the long run.
Apple does it in the former way : when you develop for OSX/iOS, you’ll be confronted with an ever changing API and very aggressive deprecation policies. This forces you, the developer, to always and constantly adapt to a moving target and is very time consuming and expensive. But it gives a very lean and efficient API. Microsoft does it the other way round : some of their APIs offer backwards compatibility up to Windows 95 (!). That is very convenient for the developers using the API, but it costs MS a lot of money to maintain. So you need to find some kind of middle ground here.
I don’t think core HA has reached a level of maturity yet where a fully stable API can be envisioned. Stable means stable for years. We don’t even have a stable release channel yet.
You’ve been playing the victim card since your first post. Quoting your exact words is not “making it personal”, it’s what you wrote. If you think your own words are “an attack against” you, then you shouldn’t have written them.
These rants bloom every 3 months or so and what they have in common is the author’s desire for a pity party. The first post is typically a hysterical rant, seeking the like-minded. The author spends the rest of the thread explaining themselves more rationally, often trying to reframe the nonsense they originally spouted in a more positive light.
Disagreement isn’t interpreted as simply being an opposing opinion. The author feels they’re the aggrieved party, so disagreeing with them is seen as lacking empathy or even a personal attack. The pattern of these kind of threads is predictable, especially its outcome which is rarely anything that moves the project forward.
Mark your calendars for another rant later this year.
I recall his comment (from a podcast) along with the inherent complexity involved with achieving it (docker container per integration anyone?) … and the comment was made a long time ago (if my memory serves me correctly). I think it was an aspirational goal and more time will pass before we see anything on that front.
FWIW, the other home automation software I use (now 20 years old), in addition to Home Assistant, has integrations that can be upgraded and installed on an individual basis on a live system without requiring an explicit restart/reload.
While its not so much of a solution as it is a practice you might consider a dev environment to test upgrades before you roll them into what is now running your home. VMs or a second Raspberry pi could provide a low cost test option that gives you an idea on impact before upgrading to the latest. N-1
If you are expecting with this thread that HA suddenly becomes 100% stable and reliable, that apparently AFAIK ain’t gonna happen anytime soon. That’s why everybody is giving you their suggestions, to ease your problems with HA so you can live with them in a decent way.
You’re mixing up zwave integrations. Zwave JS was announced the same day Zwave 1.4 was deprecated, and there has been no guarantee that a migration path will be made for Zwave JS. The devs (zwave devs, not core devs) would like to make a migration tool, so the likelihood that it will be made is high. Just don’t expect it tomorrow or next month.
The migration tool you are remembering was promised for OpenZwave (beta), which was delivered… Then fishwaldo decided to quit and that killed off OpenZwave (beta).
I gave up on Z-wave a year ago. Once the existing devices quit working, I will replace them with something that uses MQTT over WiFi. That has never let me down.
Almost everything here is using an ESP (like Sonoff or things I build). I rarely have an issue with them.
Then I must have misread something, but I really remember reading something about the Supervisor being depreciated. I seem to recall that you were in that thread as well, some 6 months ago or so.
Found the thread:
It was about this time that I bought a second Nuc to run the HA image. (Glad I did). This lets me keep my Ubuntu on the first Nuc.
Maybe what you remember is Home Assistant Supervised being deprecated? That’s what it states in the link you posted.
Supervisor is a management module included in two installation methods:
Home Assistant OS
Home Assistant Supervised
The plan was to deprecate the second method, namely Home Assistant Supervised. Due to pushback from the community, the plan was cancelled (but with some constraints documented in ADR-0014).
That’s the problem, you are guessing. When Legacy ZWave (1.4) deprecation was announced, it came with a caveat:
The only way Legacy ZWave (1.4) is getting deprecated is if it stops working. This will only happen at major python releases. When python 3.8 is removed from HA and 3.10 is added, that’s the next barrier. I highly doubt Legacy ZWave (1.4) will stop working then. You most likely have years before that integration stops working.
