What exactly are you trying to say here?
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.
Am often using sarcasm
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.
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.
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()
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.
It was the intent for the former helper libraries to be included too but that did not happen.
I know there were discussions about this with the jython addon, but iirc the plan was to bundle the python files in the addon bundle. The jruby addon does it instead by installing it as a gem (i.e. itâs downloaded separately from rubygems.org). I donât see any reason this wouldnât be possible for jython as well by uploading it to pypi?
I do not know. The las discussions I saw on GitHub ended in a bunch of finger pointing.
Letâs move this discussion to a thread that is a little less than two years old.
Iâll leave a couple off comments.
-
Until recently and with this explosion of new languages and other rule alternatives being worked on openHAB has emphasized consistency over catering to individual languages or technologies. This was a guiding driver of the Helper Libraries and in fact @CrazyIvan359, who has graciously taken over stuardship of them (with a little bit of my help, hopefully more help later) is activity working to normalize Jython and JavaScript parts so they work the same. When I brought up my grave concerns that the jRuby implementation was deviating from this and we risk of balkinizaton of rules I was soundly ignored. jRuby is going to do itâs own thing and will become and remain itâs own âsilo of excellenceâ.
-
A plugin for the Helper Libraries was created for OH 2.5 and itâs available on the IoT Marketplace. An OH 3 version of the add-on was never completed. And now that @5iver had disappeared from GitHub and openHAB, and given how he never really wanted to give up any sort of control nor encourage collaboration we are left starting over in a lot of ways. He was the only maintainer of the repo and with him gone that repo is dead.
So Iâm moving to mainly supporting JavaScript in the UI first and foremost. Any docs I write will be for JavaScript in the UI. Itâs all I can do right now. Rules DSL is limited (by design). All the other languages are add-ons and not part of core. The Helper Libraries are not even a part of the OH project.
And with the exception of what is being done in the Helper Libraries, nothing that is being done with Rules languages, be it HABApp, jRuby, the graals vm work @jpg0 is doing, etc. is paying any attention to this balkinizaton problem. The main focus seems to be in making rules âpureâ to the language with no thought about making it easier for users to move from Rules DSL or Blockly or whatever to theses more powerful languages. Or to move from Jython to JRuby without requiring the users to throw out most of what theyâve learned and start over.
So here we are. âCanonicalâ anything covering rules is simply not going to be possible. Long time users of OH hopefully will be able to migrate to a new language with the Helper Libraries. Non-programmers are stuck in the UI or using Rules DSL. And all the other languages will have their separate, mostly closed off but inthusiastic sub communities. Documentation will suffer even more because each language basically has to write their own docs from scratch. They are too different to share much.
When/if we have a rules marketplace it will become even worse. jRuby folks wonât be able to use my tinerMgr libraries for example.
So over all I look on the path rules are taking with frustration and sadness.