I did that couple of times by asking on pretty active threads here for changes to Features or even complete rewrites of integrations with ~400 active users. I get that this isn’t many but there is next to 0 interest in testing - may it be due to the complexity of setting up a test environment or that only a few even use that specific feature or even own hardware needed to use it.
On the other hand if one of these changes doesn’t work fully as expected it always can be fixed in a dot-release. That’s what they are there for. There are lots of such small integrations that will never find a beta-testing circle - but this doesn’t even effect the majority of HA users in any way.
Having the beta phase extended from the current 1 week to whatever timespan wouldn’t change anything about that.
Implementing the ability to only update specific integrations would require them to be compatible to earlier core versions - which with the current development pace of core - is infeasible for volunteer developers.
I like the flea analogy, and tend to agree about cloud based services.
But in this case, it wasn’t Honeywell who broke the integration. The integration update introduced all the problems. The old version of the integration still works with Honeywell’s cloud API exactly as it did before.
So, while the advice to avoid cloud-dependent devices is sound, it’s not relevant to this conversation. To be honest, with something as critical as heating systems, in my climate, its reassuring to have an alternative way to access my thermostats if HA should fail. And frankly, Honeywell’s cloud service has proven far more reliable than HA. That’s sort of what this thread is all about.
Agreed, I was just reading about some of the newest “connected” systems that basically have their own wired network ( thermostat, heat pump, air handler) in addition to cloud access. The wired network can sometimes fail and the system is either stuck on or off until there is manual intervention to establish that network again.
… As long as you’re home to use them. I had a pipe burst one time when I was 1,500 miles from home. Knowing the heat was off would have saved me a LOT of money and belongings.
The unreliable component in this analogy is HA. Users complaining about how unreliable HA is, and having those concerns dismissed by developers and hobbyists with the skills, time and inclination to take a deep dive into the nuts and bolts of setting up and maintaining HA, is a common theme here.
I’m not passing judgement. I’m here because I know the deal and I’m willing to accept what is essentially a very rough “beta” version of a great home automation system. I like tinkering with stuff I don’t fully understand yet. And I’m optimistic that HA will keep improving.
But I’m sensible enough not to put all my eggs in that very fragile basket. Much as I hate cloud-based solutions, I’ve made my peace with my Honeywell thermostats. They make a great back-up to HA control, which is my preferred method.
They do… Join discord. The beta channel goes live same with the beta documentation and blog post that describes all changes.
The next versions documentation (url: https://next.home-assistant.io/) :
The next versions blog post is at the bottom of this list and will appear when the beta goes live:
The beta goes live every wednesday before the first wednesday of the month. For example, the next release will be on 10/6, so the beta will go live next wednesday 9/29.
EDIT: This is not directed at anyone in particular. Just a statement based on my experience.
I personally run the daily build and update every day. This is essentially the ‘alpha’ for each release. In the past year of doing this, I’ve ran into 1 major issue and I ended up making a PR in a custom card to fix the problem. It’s extremely stable, just as stable as the releases. I also run this on my production machine. Anyone can do this. If the alpha doesn’t work, you downgrade to the lastest release via SSH. Everyone here who says they don’t want to do this on their production machine is just making up excuses to avoid helping make the product better. I see this literally every time people complain about HA and testing. Everyone runs for the hills as soon anyone suggests actually providing testing. Put your money where your mouth is and try it instead of making excuses.
@petro I wish I had the knowledge to do as you suggest. I’m not incompetent, I’m just not competent yet. My only avenue for support is to send money. And I suggest that others who are not competent yet also send money. It will allow the developers to hire more people.
The developers are doing all they can and it is greatly appreciated.
Just change the version number to whatever you want and run it through SSH addon.
ha core update --version 2021.9.7
Your beta testing progress will be as simple as this:
Take a snapshot
Update to beta
Read breaking changes on the blog post linked in this post.
Update your config (If it needs updating)
Report any bugs. (If there are any)\
If the bugs break your system, downgrade or restore the snapshot. Downgrade if you didn’t make config changes because it’s faster. Restore the snapshot if you change a ton of your config.
This process usually takes all of 5 minutes if you don’t have to update the config. Anyone can do it.
Joining the alpha program is slightly harder because you have to find the breaking changes yourself or ask someone if anything was changed.
I agree @AllHailJ, my knowledge has grown exponentially in the short time I have been building my home automation. Including management of a linux server, docker, kvm and zigbee networks. But I only have one instance and my family get very frustrated when things stop working. But soon I might be in a position to start contributing to beta testing.
Thank you!! I think we’d have more beta testers and happier users all around if everything were explained this simply. You’ve motivated me to do some beta testing once I work through a couple of other issues which take priority right now.
I’m a bit late to the party, but I wonder whether anybody has proposed more control over the update process? As far as I can see, the only easy option currently is to update to the latest released version. What if one could select the concrete version? This would allow some users to always be on the latest (which is important to discover bugs), others to e.g. update to the latest dot version (the one before the next major release) for improved stability. This would be extra convenient if HA could be configured such that a notification for “update available” would only be shown for that particular version (but it would still be nice to choose that version even after the next major release has been pushed out the door - otherwise, one might miss the rather short time frame during which that version is available, and the next major version has not yet been released).
I really appreciate the pace HA is developed with, but personally would like to update my HA installation once a month “only”, so that solution would suit me just perfectly - but I guess that there might be quite a few users who would prefer such an approach. I don’t have any idea on how difficult it would be to implement this, though.
What I meant is “let me select from the last (say) 10 releases (which would be 2021.12.7 to 2022.2.5 if I have counted correctly) or all releases of the last (say) 3 months”.
Btw, for me it would already be helpful if the last dot release before a new major version would be marked as such in the release notes only - I’m actually reading this stuff, and I appreciate the work that goes into that!
As I don’t have a test system and my OH is fed up with the issues I have been having when updating I now never install the x.0 version. I wait for a couple of updates to occur before installing and then only if the update has something of interest or impacts a feature I use.
As an example:
2022.2.0 - Nope
2022.2.1 and 2 - Nope
2022.2.3 - installed
This has reduced the amount of issues I experience.
That’s exactly the idea here. From my experience, it is rather common in industry to only install the latest service release on critical systems if the according software has a fast release cycle, and if no “long term support” version is available (and if you still need to stay kind of “up-to-date”).
Since HA is not critical to me, but I also don’t want to spend a lot of time maintaining it and stay up-to-date at the same time, that’s the update strategy I will use from now on (that I have learned about the option to install arbitrary versions as described above). I think that this is an awesome compromise. Note, however, if everybody does that, then the services releases will still contain bugs - early adopters are still needed for that approach…
I run the Beta on my production system without issue, usually. When there is one it takes 5 minutes at most to roll back a version. 15 if it requires a backup restore (hasn’t happened for two years).
Heck, I ran beta versions when I was 5000km from home for a year.
The more people on the beta team the more bugs get caught before release. There is only a small set of testers and we dont run all the integrations.
Having said that I realise it is not for everyone.
I applaud you and those who test the beta. Unfortunately I have had many problems with HA and in particular the ZigBee network (which I realise is largely separate from HA.
- but I guess that there might be quite a few users who would prefer such an approach. I don’t have any idea on how difficult it would be to implement this, though.