Most people depend on multiple different integrations in their HA system. These integrations change all the time (which is good.) But the testing is, by its nature, very difficult for one developer to do. There are so many different environments out there, it’s almost guaranteed that fixing one bug or making one update will introduce another problem for some users.
Lately it seems these bugs are creeping into merged integrations more and more. I use one integration which was changed in version 8.0, which made it unusable. I had to back-level HA to version 7.4. It looks like that integration might be fixed in 10.5, but now I’m reading reports of two other integrations I need becoming unreliable in that version.
The longer a user stays at an old version, the more breaking changes there will be, requiring a lot of re-work when they finally upgrade. And since bugs aren’t included in the list of breaking changes, there’s no way for the user to know whether there will be other broken integrations requiring them to back-level HA again.
I’d like to see a more modular approach, where the integrations can be updated or back-leveled separately from the core, right in the UI. It may be as simple as including core integrations on the “Integrations” page in the GUI, and offering previous versions there along with the current version.
A user could then update the core, but back-level a problem integration until that one is fixed.
You can install a previous version of an integration by copying it to your config/custom_components folder and adding a version key to the manifest file. This will then be used in preference to the core integration.
The most popular way to install Home Assistant uses Docker containers. Home Assistant and all its integrations are within a single container. Add-ons are in separate containers (one per Add-on).
If this FR were implemented, allowing users to easily rollback any given integration to a previous version, how would the integrations be distributed? I guess each one would be in its own container, like an Add-on?
Thank you, yes, I’d seen that. Obviously one has to track down and copy the correct old version, and it’s not a very user-friendly process. I strongly doubt the average user is going to do this. For many, “copying to the config/custom_components folder and adding a version key to the manifest file” might as well be written in a foreign language.
Maybe there are two issues, the core integrations and the add-ons. My FR is suggesting they both be handled the same way. Ideally I’d like to be able to see and change which version of each integration I’m using.
I’m certainly open to better suggestions. Maybe a way to back out (un-merge?) an integration if problems are encountered after it’s been merged. Some bugs only affect users with a specific environment, and users without that environment might want to keep the new version, while those impacted by the bug need to back-level just that integration, but may want to keep the rest of the new HA version.
I already said it, but monolithic releases with hundreds of integrations are not sustainable in the long-run, and I’m pretty sure the devs know that.
As the OP says, those integrations have their own lifecycle, and it doesn’t make much sense to tie them to a “core” release.
Bottom-line: I am all for it, and I would really be surprised if it’s not already considered backstage.
My question focused on distribution as Docker containers, one for each official integration. An alternative would be to distribute them just like custom components (like HACS) and they would reside outside of Home Assistant’s container.
The tricky part is that if you upgrade the Home Assistant Docker container, the (now separate) integrations don’t automatically get upgraded. Either you upgrade them as a separate step, or make the entire Home Assistant upgrading process more sophisticated so that it can offer to upgrade the separate integrations as well.
Either way, it’s significant departure from how they are currently distributed. I imagine there might also be a need for some meta-data indicating version compatibility. For example, if you were to rollback an integration’s version too far, it might no longer be compatible with the latest version of Home Assistant (due to breaking architectural changes).
I recall a podcast, perhaps two years ago, where Paulus mentioned it in passing and briefly described the challenge of doing it (with Docker containers). Seeing that it’s been on his mind for that long and nothing has materialized suggests to me that this is a can of worms no one is in a hurry to open.
Missed your point. Not really sure why you think about docker in this context.
I’m thinking about “custom components” way of distribution, as HACS is doing, basically.
Using containers for integrations would basically mean rewriting core so as to have a low-level communication channel for this.
Not eve speaking of the fact that containers bring a full OS along, which would be a crazy waste of resources if you’d have one per integration.
Yep, been there done that. But in HA’s case, manifest.json is already there, so it’d just be a matter of expanding it with those kind of attributes.
Agree with OP.
With the request alone as well as reasons behind it
Though I cannot believe it’s going to happen since project owner’s view seems to be “all or nothing” (see years old request for option of disabling selected default/zeroconfig integrations)
How do you envision the upgrade process would be handled? Supervisor currently pulls a new Docker image and instantiates a container. Done.
That wouldn’t change but now it would also need to download integration files and overwrite existing ones ( … or something).
It’s feasible but I kind of understand why it’s been on Paulus’ backburner for 2 years and counting.
FWIW, I still use 15-year old home automation software that allows separate installation (and uninstallation) of integrations without even the need to restart the core service. However, there’s not much call for doing that because the product was discontinued 15 years ago … so there are no new integrations Nevertheless, having grown accustomed to that convenience, it’s hard to give it up in Home Assistant. This FR has my vote but I would be surprised if it was implemented any time soon.
Just popped that a recent app doing basically this is Nextcloud.
When a new “core” is available I’m notified, and it also tells me if a plugin/addon I’m using is not (yet) compatible with the new version. Easy to do if a “version compatibility” tag is added to the manifest.
At the end of the day, it’s been done countless of times, so no real need to reinvent the wheel, here.
Still it requires some “code maturity” on the core side, i.e. no core breaking changes every month
On that matter, I consider HA still in its infancy, here, so this is something for mid/long term.
When we get to the point that most of the release notes content relates to integrations, that’s where this will have to be seriously considered.
It occurred to me that, if I were testing HA today to decide which smart home system to implement, I’d have to discard it as an option pretty quickly. There are THREE integrations I need to control my devices, one of which is flat-out not working and two of which have had bugs reported which may affect me, in the current version. I’m still running 7.4, where they all still work. I want to upgrade. This is so depressing!
Out of curiosity, what are the three integrations and do you know if they are handled better in other home automation software (openHAB, Hubitat, Homeseer, ioBroker, etc).
No, I don’t know that they’re any better elsewhere. And I don’t want to throw anybody under the bus. These three integrations are being worked by dedicated developers and I have every confidence they’ll be fixed eventually.
The problem isn’t the developers, it’s the practice of rolling everything into the core and not having a way to roll back components when problems are (inevitably) discovered after the merge.
To be clear, my goal isn’t to pillory the developers but to simply determine which integrations have long-standing issues. Anyway, if you prefer not to identify the integrations, I won’t press you to reveal them.
Perhaps it should be. Let me put some feelers out with the documentation gatekeepers, if they don’t want it in the main documentation I’ll attempt to write a community guide instead.
I have not read any news about this but it seems to indicate that the ZHA component might get broken out of Home Assistant’s core. If so guessing it will mimic client-server model architecture of Z-Wave JS?
Hopefully, that will mean that will later be able to choose if and when to upgrade the server part of ZHA?
Breaking out the ZHA component and using via WebSocket server and the client would not only allow it to be updated separately from Home Assistant’s core but also allow running ZHA on a separate computer.
Nevertheless, having grown accustomed to that convenience, it’s hard to give it up in Home Assistant. This FR has my vote but I would be surprised if it was implemented any time soon.