I am an unconditional lover of OpenHab. My knowledge has grown a lot, since a year to now, with so much information that I have acquired.
I started from scratch and what I have built was very sweaty and long invested to control this magnificent platform, which is OpenHab, and with this group of friends who are exchanging ideas and knowledge.
But I’m worried. What is the reason that in recent times, I have seen reference YouTube channels to switch to Home Assistant?
I tried several times to test the system, but I can not find anything better than OpenHab.
In fact, I noticed that Home Assistant has been creating more partnerships and with that, to develop more integrations for their system.
But why do I have this feeling that Internet influencers are slowly brainwashed and try to show that Home Assistant is better?
This is an outburst. I do not want to create wars or bad environments, but I feel like I’m almost “forced” to change.
Attention … I have OpenHab running 100% smoothly and with everything I can do. The only thing I think is missing at this point is more integrations.
Thank you all
I visit both forums very regular and I have in the past wondered the same BUT I have noticed a few things about HA compared to OH. I have never tried their platform so the following is only from looking around…
HA looks to have more ‘components’ then our addons, but when you look at it closer you will see what one of our addons does, it takes 10 of their components to do the same job. It is as if someone has done it deliberately to push up the number of supported devices for marketing reasons. Under Camera components you will find “mqtt” and “local file” and then multiple generic and branded ways. The ipCamera binding handles many brands and is only seen as 1 addon which is not listed on the OH site.
Forum has more traffic, but you can read this as there is more people asking for help.
There are more breaking changes from the looks at the HA project and they are losing users and complaints about it. The openhab core and framework has been well thought out and implemented and is stable. A rapidly changing code with lots of releases has its downsides.
The Openhab cloud is free/donation, where the HA cloud costs you $5 a month. They pay 2 peoples wages from this if I am correct.
Can I ask why you feel “forced” to change by people expressing opinions on the Internet? The only reasons you should switch to HA is if OH stops serving your needs or you think HA can work better for you, and it doesn’t sound like that’s the case.
This isn’t a competition between OH and HA…it’s just two different options, both of which offer strengths and weaknesses. So long as both are viable, all that matters is which you prefer to use.
You shouldn’t be an unconditional lover of any software tool. Keep your eyes open and never be afraid of considering some other tool. It might be even better for you.
OH is not dying. In fact, based on what few statistics I have access to all indications are that OH’s user base is growing. Using the forum as a proxy for OH use, in the past month there have been:
714 new user signups on the forum
709 new topics
7.7k posts
138 average daily engage users
330 new contributors (i.e. first posts)
Compared to last April, all of the forum stats are slightly higher now than in 2018, but trends are hard to see because of the big spike leading up to and immediately after the 2.4 release.
It’s hard to draw any firm conclusions based on forum statistics, but it’s all I got. My overall impression is that OH’s user base is slowly growing.
That doesn’t mean everything is all unicorns and gum drops. OH, like HA, is an open source project. Furthermore it is an open source project backed by a German non-profit foundation which “pays the bills” if you will for hosting this forum, myopenhab.org, etc. but doesn’t really direct the development of OH itself. This is one reason why the foundation cannot charge for use of myopenhab.org (or at the very least it would be very difficult to do so and retain the non-profit status). But this also means that OH can’t really operate like a business. It very much does look like HA is trying to run like a FOSS business (a la Red Hat or Docker).
OH also has it’s fair share of human drama and controversies. You don’t have to go far to find “rage quitters”, complainers, lengthy discussions about what we need to do “or else OH will die.” But this is true of every open source project. Open source development is as much if not more a human community exercise as it is a programming exercise. Some projects are better at hiding this than others. OH isn’t so good at hiding it. From what I’ve seen, HA isn’t so good at hiding it either.
OH also has a problem with a lack of maintainers. We don’t have enough to keep up with updates to the core and the huge backlog of bindings awaiting review before they can be officially included in the list. I think there are 30-40 new bindings stuck in this limbo. So the main developers are spread thin. This slows down forward progress and leaves some very important issues open for years without fixes,
As with any long time project, OH also has its fair share of technical debt and long term consequences for architectural decisions made years ago. To some extent HA, because they are much younger, doesn’t have to face this drag on development so indeed they can be more flexible, pivot faster, and over all appear to have faster forward progress than OH is capable of. In short, they don’t have to worry about legacy support and backwards comparability. And philosophically, I don’t know if they ever will. That philosophy is great for improving a product rapidly but it sucks for anyone who needs a relatively stable platform. Ironically, on their forum when people complain about the stability and breakage, lots of their users recommend OH.
It doesn’t help that we have to take on massive projects right now like the merge of ESH back into OH and the change to the build system. Because of this the first quarter (half?) of this year is basically lost to forward progress on the software itself. Ultimately at the end the simplified build system and simplification from bringing the two separate projects under one repo will make it much easier for new developers to get started and hopefully make it easier to recruit new devs. But for us users it looks like progress has stalled in development which can give the impression that it’s stalled entirely.
Honestly I don’t follow Internet influencers. I do know that the HA community seems to behave a little more as if they are under siege. I rarely if ever seen much negative written on these forums or OH related videos about HA. The same cannot be said the other direction. There is a pretty high degree of hostility towards OH on some of those YouTube channels, especially in the comments.
But HA is also “the new hotness.” No one is going to care about some article covering some old and stable open source project. They all want to talk about the hot new thing and right now I think that is HA.
However, OH as a community is not good at outreach. The focus of the whole community is here on this forum. We don’t have a Slack or Discourse channel. We have only just revived the subreddit. We don’t reach out much to the internet influencers so I’m sure many of them go along blissfully unaware we exist or, because we suck at marketing, assuming that because we are not making noise we are dying or dead. Shame on us for that. But I personally don’t know how to fix it.
I personally have submitted articles and ideas to Make:, MagPi, and elsewhere. I was made a moderator of the subreddit (if you are on reddit, please come and answer some questions or make some comments!). But I don’t know where to go from here. I personally suck at this sort of thing too.
“Better” is also subjective. For many users HA is better. It may support more of the technologies they need to use or supports it better. The Python nature of the code might be more attractive. They may like the way the UI looks better or perhaps they trust a cloud service one has to pay for more than one offered for free (supported through charitable donations). There are lots of reasons why one might find HA better than OH. For those influencers, perhaps HA actually is better.
Or both. There are some users that run both at the same time because HA has better support for some technology and OH has better support for some other technology.
To conclude, despite all the problems talked about above, OH is still growing in both capability, functionality, and in user base. I personally think the future of OH is bright.
This is the pulse of the openhab2-repo for the last month. (Public visible on github)
As you can see there is a lot going on with bnd migration and maintainers are doing a great job.
My impression is, that activity is increasing those days and the structural changes are bringing some progress.
If i am right, there are also some new maintainers, which have joined the team.
Yes there is a long queue left, but i have the hope/enthusiasm that this will change in the nearer future.
So to see this from a code based view:
Nope. openHAB isn’t dying. openHAB is changing currently.
This may prevent some users from working with it in the future, but it will also bring new users or bring back old users which waited too long for some changes.
As a user of both (mainly for the homekit support), and a frequenter of both forums.
The OH forums are by far more friendly and are able to help solve your problem. You’re much less likely to get an rtfm like reply.
I think ha feels like it’s gathering more steam, is because the contribution barrier to entry is lower. Being python based, I think it’s easier to get something going than the development environment needed for openHAB. They also have a weekly (I think that’s right) release schedule.
So while I have feet in both camps, my primary system is openHAB. And even then it’s a 2.3 version, because it’s just working. With such long release times, I feel that openHAB is a lot more stable.
Here some views from a way less skilled person than any other on this thread for whatever that is worth.
I have had an OH instance running for a few years (since OH1.8, I believe) and have been watching HA at the same time, setting up an instance of that once in a while, because it is interesting.
HA appears more dynamic and vibrant, but every time I looked into that, it appears at the end of the day like micro-changes. Once OH changes, it is significant but it does not change that often.
Choices…and consequences.
Having read about both, I remember statements from HA that a two week schedule is the dogma…just to ensure the image of vibrancy and responsiveness is maintained, OH2 seems more deliberate in this way…which of course is a pain if one waits for something important to one’s own sphere of interest.
As English is my second language, HA reminds me sometimes of learning English, super easy in the beginning, but then you are hitting weird pronunciation rules, grammar, idioms and comma rules…and suddenly it gets hard really quickly. Other language require more efforts upfront but are more consistent after that. OH2 is the latter to me, HA the former.
By extension, and now I am veering away from the language comparison, OH2 will always be more deliberate and seemingly slower, but more consistent.
This may of course just be my impression. In any case, I do not want to miss to express my kudos to all on this forum and the maintainers…thank you!! I feel so fortunate that I can benefit from your hard work and enjoy a super stable home automation, that even I as a non-expert can actually use.
So, as any volunteer activity it is hard to keep it up, but I think OH has a great strategy that is there for the long haul, even when there are ups and downs and drier periods.
I think some of the “concern” the OP had comes from the feeling that forward movement in last couple of months feels very stale in this forum. For those who only look at this forum and not at GitHub alot of what they read is we are not moving forward with updates until the build system is fixed and the merge of the core back into OH.
I read these forums daily and to tell you the truth, it feels a bit musty in here…it feels like all forward progress has stopped. THIS IS PROBABLY NOT REALITY…it’s just the perception one gets from reading that all new wanted features and bug fixes are in a holding pattern. There may be traffic, but it’s not the discussions we were having 3+ months ago about new features and capabilities.
What I also feel has been a distraction is all of the conversation about new user interfaces and how this one developer believes he wants to change OH. Please don’t get me wrong…I appreciate all of the hard work he has done and will continue to do…but it comes across as he is making all of the decisions on the path forward. I’m all for change and I’m all about progress but when did the voice of OH come down to one person? Is it because this developer is more vocal than the others?
There also seems to be no check and balance about how new features get released and how the “new” versions will break what’s currently out there. We all were fully aware of how the ZWAVE binding was going to change and how we should plan our migration…but we totally missed the boat with MQTT and Hue Emulation that it took great deals of time with hours of head banging to restore some sense of operation.
We all need to participate back into OH as much as we can…whether that’s assisting in the forums, helping with documentation, coding, or whatever you can best provide to allow this platform to grow.
To me, OH currently seems a bit lost…I sure hope it finds it’s way back to releasing new features and bug fixes on a regular schedule soon.
I’m sure some maintainers will lambast me for providing my opinion, or saying I’m complaining but I’m a firm believer in saying how I feel…how some people take it, is up to them.
It’s true: openHAB has, compared to Home Assistant, a slower development pace. The main reasons are, in my eyes, the lack of full-time maintainers on the one hand and the portly technology stack on the other hand. Home Assistant is not so strong in terms of architecture like openHAB, which also allows developers to develop add-ons more “quick & dirty” and much faster. Also, at HA you have 2-3 maintainers who obviously work nearly full-time on the project. Since Telekom dropped ESH, we do not have anyone who is working full-time or nearly full-time on the code (I hope this is correct, please correct me if I’m wrong). This leads to the situation that HA, despite it’ a bigger project than openHAB meanwhile, they still have less PRs open than we do.
So yes, maintainers are a bottleneck and I’m part of the problem. I stopped to fix the automated release process to prevent unnecessary double efforts due to a temporary structure that was made for the bnd migration. Anyhow, I think this migration absolutely makes sense and will hopefully increase development pace once it’s done.
The only solution towards more activity, more features and bug fixes is to get more people working on the project and get companies to invest into openHAB development. Any idea how to achieve this is welcome.
One word to your question:
Developers decide theirselves if and what they’d like to work on and how they implement the solution. This is not a company, you cannot force anybody to work on something that he does not agree on. So if somebody wants to work on a topic the community has 2 options: Encouraging him and try to direct him a little bit or rejecting his work. The last option is quite a bad one as it will obstruct progress even more. Regarding the first option, the influence of users is, of course, limited. Why? As I said, this is not a company, you cannot force anybody to work on something that he does not agree on. A developer either works out a solution that he also wants for himself, or there will be no solution at all.
Playing devils advocate here…but shouldn’t their be an advisory council to review what the developer proposed to change before they spend all of their time developing and testing. When you have such a large user base as we do, it’s a bit frightening to hear that a single developer could change core functions to the system to better fit what they feel is the path forward.
A single developer does decide what he’s working on, but he’s not deciding whether his changes are merged into the core. To get your changes merged, you need at least approval of one maintainer who is not yourself. For invasive changes it’ll be in most cases more than one maintainer. And of course, maintainers do also consider user discussions - in the end, every maintainer and every developer is also a user, so these groups won’t differ so much in their opinions as you may think. E.g. the decision to migrate to bnd was not taken against users - it was made to speed up the development which exactly tackles one of the major issues you claimed.
First: there is an AC. Second: for core functionality OH is very conservative, breaking changes are kept at a minimum. Third: before something is merged to master it needs approval by another maintainer and generally, bigger changes are discussed before.
But: no one wants to do further work on the „old“ PaperUI. No one (except David) developed a new administration UI. So what choices do we have: We can stick with what we have (with all limitations and bugs we see) or we can take what is offered by David (which is a nice piece of work IMO). So yes, one developer can „decide“ the way to go (in the sense that this is the only contribution forward). But the decision to take it or leave it is not a one-man-show.
never thought this was taken against users…and I’m happy that a better build process is on the way…my only comment was all of this on top of each other has caused a stall in development from the user perspective.
I agree that the work I have seen in the new UI is promising and seems to offer much more than we have today…for that I am excited. What was concerning were the comments that were being made about getting rid of this or getting rid of that (text files, etc) it seemed like David’s voice was the only one and if he felt that something was not needed it was gone…lots of the these comments were made before he was tagged as a Maintainer in this forum.
I can’t wait for OH3 and the features it will bring…but I don’t want (or would hate) to trash my system either because one developer decided their vision was right over the communities.
Please take this as a discussion, not as an attack on any individual or group.
Given how often we upset users with essentially a rtfm replies, that’s both surprising and scary. I always feel a little guilty when I resort to that kind of reply and was thinking we did it too often.
That is a huge thing and IMHO one of those “technical debt/year’s old decisions we have to live with” things with OH. The new build system the maintainers are furiously working on right now will improve matters some, but at the end of the day it’s a Java project so it’s always going to have a bigger getting started cost. That’s one of those areas we can only make it better, never solve. And that may be one area that particularly differentiates OH and HA going into the future.
I love this simile!
I love to hear experiences from users who are actually using or have tried HA. In my opinion, if there is any openHABian (pun intended) on this forum who feels threatened by comparisons with HA, they should get over it. They are doing good stuff. We are doing good stuff. There is room for both and we can both learn from each other. People with HA experience, please don’t feel hesitant to talk about both the good and the bad of HA, and vise versa.
Indeed, the devs bit off more than they expected when they decided to merge ESH back into the core and changing out the build system. There has been on going work but work that we as mere users would see has stalled development. There has been other work happening too like pulling out all of the UIs into their own repo with it’s own set of maintainers, changes to the persistence add-ons so they can become OH 2.x add-ons and more. But none of those changes are user facing. And the build problems is primarily what is preventing an M2 release and making the snapshots unsafe for daily use.
And a lot of those discussions we were having three months ago I feel, in hind sight, were more harmful than productive. A lot of feelings were hurt, a lot of users became angry, I suspect we lost a number of users, and a huge fog of fear, uncertainty and doubt enveloped the whole project. Some good came of it like the PaperUI NG design study and such, but there are some problems even there as David is really off doing his own thing more than collaborating with Yannick and the other UI devs. I actually blame some of those discussions for part of the drop of activity on the forum now.
People are still worked up over some things that were just a discussion about what could be or hypothetical ideas, or proposals offered by just one developer, thinking they are decisions made and final. That isn’t the case.
That’s the point that I think was lost in those other discussions. He doesn’t speak for OH. His proposals are just that, proposals. His proposals carry more weight than mine do because he is actually going to work on it and submit PRs. But and major architectural change to OH’s core or the way add-ons work will have to be approved by the maintainers. He was expressing his opinions, as a developer. Everyone was taking his opinion as “this is what OH is going to do” instead of “this is what I want OH to do”.
Again, his ideas will carry more weight than mine or yours because he will back up his ideas with code and PRs. A PR will always carry far more weight than a forum posting or a hundred forum postings. But OH development is a community effort and no one developer is allowed to make sweeping breaking changes without agreement and consensus from the maintainers.
If you look in github, you will see that the openHAB project consists of 45 repositories. Each of those repositories has their own set of maintainers. There is a lot of overlap in those maintainers across them but I don’t think even Kai is a maintainer in all of them. What gets included into the baseline and when for a given repo is controlled by the maintainers of that repo. There is no central coordination beyond entering a “beta” period where new PRs that do not fix known problems are not allowed for about a month before the official release.
The addons repos are a little different still in that each binding has it’s own maintainer(s). Their bindings need to be reviewed and approved by the repo maintainers but for the most part each binding has it’s own set of developers. So what gets added and when is largely controlled by the individual binding developers.
I don’t know anything about what breaking changes occurred in Hue Emulation so I can’t speak to that. For the MQTT binding a number of mistakes were made. But the biggest mistake was not realizing that the core would automatically uninstall the 1.x binding once the 2.x binding became available. That shouldn’t have happened and if it had not happened there would have been no immediate amount of work necessary because everyone who was using the 1.x version binding would still have been using it and they could have migrated at their leisure. No one realized this is what would have happened. Perhaps if we were give a bit more time to test and play with it before the 2.4 release (i.e. IMHO we should have waited and not rushed to release it as part of 2.4) we might have discovered this, but honestly I doubt it. No one would have realized that the 1.x version was going to be automatically replaced until the 2.4 release occurred I think.
In short, most of the swirl caused by MQTT2 replacing MQTT1 should have been avoided but probably wouldn’t have been even if we had a much stronger release process. The problem was caused by behavior that wouldn’t have become obvious until the release occurred.
It’s probably worth describing the release process. There really isn’t much to it. Every month we wait until there are no known bugs and snap a milestone release. Twice a year we freeze new features for a month. Work off any new bugs found in that month. Then we snap a 2.x release.
That’s it. There is not great planning or deciding what gets in and what get’s left out. It’s almost strictly time based. What happens to be done and merged before the release becomes part of the release. So for the most part, any upgrade problems caused by a binding being released is the responsibility of the binding developers. Chris did a fantastic job of managing Zwave. As much as I like the MQTT2 binding, David did not do a good job of managing the release.
Give it a month or so and we should hit the usual release cycles and the SNAPSHOTS should become safer to use again. The same amount of work, if not more, is still going on. It’s just paying off a bunch of technical debt right now which should put us in a much better position to make future releases even better and make starting up new developers much easier.
I don’t see anything you’ve said that seems overly negative or problematic.
And if but only if the maintainers cannot agree on a merge for some reason they can appeal to the Architecture Counsel to break the impasse. I honestly expect that to occur very rarely, but I wanted to make sure that the readers here know there is a way to deal with this problem.
I also think it’s a good idea for the maintainers to at least inform the AC if there is a major change that will have impacts across more than one repo (e.g. a change to an existing REST API end point) if for no other reason that the change can be more widely coordinated. Though that may not be necessary, y’all have managed without an AC before now.
Correct me if I’m wrong, but I suspect user discussions that take place on the issue in github will be more likely to be read by the developers. It’s hard to keep up with the forum I think and I suspect a number of devs may miss some important discussions here.
Actually Yannick has a prototype too. But Yannick acceded to not discuss it on the forum until Kai was ready. David did not agree to refrain so his proposal became “first to market” so to speak. I think it is important to realize that Yannick also has a prototype which has a lot of good ideas in it too and I hope ideas from both make it into whatever bets built for OH3.
They were all his opinion. And he indeed will be pushing for these changes. And the fact that he is actually contributing code means that his contribution and opinion will count far more than those who don’t contribute code.
But, like Jan said, the maintainers are users too. They are not going to approve drastic changes to the core willy nilly and he will need the support of at least one other maintainer to have his changes merged. If the changes are sweeping enough, more than one maintainer and perhaps the AC as well.
That’s why I think those earlier discussions were a mistake. User’s assumed David has more power than he actually has to unilaterally make these decisions and assumed that his opinions are the plans. David was the only developer contributing to the discussion to some extent because Kai asked these types of discussions be postponed at that time so no other developer perspective was being presented. It was all a big mess and except for my attempts at diplomacy, I’m sorry for my participation in them.
But don’t neglect to recognize that David actually moved a whole lot from his initial position at the top of the threads. He went from “no text, period” to offering many alternatives and incorporating many ideas from users in that discussion. In terms of user engagement on this forum, David has been the most active in soliciting feedback and visibly incorporating changes based on user feedback of all the developers who are working with “core” features. He deserves huge kudos for that.
