I have never heard it referred to as Concurrence.
sorry, bad translation. I meant competitor 
1 Like
Why not just try it.
No need to destroy your openhab instance if you have another machine to spin up homeassistant.
For most things, you can have both controlling/interacting.
Only trick will be when you want to jump your zigbee across (if you use a dongle in the openhab machine)
Many many users here have come to homeassitant from openhab - myself included - from back pre openhab 2
The general attitude in the forums is very helpful - and there is a large history of anwsered questions already here too.
Hope you see what we like about it
Enjoy
Phil
2 Likes
Literally any junk machine is enabling you to test this out. If you’re able to schedule some downtime, you may only need a free SD card to test HA on the RPI. (the experience will be slow though, for better performance a hdd or an ssd is better.)
2 years ago I almost started in OH, there were some forum post stating that OH is more stable as HA is more aggressive in development.
Now I think HA has a good balance between progress and safety, plus the core staff is motivated financially as well to build a good product - which helps a lot.
Btw. 2 years ago I did choose HA because it seemed easier to integrate my alarm system - which was fairly easy and I’m a happy HA user since then.
1 Like
HA can be a bit unstable in the beginning of the month if you are a first mover on updates.
There are alot of changes with each months update and of course there will be a few bugs too, but the team is incredible fast to correct them.
If you look at the updates for each months you will see that there will be an update around each second day the first third of the month, so wait with the update until the 10. day and then it will be stable.
1 Like
I evaluated both HA and OH (and a couple others) when I first started. I don’t regret going with HA. The core itself has been rock-solid stable for me.
But… It’s not for the faint of heart. As mentioned, there are frequent core updates. These updates often require hands-on work to fix breaking changes, which are fairly well documented.
The biggest problem, in my experience, is that updates to integrations are rolled into the core updates. Integrations are notoriously hard for any one developer to test. They can only test in their own environment. Yours is probably different. Bugs are common, and not documented anywhere. It’s possible to update the core and then run into a bug in an integration, even if you diligently read the breaking changes list. The only non-invasive way to back out one of these integration updates is to back out the entire core update. In fairness, the developers usually do a great job of jumping on these bugs, but by the time one is fixed (in the next release) another could be introduced in a different integration you need. Once you get a couple of versions behind, catching up takes a lot of effort.
Right now the best a user can do is to minimize the number of integrations they depend on. I did put in a feature request to decouple the integration updates from the core updates, but it didn’t get much traction.
This shouldn’t be a show-stopper. Just go in with eyes open and understand that HA, and probably any such system you’re actively tinkering with, is going to require a commitment of your time to maintain. I just finished digging myself out of a three-releases-back hole and I’m still a fan.
2 Likes
I’m using HA for over 5 years now and can only confirm @frits1980’s statement. Rock solid, every issue/unstability I had was caused between the chair and the screen
2 Likes
I consider HA to be a particularly unstable platform, for this very reason. Frequent updates have breaking changes that, unless you have time to read all the documentation about the update, will break an integration, script or automation.
If you have the ability to run it as a container, then you can pin a particular version until you have time to read about the upgrade and sit down to iron out the breaking changes. This is what I usually do.
If you want an example of the havoc caused by breaking changes, read up on the z-wave and Tuya issues after the last major update (2021.10).
I would compare HA to Arch Linux more so than Debian.
1 Like
No version updates itself so anyone can stay at whatever version they desire, and update after they have read the docs.
3 Likes
HA have been great for me and so far no complain. Off course people have to remember regarding breaking changes and read the release document. Most people having problem due to just upgrade without know what they are getting into (its happen to me during my early adoptions)
1 Like
If you use the search button above you’ll find plenty of info and opinions on openhab vs ha. This one in particular
2 Likes
I have news for you. You ARE on the dark side.
Move into the light where developers actually care about user input. documentation is actually useful because it is written by the developers who create the code. openHAB expects users to write the documentation for the core. For addons OH requires the developers to provide documentation though.
The OH leader’s actions, many times, do not agree with his actions. I know for a fact the "stable OH 2.5.0 was released with a bug that was reported over 6 months previously. They refused to actually fix the problem in the core code but worked around the issue in 2.5.1 without changing the core. New users who installed OH & the addons package were unable to configure their system. I know this because I discussed it at length with the lead developer and pushed for a resolution.
1 Like
The thing with stability is IMHO:
A: Configure your recorder properly, and then you can leave HA alone, it will work alone.
B: IF you have new ideas (and you will have ideas), you have to choose:
=> B1: Realize those ideas in your home system => Your will cause unexpected downtimes, that affects other people in your house
=> B2: Realize those ideas on an sandbox system => Your will not cause unexpected downtimes, but you will have to spend more time to maintain your system
The problem with B2 is (in my experience): You have not two homes, one live-home and one sandbox-home .
3 Likes
I have done this on occasion to test breaking updates to integrations. If you have the capacity to run docker containers, it’s trivial to set up a new, test instance of HA.
My underlying storage is ZFS, so I usually clone my data and spin up a new updated container to upgrade. If all goes well, I get rid of the old container. If not, I get rid of the new one and wait for the problems to be ironed out.
In the last 13 months I have not had a single stability issue, though I am not running on an RPi… that seems to be the source of 90+% of stability issues judging by forum posts.
1 Like
Really? I’ve had integrations break a few times in the last year.
Were these breakages mentioned in the release notes and you did not fix them before updating?
Were those core integrations? Can you name some examples?
Also for me an integration breaking is not instability unless it took your whole system down, but that’s just my personal opinion.
1 Like
Yes it’s not unussual that core integration(s) not mentioned in changelog suddenly stop working after update (or at least part of their funcitonality is broken)
I guess someone who considers moving to new platform is interested in reliability in overall not stability per-se.
I could say HA is reliable if you have a luck or don’t uses system under specific conditions which might
cause problems. The few issues I’m aware of:
- Supervisor may fail on update crashing whole HA. unfortunatelly Supervisor updates without user control as we know. It happens to people in waves kind of once a year or two.
- Communication with NabuCasa breaks without reason. Probably snitun module fails and not recover. Happens about once a year
- Transition from DST to normal time crashes half of HA functionality, makes high CPU load, some installations stopped working at all (see todays reports).
- Core may DDOS itself and your local network because of DNS issue
- Last but not least: all issues with various severitites related to updates. incl impacting components which are not listed in changelogs. It does matter after the fact that all components must be updated at once (with whole HA). It increases a risk of breaking one component while updating another one in order to fix it
- One of the reasons why I don’t use supervisor. But still, a failure only once or twice a year is not that much in my view. There are commercial systems that fail more often
- Not using Nabu Casa anymore. Again an online system that fails once a year is actually pretty solid, Amazon/Google Services fail more often.
- No issues at all here, from what I could see it was mostly caused by time pattern trigger, while I agree that this shouldn’t be the case, I still haven’t seen a single automation that actually needed a time pattern trigger and other triggers would not have been more efficient.
- I agree this is an issue discussed heavily in another topic and should not be the case. Again I don’t use supervisor, so can’t comment on that.
- I run HA for 5 years now and my system never went haywire due to an update, I also never had the system reatart itself, not even once.
I got a feeling that people expect a military grade reliability system for free. In maybe 95% of the cases I saw here on the forum (and I read quite a lot of them) the issue was not with the system, but with the user and more often than not it was mentioned in the release notes, but people rather ignore them and whine afterwards than taking 15 minutes to read and 10 minutrs to adjust their system before updating.
The “breaking changes” section of the release notes does not list changes which break things (bugs.) It is intended to only list intentional changes which will force some or all users to make configuration changes to keep things working correctly.
For a long time I didn’t know this and thought I’d be OK if I just read the release notes and fixed any breaking changes which applied to me. This is not the case. You also have to monitor these forums and Github to scan for any reported bugs with the specific integrations you use. Or just cross your fingers, update, test everything, and be prepared to back out if necessary.
Exactly. Bundling all integration changes with the core update, then not documenting bugs in one central location is setting users up for failure.
I agree there’s a lot of “pilot error.” I’ve certainly made my share, and folks here have always been kind and helpful in setting me straight.
I do question the 95% figure, but even so, it’s hard to call it whining if someone does read the release notes but is impacted by a bug in an integration which was known but not documented, especially since there’s no way for the average user to back out an integration update without backing out the whole core update.
2 Likes