I don’t know if anything related to HA is ever “guaranteed” not to break but I assume that the API should be fairly stable.
Here are the docs:
That’s essentially how I do it. It’s the only way I found to deal with these constant breaking changes in HA and have something stable I don’t need to constantly babysit and fix after every few updates. Up to recently I found this to be the perfect approach for me. I could use all the nice automation and UI parts of HA, was pretty much shielded from breaking changes as MQTT is (almost) the only integration I use and I have a completely separate and optimized MQTT based backbone, entirely independent of HA (read: an exit strategy if at some point in the future I decide to leave HA behind). I was happy.
Then there was a breaking change in the MQTT configuration format. I still haven’t found the time and motivation to start fixing my entire configuration with the tons of MQTT devices I have. I can’t update my production system to 2022.12 and beyond because of that.
I think, it is fair to mention, that the devs raised the requirement for the new MQTT configuration 6 month ago.
While I can understand the frustration and also the lack of motivation and time to change this, it should be mentioned in my opinion that this was not breaking from one to the next release …
Again, I would highly recommend that you should consider a change management for your systems.
That’s something established by nearly every company for nearly every software - and it will allow you to plan and maintain your updates in a way that does prevent most of the issues related to breaking changes on an update.
Of course - not everything might be catched - but that could be ruled out by having another evaluation installation active.
- Backup
- Update Management (Change Management) - with risk evaluation
- Evaluation system for testing updates
- Rollout updates to the productive entvironment
Yeah… if a software which entire purpose is to make my life easier, more relaxing and convenient at home, during my free time, requires me to set up a full and closely monitored application update and lifecycle management, just to keep said software from falling apart every month, then there might be a little problem somewhere… maybe if the devs would stop YOLO’ing breaking changes like they were nothing then we wouln’t be in this situation.
1 Like
I think it would be fair to say automation systems like Control4, Crestron, Elan, Savant, RTI, AMX, Johnson Controls, Siemens, Schneider Electric, Honeywell, Vantage, Legrand, Hubitat, Leviton, Loxone, KNX, HAI, OpenHAB, Homeseer, Lagotek, KNX, Lutron, Dynalite, or possibly Node-RED would suit you more.
1 Like
Hello,
basically runs to at least the following version. For about 2 years I have a HA installation running at my parents home. There I make the updates every 3-4 months. But then at least a version x.4. I have then usually to make a few fixes to the configuration and so on. But it runs so and so far stable over the next 3-4 months. The procedure is necessary because I am not on site and we have no external access installed there.
From my point of view the monthly updates are basically nice but the users of the versions x.1-3 are rather beta testers than users. The discussion under 2022.12 Color states are broken/unusable also shows that conceptually HA is a software from nerd for nerds. HA is regularly changed with the head through the wall.
Frank
1 Like
I agree, here - the beta cycle might be a bit short… and I also have some doubts about the “monthly” release cycle - at least, if you stick to a release on first Wednesday each month…
That will put a high preasure to the team, because they “should” finish the release by the target date… I do beleive, it would be better, if they turn into a quarterly based cycle - at least feature-wise, and provide updates to the core integrations more frequently (out of the feature cycles).
Also, if there’s a feeling that a feature won’t be ready for the target release date - postpone the release until testing and fixing is really done - when I read the comments, many users are already waiting with their updates until version x.4 x.5 or whatever…
So it wouldn’t be a big deal to postpone a major release by a week or so… 
1 Like
There is a silent majority. I do not believe anyone has an idea of what is best. But to me, looking from outside in, there seems not to be too many issues with how things are run by the HA team. I assume a poll with at least 100,000 responses can provide an idea of what people’s feelings are. But then again regardless, within reason, of what people say, this being an open source project with lots of people/devs giving their free time, devs need to be happy as well. No open source project can survive unless the devs feel passionate and love what they are doing. If driving fast is what devs love to do, and anyone tries to apply the breaks, it will kill the project.
I am not certain how many people have experience of the other domotics platforms out there. Nothing comes close to the openness, flexibility and power of HA, with the exception of Node-RED. But then Node-RED is exceptionally difficult for most people, unless they have webdev skills. I maintain over 100 instances of HA with no issues for years. But I run test, staging and production separately. Unfortunately most people do not have this luxury and run production, staging and test together in one system and hence suffer the consequences of instability, especially longer term.
1 Like
Great discussion folks…
It must be great to have the luxury of a separate test and staging environment. Unfortunately I only have so much time to devote to HA.
But what I’m really curious about is the 100 instances you support. Would you mind explaining how that came about, where they all are, how you manage them, etc.? Sounds like a more-than-full-time job, but a fun one!
Very simply friends all over the world and a technology business running for decades.
I would like to be your friend (and run my HA instance) 
good one 
I’m a bit tired of reading how good are the devs (that they are,indeed) and how bad is the community when something breaks their configuration…the custom components or other custom integrations that works among home assistant are made also from developers…maybe not in the nabu team…but developers and, the reason why lots of us rely on HA.
I think, that there is not too much condescendy when someone (or a bunch of them…that’s what it sucks) disagree to the point of view of the “bosses”
It’s ok, you rule, but probably I will lost my interest, and take down my nabu casa subscription, if when something it’s not well received and, there are only answers, asking them to being polite, to those who are angry and could say a louder word…
See a lot of post with nice reasoning and arguments that can not be argue, about things that changed to worst: slider in the automations, history graph, colors…, which get no response and are completely ignored…many, will say it’s not the way the things are done and, that we are not aware of the implications of bla…bla…bla…, but it’s how I feel in the last months…
No acritude and, a big clap for what HA it is and, thanks to all the developers but, politeness, does not remove the brave.
I really have to disagree on that statement - at least, for the icon colors, the dev team have listend and there was a great discussion ongoing until we got the solution to add customized color schemas to the different binary_sensor domains.
It is the same thing as always - it really depends on how you write your critism.
“This F***** update broke my whole system AGAIN” - will probably not work for getting a solution.
Especially, if you do not provide any additional context and or debug information like logs.
In terms of Custom Components:
→ The Core / NabuCasa Devs cannot know what custom components do exsist.
They do maintain their Software - and implement what they consider as required.
Usually, there’s the Beta-Cycle, where people can attend - and especially if they are using custom components probably SHOULD attempt - to report issues with their components to the devs that maintain it.
Also recommendet for the Devs to attend to this Beta Cycle, in my opinion…
BUT Still:
Custom Components are a fragile thing… you’ll never know when a dev will stop to develop and maintain the code.
Maybe due to changed priorities in business life, maybe due to loss of interest or - because he / she no longer use the peace of hardware anymore.
And yet, I haven’t seen any suitable way how such issues could be overcome.
I can agree, that it is sad and frustrating, when core integrations break - or if they are no longer maintained… but even in this case - it is open source, and priorities for devs of an integration that was added to the core might change… then it is up to the community, if someone will continue the work.
If not, the only solution would be to remove the component from the core - which - will again cause breaking changes for those who are using that integration.
In my opinion, NABU CASA should only provide the “homeAssistant” Framework.
Maybe, with a handfull basic integrations - and all others should be part of an HACS like plattform.
This could include ALL components - HACS, CORE, and so on.
They could be tagged like: “ha_core” and “community” … and there should be an information if the integration was tested successfully with the latest version.
Similar as it is done for wordpress… (as an example)…
But the main topic is - I think …
You can’t do it right for ALL users.
Some will like a specific change - others dislike the same… and vice versa.