Is OpenHab Dying?

113

@rlkoshak very good points as always. I need to point out that when I got started with OH I didn’t know that JavaScript would be my favorite. My previous programming experience at that point was HTML in junior high and MatLAB in college. I had found shortcommings in HA and was moving to OH so I used the xtend rules as they are well documented in the forums and that’s where I was learning things.

From there I started “branching out” into the openhabian optional installs, found Node red, and got hooked. JavaScript didn’t “click” for me until after having a full setup in OH.

Obviously if someone is a JavaScript pro they should use JSR223 rules.

My reasoning for having to rewrite my rules is not completely to get away from the “old” rules. It’s also going to be caused by evolution of my house, abandonment of the OH 1.x insteon binding, and the desire to add more into my system.

Also if the DSL is depreciated there’s very likely going to be new features of whatever causes that depreciation… At that point I assume users will either run two sets of rules: old stuff in DSL that they are reluctant to change and the “new rules engine” (which is still experimental?) with new features.

Are there even more ways to program rules? The rules link on the “introduction to openhab” page goes right to a document on DSL rules in Xtend. There is no mention of any other language there. There is a link to JSR223 Scripting on the sidebar but honestly I didn’t know what that meant until the last couple of days reading this thread… “JSR223” looks to me like another layer of OH that I don’t fully understand and isn’t well enough used in the forums that I feel like there will be decent support. Everything seems so complex to someone like me who hasn’t used JSR223 and too often you have to know what you’re looking for to find what you’re looking for.

I did ask sooner here. It was my first day according to that comment. Two comments down I was trying to install his fork of the homekit binding (I tried this for about 2 weeks actually) with no success. At that point I didn’t know where to get help - now I know I should have come to these forums.

Even installing a beta binding is something I’ve never gotten to work. I’m sure I’m doing it wrong but reading the forums I decided I may be interested in the apple tv binding which has a link to a jar file and I’m only about 75% sure I know where in my system to put that jar file.

My experience updating from 2.3 to 2.4 was that it broke random of my insteon switches each time I restarted. I eventually got my .items files cleared up and cleared the catch which cleared up my issues after about 2 days of struggle. The risk of another upgrade issue does not (for me) outweigh the benefits of dropping a bug on mqtt or being able to use experimental bindings…

Future readers:
Don’t get me wrong, OpenHAB is a great program and can do many things. At this point in time (May 3, 2019) I am planning to move on in the next few months sometime. The main cause of concern for me are the downfalls of the Insteon binding and my own personal unwillingness (or lack of time) to commit to learning more about OpenHAB. Check with me in a couple more months, there’s a huge chance I’ll have changed nothing.

1 Like
114

You are fully right and we are on it. I have started a discussion thread to improve this for the future.
Improve the jsr223 doc and show users that there is more than rules dsl in the docs directly.

3 Likes
115

It’s always been there but until some recent pushes it’s always been nitch. In the past few months Scott, Lewie, David, and others have made great efforts to improve the usability and capability of JSR223. And the Next Generation Rules Engine, which will let us create Rules through the REST API (e.g. PaperUI) uses the JSR223 languages for custom code AND it both sets run on the same Rules engine. But in answer to your question, yes. JSR223 allows you to write rules using JavaScript, Jython, or Groovy. There are other external tools that aren’t part of the OH project that some users use as well, including NodeRed.

Jerome has started a thread to begin to address the documentation problem and over the next six months or so I expect that we will see many more postings showing those languages instead of Rules DSL. I’ve a task on my plate to add at least one JSR223 version of all of the Design Patterns (where applicable).

So yes, for a time and even now, the documentation and usability of the JSR223 Rules are not as high as Rules DSL. But we are working to change that. And for OH 3, these will replace Rules DSL in those sections of docs. Like I said, none of this is really directed at you because given your path you are heading in the direction that makes sense for you. But a new user on this forum will not have the history or decisions to deal with and choosing JavaScript might be a good choice for them.

116

The new developer documentation has been merged. It will be amended once more when the migration is complete (which should be in a few days).

@Confectrician I’d say we rename Rules DSL to “Legacy Rules” and put all related documentation in a “Legacy support” section. I’d really not want any new person coming to openHAB to write Rule DSL rules. But yeah have to be decided on the corresponding thread.

5 Likes
117

openHABian’s counterpart, in Home Assistant, is Hassbian. It’s a ready-to-burn disk image for a Raspberry Pi, containing a tweaked version of Raspbian and a pre- partially-installed version of Home Assistant (in a python ‘venv’). The counterpart of openhabian-config is hassbian-config. All-in-all, very much like openHABian.

Hass.io is unlike anything I’m familiar with in openHAB. It is available as a disk-image for an RPi but, unlike Hassbian, employs two Docker containers (one is Home Assistant, the other is a hypervisor) and a bare-bones Linux OS.

The goal is to shield the user from the Linux command-line and make most everything GUI-based. One of its strengths is the ability to add a major functional piece, like Influxdb, Grafana, nginx, etc, by simply selecting it as an ‘Add-on’ from the ‘Add-on Store’. There are official Add-ons and user-built Add-ons available. Configuration is reduced to filling out a form and, presto, you have nginx running.

The hypervisor can do maintenance chores like create ‘snapshots’ (backups) and even perform automatic upgrades.

In a nutshell, Hass.io and its Add-ons are customized Docker containers. Naturally, anyone who knows their way around Docker, and a docker-compose.yaml file, can duplicate most of this functionality. However, Hass.io doesn’t require you to know anything about Docker.

Personally, I don’t run hass.io but, according to the last published statistics (many months ago) at least half of the community uses it. My own impression is that it’s a clever concept but can be quite taxing even for an RPi 3B. Users who love its convenience but not its lethargic performance, migrate to installing it on a micro PC (like an Intel NUC). In other words, Hass.io is also available as just the two Docker containers minus the bare-bones Linux OS.

118

So the goal of Hass.io is to create a software appliance. I’d like to see OH move in that direction at some point but there are clearly more important things to do first, and it’s a huge effort.

1 Like
119

I think the main point everyone forgets that iot is in its infancy, jeez I can’t even get a Zwave double plug socket for the uk market. I feel it’s just starting to really boom, pushed along by the likes of Apple HomeKit, amazon Alexa and google home.

From a ‘normal’ (and by this I mean no offence, non developer type of person), they go and buy a hue bulb and an Alexa, then they get the bug… just like me, before long they are adding all sorts. Then it dawns… I’ve got an app for this and an app for that I just want it all together.
Ok, HomeKit does this to a degree, but then you have to have Apple TV/iPads to do very basic automations, the same goes with google/amazon. It’s not customisable enough and only really works for mainline big brand retail companies. So they go looking…

I started out with an rf light switch which led to a harmony hub to control my entertainment… now it’s pretty much everything in my house, even my tumble drier and coffee machine.
When I first started out I wasn’t bothered about overly complex rule engines and lovely gui’s for control panels, I just wanted something that could combine ALL my devices.
What I’m trying to get at is I chose openhab for 3 reasons only:
1: it supported out of the box 80% of my gear
2: it was easy to setup and get the basics working
3: it was stable
In my opinion if openhab is to continue to grow these are the 3 most important things to draw new run of the mill gadget guys in. Yes more advanced users may want new rule engines and more JavaScript, but the foundation and building block shouldn’t be ignored as this is what I feel stands it out from the crowd in the first place and the quality and selection of bindings is by far the most important as we all have different gear in the first place.

I feel like I’m moaning, but I’m not, I think openhab is a great platform, and I therefore want it to survive and grow. I will input as much as I can, which will probably be in spits and spats due to work, but I get a lot out of it and it’s free so will put back in where I can. If anyone’s watched the box set ‘Scorpion’ I feel it’s much the same, it just needs a bit more EQ rather than IQ.

4 Likes
120

Great news as the way it was worded from memory was that future features would be delivered (plural, more than 1) and did not name the feature/s perhaps the scope had not been defined at that stage. Of course written posts can convey confusion, so thank you for clearing it up. I have no idea if in the long run the move to a $5 a month cost is a smart or dumb move, it could go either way and I suspect it could take 1-2 years to know. My concerns would be the same if Openhab took this route. Push requests from entry level coders (I count myself as one of these so I mean no offence) that constantly change code are not the same as quality coders written by a limited number of users that fully test and refine code before it is pushed. I really do hope it works out as I like the fact that there is another package besides Openhab in case my goals do not line up with the direction that Openhab takes in the future. I am more than happy that my choice with Openhab is the better one just as I am sure you feel the same with your choice.

BTW congrats on getting into the list of fastest growing opensource projects on Github. If there is ever a way that both projects can work together please feel free to suggest it.

Yes true and also the fact that as home automation becomes more mainstream and popular the number of ‘noobs’ increases that do not know how to safely secure remote access. Only 6-8 months ago there were a number of HA users that had people hacking in and leaving notes to them that they were open to the world. The statement that the clouds for both HA and OH are “optional” is for some people I feel is wrong as they lack the skills or time to learn how to do it. My personal goal is to remove the need for a cloud which is why I love and hope to check out Habot soon.

I have never seen a single call for donations and that makes me feel comfortable that OH is not Dying and also the cloud has a number of times needed upgrading as it has been growing in use. All good signs.

Maybe you and others should check this first video out and consider subscribing to the channels and like the vids to say thanks for making the videos.

yoyoTech (Spoiler alert he likes Openhab and mentions HA in multiple other videos)

MK Smarthouse channel
https://www.youtube.com/channel/UC1WPn_mBd7eDmz7lMSXR5bA

SuperHouseTV
https://www.youtube.com/channel/UC75HTMhqVZs0sPOMTMQqI9g

BK Hobby
https://www.youtube.com/channel/UC82xXciVxsQKthONKeYbhnw

1 Like
121

If there was the desire to pay for a developer then presumably we could simply set up a new entity to do that. In the UK one would do this with a company limited by guarantee; it wouldn’t usually be taxed on the contributions it receives (on the basis those contributions are non-taxable gifts). The time/cost/administration of registering as a charity wouldn’t be worthwhile.

I expect this isn’t a runner for a variety of reasons, but if it ever was, and the entity was to be established in the UK rather than Germany, I’d be happy to help with the legal side.

122

I don‘t think there was a need to pay a developer in the past, so we are fine with the foundation. I don‘t know if there will be such a desire in the future.

123

Yoyotech MK Smarthouse, and, BK Hobby are active on this forum and I do watch their videos. My comment was meant to be hyperbole and not taken literally. BK Hobby (i.e. @bartus) is the person who got me on the marketing kick in the first place.

All of these changes are great and doing great work and not leaving it oh.

124

I’m a User since OH 1.6. For me OH is dying slowly. The last Update from 2.3 to 2.4 with the new MQTT almost got me to stop using it.
Why?
OH does strange things I’ve never seen before:

  • my beloved MQTT is gone
  • understanding the new MQTT 2 takes me hours of reading the documentation again and again - without this forum i would still be reading…
  • the MQTT 2 stops working after a while - i’m sending too many MQTT-Actions in Rules - this never happens with MQTT 1
  • with MQTT 2 the mqtt-eventbus is gone (using MQTT1 with MQTT2 is not recommended)
  • in Configuration - System - Add-on Management - include Legacy 1.x Bindings is disabled but i get error-Messages in the Log from an old use of max-cul-binding.
    I had no luck finding an old .jar Binding File
  • Settings for Persistence Service MariaDB changed apparently to older values - while running
  • Network Binding is unable to Discover (fixed in 2.5 M1 thanks to @Rich)
  • some more i’ve forgotten (luckily)

Text based configuration in OH 1.x was the way go. After a while, the syntax was learned and the system works as expected. OH 2 became automated with Paper UI - but not entirely- you still need to have a text based sitemap. Confusing.

As often pronounced - OH 3 plans to cut off text based configuration. A nightmare if you use hundreds of items - created easily with find&replace in a Text-File.

Servus
Olli

1 Like
125

Why did you not stay with the original MQTT binding…it’s still available.

126

Can you quote the sections of this thread where people in development have pronounced that?

This conversation has now featured comments from people who believe OH cares too much about text-based configuration, and comments from people who believe OH is completely doing away with text-based configuration. I’m not sure why people only see the one-sided text-vs-GUI claims, yet ignore all of the people saying that OH can do both.

1 Like
127

Not gone. There is a behavior that has been part of OH 2 since the beginning that no one realized would impact the roll out of MQTT2. In short, if you have “Show legacy 1.x bindings” turned off, OH will not show a 1.x binding that also has a 2.x version. What no one realized is that on the upgrade it will also uninstall the 1.x binding and replace it with the 2.x version. This one thing was the source of a huge amount of the problems experienced by most of us.

But if you enable “Show legacy 1.x bindings” you can install and run MQTT 1.x just as you always have.

If you are using the MQTT 2 binding, you should be running the 2.5 M1 version. There were tons of bugs fixed in that short month between 2.4 release and 2.5 M1. Do you have the same problems with 2.5 M1? Have you filed an issue?

Why? I’ve not seen that recommendation. Quite the opposite in fact. And there is a way to duplicate the eventbus using a short rule and an event Channel that subscribes to all the topics below a certain point.

That setting does not remove 1.x bindings (except in the situation described above). Fixing problems like this are almost always solved with Clear the Cache.

The big thing I notice though is that all of the problems sited are with individual bindings. While certain bindings like MQTT should be rock solid and reliable (and the roll out of MQTT 2.x was a huge problem and the 2.4 version was neither rock solid nor reliable at the 2.4 release) there will always be a mix in the quality of individual bindings. Every binding has it’s own set of developers and maintainers. Some have been all but abandoned. Some are new and undergoing active development. So there will be problems like these. It can’t be helped as far as I can tell without limiting the number of bindings to just a dozen or so highly controlled and maintained bindings as opposed to the 330+ we have now.

But even for this problem there have been some talk about ways to address it. I’ve seen ideas floated to allow OH to run multiple versions of bindings which will let us break the binding versions from the OH core version. That way we can find and install any version of a binding through the PaperUI interface. I’ve also seen talk of having a rating and comment system so we can rate and comment about the quality and usability of individual bindings.

No no no no! OH 3 plans to change the format of text based configuration and provide a way to migrate your existing text based configs to the new format. The way that text based configs are loaded will like change too (i.e. you have to initiate the load instead of OH polling a directory).

And the replacement for PaperUI will also have text based find & replace in the text configs through the browser if you don’t want to maintain your configs separately in text files. And OH 3 will have a way to do everything through the UI for those who prefer to, including sitemaps (or whatever sitemaps become).

2 Likes
128

Why did you upgrade if everything was working?

129

Some of the questions are unexpected.

Yes, but with updating OH 2.4 it was replaced with the new Version. So it was intended by the developers. So i have to switch over.

This was a good question. I’ll never do that again.

@rlkoshak: Thanks again for tuning in. I’ll try to use OH 2.5 M1 and use your recommendations. The recommendation for not using MQTT 1 with MQTT 2 came from a Blogpost i can’t find anymore. Sorry.

Servus
Olli

130

This I can relate to as well. I do not find PaperUI items having a good overview. The same goes with things, but there are often less things than items, and it´s easyer to find ie zigbee things rather than trying to find items related to zigbee things…
I have no idea yet, how I will react, if text based configuration files is cut. I would prefere to have both available options.

131

Hmm, I think there has been some rumors about text based configurations files beeing cut… Or maybe thats just misunderstandings… I wasnt sure.

132

I partly understand your question… But please dont use it in general. If nobody upgrade, because their system is working, I would say developement is beeing challenged.

1 Like