Is OpenHab Dying?

[rlkoshak (Rich Koshak)]

@Kim_Andersen

I give up Rich… You simply wont understand that I´m not trying to censor anyone. I´m trying to change focus of what I believe matters most…

But you are trying to change the focus by shutting down and discouraging discussion on any topic that isn’t, in your opinion, what matters most.

I don’t disagree with your opinions or your ability to express them. I disagree with your insistence that in this case what the rules language is not relevant and should not be discussed in this thread.

Why is this topic focusing on the rule language?..

But I get concerned when I see a discussion about which language to use for rules, insted of focusing on creating a UI for drag and drop rules. Then the actual rule language doesnt really matter for the common user.

But I find it strange to discuss something which isn´t a main concern, when other things such as UI´s are in a desperate need of a makeup.

If the UI´s can take care of the rule process like a drag and drop, then it really doesn´t matter which language beeing used behind.

Discussion of which language to use for rules is, in my opinion, a high level discussion, which belong beside any other discussion of how to make opehab better for new/ordinary users, or discussion of whats wrong with openhab.

But question is, if this is a major concern above other things…

I´m concerned that high level discussions may drive even more potential new users away, rather than trying to welcome them at their level which, in my opinion, is highly needed.

trying to change the focus to where I believe would matter most for openhab in general.
I could be wrong

Its me trying to put the priorities into perspective.

But it can also become a signaling problem

Because they´re already advanced users. They dont struggling trying to comprehend openhab.

All of these outright state or imply that we shouldn’t be discussed in this thread. I vehemently disagree and fully expect that stuff like this would and should be a part of the “Is openHAB Dying?” discussion.

@matt1

Home Assistant has sold the $5 a month as a fee for “premium features” and not just access to their cloud. This means the plan is to add features that only paying people access, the longer the scheme is in place the further they will migrate from paying is optional to being that the software really needs the so called optional package. Openhab may see a lot of people migrate over here because of this decision and it may take some time for this to be seen.

They might be making a bet that the cost of migration will be great enough that most users will just pay the money to avoid that hassle. Couple that with the fact that, as mentioned, openHAB isn’t even part of the conversation in home automation communities outside of this forum. I’ve seen a bunch of “Home Automation Comparisons” that all include HA and none of them even mention openHAB. In maybe one post out of 10 on the smarthome and homeautomation subreddits mentions openHAB as an option. This is what I mean by our community not being good at marketing. Those HA users may get fed up and want to leave but wouldn’t even know about the existence of OH because we are not part of the conversation.

I posted another thread already and will repeat it here. If you are at all active on reddit or follow the internet taste makers, please contribute and speak up in the comments. Let the wider community know that we are here, we are active, and we are a viable option.

@delid4ve

My only real contribution would be to say a ‘how to’ / ‘explanation’ creation of a very simple binding.

I believe David already has one written and it’s awaiting approval for merge. One of the improvements that we should see from this big merge of ESH and change of the build system is a much easier getting started building bindings process.

@delid4ve

w3schools has this down to a T with html for instance, examples and clear English explanations.

w3schools is a much larger organization with far more people contributing to their tutorials. We do what we can with the people we have and that means not reproducing documentation that exists somewhere else. But don’t confuse bindings with Rules. They are totally different things.

@Thedannymullen

hass.io and home assistant…

My assumption was hass.io was akin to openHABian. Maybe I’m wrong.

@splatch

One of guys who been involved in whole process opted to work on places which haven’t been hit, however his opinion was ignored. After a year when planes with new designs were flying it turned out that the one guy which voice been ignored was right.
The problem were not hotspots created from airplanes which have returned.

Unfortunately, there are two places where this analogy fails in the OH context. First of all, there is no authority to say what the developers actually work on. So there are no army commanders to direct the engineers to start work on that. But, that also means there is no one in authority to tell that one guy working on other areas he can’t do that.

@splatch

To reflect this story - maybe all topics which are turning to be so “hot” and controversial on forums, are not these which we should look for in first place?

Honestly, I don’t believe they are. It takes a huge amount of time to monitor threads like these and I suspect most of the developers prefer to spend their time writing code instead. That’s why I get frustrated with “OH should do it this way or focus on this first or else I’ll quit/you won’t attract new users/the apocalypse.” By the time these sorts of comments get made in these threads, what few developers who were following the thread have long since abandoned the thread. It’s just users who are strongly expressing their opinions at each other.

@123

I’ve watched a lot of videos about Home Assistant and the one thing I recall them all saying about openHAB is … nothing.

Bingo!

@crxporter

TL;DR: OH is too much for me, I understand Javascript better.

Just to be clear for future readers, you can write rules in OH in JavaScript right now. And in the future, it will be one of the “default” languages instead of Rules DSL.

@crxporter

I don’t have any desire to build JSON parsing into my OH setup for 35 Insteon switches, mostly because I understand how to do it in JavaScript but have no idea how I would get that into OH.

Write JSR223 Rules using JavaScript would be a good option. Though the JSONPATH Transform and MQTT2 binding should be adequate in most cases. But if you are comfortable in JavaScript, I is (and always has been) an option.

@crxporter

eventually I’ll have to rewrite all of my rules

Probably not. Deprecating Rules DSL doesn’t mean eliminating it. It just means that it won’t be the language recommended for use any more. IMHO we cannot afford to force all current user of OH to rewite all their Rules. The developers I know working on this agree and appear to be working towards continue support. It just might mean you have to install something separate rather than support coming with the base install in OH 3.

@lewie

Browse a bit here, if it suits you: https://github.com/lewie/openhab2-javascript/blob/smarthome-To-openhab.core/SimpleRuleExamples.js

I’ll also recommend Jerome’s recent migrating from Rule DSL to JavaScript tutorial. Migrating DSL Rules to JSR223/Javascript with a case example

I’m not arguing that @crxporter is making a bad decision, just providing clarity about some alternatives and options for future readers.

@crxporter

Essentially I’m scared of messing with my OH deployment in the same way I wouldn’t poke a bear in the forest. It’s fine how it is, I’ll almost certainly break it if I try anything.

I find a solid backup and restore process and/or running a separate development instance of OH is freeing in this regard.

@crxporter

The node red developing environment works better for me. As I said in my first comment, there are arguments and fixes to everything I have problems with but I personally would rather invest the time into node red.

Don’t necessarily take Lewie’s and my responses as arguing that you are making a mistake or a bad decision. But these posts persist forever and future readers may come to a different decision based on the additional information we provide.

@crxporter

So new development is happening but to get involved I either have to wait months for a 2.5 release (then maybe 2.6 if there were bugs!) or I have to run the potentially unstable 2.5 milestone.

All OH releases are essentially “At this point in time we are aware of no major breaking bugs.” The only difference between a release and a milestone is the release gets a little more testing immediately prior to release. Based on my experience, the milestone builds are no more or less likely to contain errors than the release. And the closer the milestone is to the release the less likely it is to have problems. I would say that 2.5 M1 is exactly as reliable and usable as 2.4 Release and do not hesitate to recommend it’s use, particularly if you use MQTT or Zwave as there were bugs discovered after the 2.4 release that got fixed.

All new development takes places on the next version. Since 2.4 is released, all new development, including bug fixes, takes place on 2.5. If a major bug is discovered, it might be back ported to prior versions of OH, but I’m not aware this has ever happened.

And for OH 3, this too is being addressed, or at least talked about. There are discussions about separating the bindings from the core in a way that would let us choose which version of the bindings we want to install rather than needing to manually install or wait for a new version.