Is OpenHab Dying?

This one looks interesting, I tried NodeRED once and do not really like this kind of “visual programming”. Will give HABApp a try, thanks Rich.

1 Like

OpenHAB is not dying. The Home Assistant group makes a lot of noise and prides themselves in having a release every 2 or 3 weeks but every release breaks things. The last release they released a patch the same day.
Home Assistant needs paid users of their cloud service to support them. If you value stability stick with OpenHAB. I just moved from Home Assistant to OpenHAB. .

9 Likes

Bump :+1:

What exactly are you trying to say here?

2 Likes

Me? Agreeing with Bruce’ comment!

@J-N-K They are moving from Home Assistant and started off with a bad attitude. I did not resist the temptation to return in kind.

2 Likes

Am often using sarcasm :stuck_out_tongue_winking_eye:
These places can take themselves too seriously sometimes!

Perhaps because volunteers here are expected to solve issues with no information or indication the poster has even tried themselves.

Clicking the heart and liking the post is the appropriate way to do that. Especially with exceptionally long and controversial topics like this it’s better not to come in months later and bring it to the top of the “latest” queue.

Bump a post to get it to the top of the list so people it gets more people’s attention. I personally would only expect the OP of a thread to be bumping it.

Like a post you agree with or think is a good post for some other reason.

NOTE: New posts automatically get closed after one month of no activity to prevent this. But we were unable to apply that policy to existing posts.

6 Likes

Where do i get more information on how to write rules for openhab in Java? This is a really interesting topic. Why not use the power of Java in a Java application?

Probably, in an attempt to be somewhat user friendly OH was initially designed to use Rules DSL to be more user friendly and attract a wider user base.

It’s great that DSL is available. For easy rules it is fine and syntax stays clean. But for some more advanced stuff Java would be the next option in my opinion in terms of speed, similarity, libraries and seamless integration instead of using a completly different language like python or javascript.
If smarthome grows users would try Java for more complex rules and improve their skills. These users could then bei able to develope bindings that have to be written in Java, too. If Java was so bad and nobody liked it why is openhab 3 still a Java project?
The missing gap is between DSL rules knowledge and the Java binding development. Why does openhab hide Java from users? Users today should become the binding and system developers of tomorrow.
Ii ist even more difficult to get help when everyone uses another language. This leads to homemade fragmentation of the community.

If you notice OH3 has many other options, including GUI based Blockly.
Many people use HABApp to get the power of Python 3.

At the moment it is not clear what language will survive in openhab. Jython is out of date already and a new project sould not start with unsupported or outdated components. So i will avoid rewriting all my DSL rules in an outdated python version where it is still mit clear how good the required helper libraries - that are still not part of openhab - will be supported in future. A year ago it was hyped to use jython but now it seems Javascript is the prefered option. It seems that the project looses focus in this aspect.
In my opinion best practice stuff should be integrated.
For example it should be easy to trigger a rule writing easy to understand code like:
Every hour
Every day between 08:00 and 15:30

DSL rules are great in many parts - but cron notation is far away from easy to read. Things like that should be optimized. Then the language is not important when easy things can be done easyly. Difficult things can become easy with powerful and intuitive helper framework and the possibility to create and share own helper functions. Best practice is what should drive development.
I have no problem rewriting DSL rules in python - but at the moment this is a lot more code - at least in my case. You have to write many manual checks to just get a value that means lots of repeating and duplicate code that a framework should handle.
Conventions and a good rules framework with intuitive helper functions would make rules a lot easier to write and maintain and avoid lots errors in my opinion.
Similar to HTML/css compared to bootstrap - both ways are possible but ready to use components and a best practice standard of doing things leads to more acceptance and quicker results. And a combination of custom and framework stuff is there possible too.
A best practice rules framework that takes away lots of manual work so that you can focus on the logic and what to switch in what order is what i would like to see in openhab. Creating rules with the ui is a good direction in openhab 3. I love openhab and the stability and thank everybody working in this great project!

If you are willing to use a language addon I would suggest you try the jruby scripting. Where we are trying to create exactly what you describe.

Triggers can be defined (almost) the way you wrote:

every :day
or
every :day, at: '08:00'

(The ‘Every day between’ doesn’t really make sense, since rule triggers is an instantaneous event and not something running continuously)

We also try to abstract away much of the repetitive tasks you describe, instead of

items["Item_Name"].state.intValue() > 5

you can just type

Item_Name > 5

See the link above for more examples.

Unfortunately, the helper library might fail to install at the moment because of a dependency that was suddenly removed from rubygems (which caused quite a havoc since it also broke ruby on rails). Hopefully this can be fixed soon.

2 Likes

HABApp comes pretty close:

from datetime import time
from HABApp import Rule

class DummyRule(Rule):
    
    def __init__(self):
        super().__init__()

        self.run_hourly(self.func_every_hour)
        self.run_on_every_day(time(hour=8, minute=30), self.fun_every_day_at_8_30)
        
    def func_every_hour(self):
        print('every hour!')
    
    def fun_every_day_at_8_30(self):
        print('8:30')

DummyRule()
2 Likes

Great to hear that there is development in this direction. Will this be part of openhab what means officially supported or another standalone development? I hope that openhab doesn’t run into the same fragmentation issues like android has. It will then be hard for the community and for users because nobody has the same structure and toolset running.

@Spaceman_Spiff 's HABApp exists today.

One issue if something is included into openHAB is having any accompanying restrictions and changes sometimes out of your control. If the UI can control OH through the API, other programs should be able to as well.

It’s currently not included in the distribution, but the plan is to have it added so it can be installed like any other addon. Unlike the other scripting add-ons though, the helper library (which makes it easier to write rules) is automatically installed since it’s packaged as a ruby gem.

The fragmentation is an issue with the scripting addons, or more correctly the different helper libraries, since they all try to utilize the strengths of the respective language, but as always it’s hard to impossible to offer both flexibility and consistency at the same time. Openhab in general leans towards the former.

1 Like

It was the intent for the former helper libraries to be included too but that did not happen.