Hmmm. Based on the dates on that discussion, I’d say this idea is pretty firmly dead.
As for ZHA, not sure what that means. For all the complaining I’ve heard, it’s been working flawlessly for me. With my luck, it probably means someone will stir the pot and start breaking it.
Don’t think that idea is completely dead as they are usually quick to close “issues” if the idea is rejected.
See all the closed ideas:
https://github.com/home-assistant/architecture/issues?q=is%3Aissue+is%3Aclosed
verses still open ideas:
https://github.com/home-assistant/architecture/issues?q=is%3Aopen+is%3Aissue
But on the other hand, they have changed submissions so that new ideas first comes in as discussions:
https://github.com/home-assistant/architecture/discussions
I guess it only means they break out the ZHA backend parts into a WebSocket server and keep the client and GUI parts, with the WebSocket server and client used to enable a separation over TCP/IP.
https://github.com/home-assistant/core/tree/dev/homeassistant/components/zwave_js
https://github.com/zigpy/zha-websocket-server
https://github.com/zigpy/zhaws-addon
Breaking out some pars of ZHA and moving to WebSocket server and client would not only allow it to be updated separately from Home Assistant’s core but also allow running ZHA on a separate computer.
https://en.wikipedia.org/wiki/WebSocket
https://en.wikipedia.org/wiki/Client%E2%80%93server_model
This client-server model concept is also known as a “distributed computing” or “distributed system”:
https://en.wikipedia.org/wiki/Distributed_computing
" Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. The components interact with one another in order to achieve a common goal. Three significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and independent failure of components. It deals with a central challenge that, when components of a system fails, it doesn’t imply the entire system fails. Examples of distributed systems vary from SOA-based systems (service-oriented architecture) to massively multiplayer online games to peer-to-peer applications."
https://en.wikipedia.org/wiki/Service-oriented_architecture
“In software engineering, service-oriented architecture (SOA ) is an architectural style that supports service orientation. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.”
PS: Such models could in theory also allow other third-party apps to use/control ZHA WebSocket server, as similarly, Z-Wave JS WebSocket server allows many different UI clients to connect / control it.
As for ZHA, not sure what that means. For all the complaining I’ve heard, it’s been working flawlessly for me. With my luck, it probably means someone will stir the pot and start breaking it.
Be careful what you wish for…
Yes, I’ve been monitoring that. After the past few releases, I’ve gone to a new strategy. Instead of trying to stay current, I’ve been waiting until the end of the month, when the point updates slow down to more than just a few days apart.
We’ll see how this ZHA issue shakes out. Native support for Zigbee would seem to be a core functionality which any home automation system needs to prioritize. Hopefully it’ll get fixed.
Made a request but it got marked as duplicate of this one. Altho it wasn’t exactly a duplicate as I mentioned having a “comparison list” and having previuse version of HA files stay as the update brings new files; therefor old integrations will get to use the old files and new integrations will use the new files.
So basically like having “puzzle peaces” get added on rather then a whole package being changed.
I saw your FR, and it made sense to me. Anything which attracts some attention to this idea would be great. Presumably there are a lot of smart people in the core dev team who could discuss the best way to implement something like this, and probably come up with something better than you or I could alone.
Right now the vote count for this FR is pretty low. There are lots of FRs with far more interest from the community. I do believe that the current process of making massive changes to everything, all at once, is risky, and perhaps some day this idea will bubble to the top of the priority list.
I get why someone would request this. But in practice I’m not sure how this would make things better. Integrations require maintenance and that requires a codeowner actively paying attention to it and making the improvements and fixes people need. Integrations which have this work well, integrations which don’t quickly do not.
Moving things outside of core doesn’t change this fundamental principle, there must be one or more developers actively invested in its working state else there will be issues. At least with things in core the test cases are all run with on every pr ensuring that what did work will keep working. That isn’t the case for things outside of core. Hacs developers rely on users informing them of warnings and errors being logged after they start appearing. Which in my experience seems to mostly result in a mad scramble during beta when warnings become fatal errors for those willing to beta test.
IMO if you want this to get better what you really should do is add test cases. This applies to anyone willing and able to do python code. Go find the integrations you use and ensure the use cases that are important to you are captured in test cases. Increase the coverage of that integration. A project this size is only as good as it’s CI. That’ll be true whether the 2000+ supported integrations are in one repo or separate ones. If CI is not automatically ensuring something works after each pr then it’s only a matter of time before it breaks.
From the perspective of official integrations that would not need to be an issue. They would still be just as able to run all of those tests, and make sure all official integrations that need an update get an update. Doing this would maybe need more emphasis on backwards compatibility. The reason HACS integrations may have issues is because the developers of those need to go out of their way to make sure their integrations work with future releases before it is released. For official integrations managed by Nabu Casa, they can still easily work that into their work flows to be essentially the same as it is currently.
The way I see such an implementation working is through a feed/package management system. For those not familiar with programming, think of something like an RSS feed where you have just a URL that links to a standard way of distribution of integrations. When you want to add an integration there would be no need for any containers, not sure why that was brought up, the necessary files for the integration would just be downloaded and registered into an “integrations” folder. You could then theoretically install any version of an integration, or even add your own feed for custom integrations you created. This would make integrating HACS much more easy, and there would be a universal location for all integrations official and unofficial.
This way of doing things is pretty standard in the industry, and should be relatively easy to implement. Although, that would also depend on how well the system is designed. The biggest thing is you want to get the design right from the beginning. Getting it wrong could be a big headache when it needs to change in the future.
For the number of times this issue comes up, I’m surprised the vote count is so low. It seems like such a simple concept.
In fact, that’s how all our mobile devices work. There’s a “store” of apps (think, integrations) that are updated independently of the operating system. You can put these on automatic update, or you can choose which, and when, to update.
There’s always talk about making HA more modular, and about making HA easier for beginner users. To me, being able to roll back a problem integration, without having to roll back the HA core and every other integration with it, seems like it would be far simpler for everyone. It might encourage more people to stay current. It certainly would for me.
I am not a coding professional, although I have fair IT skills and a huge amount of enthusiasm. However that enthusiasm is dented any time I update Home Assistant (always after reading the release notes) and something breaks. And when I say something breaks, I don’t just mean the ability to switch off the lights in the lounge at bed time, or to switch on the bedroom light. The other thing that gets a knock is my partner’s patience, my kids’ sense of humour and my dignity.
Home Assistant is an amazing piece of software and I cannot believe how much has been achieved by a community of enthusiasts. To ensure its future success we need to make sure that for ordinary users it keeps on working without nasty surprises. It may be that rolling back updates needs to be made easy through the UI?
From my experience of another system that has a lot of third-party add-ons, WordPress, keeping separate updates for the core and the add-ons is really important.
I couldn’t agree more. Lately I’m seriously afraid of updating the core.
The funny thing is, 3 years ago I started with implementing a few hue lights and our 3 blinds. At that point is was almost funny when something stopped working. Nowadays I have 2800 entities with almost 500 devices and services connected to it. If something breaks now… the concequences can be tremendous. Everything is linked together. Our central heating system our AC’s our watering system. A few versions back our central heating all of a sudden stopped working after an update. The temperature sensor (thermostat) is used in more then 25 automations in the house. Including ac blinds and 15 thermostic valves. If this breaks all goes wrong.
Making the core modular shouldn’t be any problem. Instead of installing them all when installing ha. They should be installed just like add-ons when you add them to ha. After that they will keep their version until manually updated. It’s just like custom_components work now but then this will become the standard way of doing it.
And as a side note. I wonder why we need to add versions and stuff to the manifest.