Strange behaviour in Rules UI using previous state of item

[rlkoshak (Rich Koshak)]

@brusper

Yes, that is kind of the thing that got me wondering: should an item that is a number (here Number:Power) be included in the list where the user selects what item to include in the trigger and be allowed to use numeric comparison? Absolutely if the item is a string - but a number?? I copied every step in his definition in the GUI and there were no warnings or error messages. I mean a string may have a value of e.g. “<3.0” but a number can not. No big deal, but…

I’m not sure what you are asking here. Should triggers on Number Items be allowed to use the previousState and state fields? Yes of course. There are times where a Number Item might be used with only a few discrete and well defined values. For example, maybe they are using a Number Item with a mapping on the sitemap for a three or more phase switch.

Should the UI do some sort of checking to prevent putting in a meaningless previousState and state for the various Item types? Perhaps but that’s going to be really complicated code to cover all the Item types, states, and commands. It’s not impossible but it’s going to be tedious and complicated which is probably why no one has volunteered to implement it. And implementing it could run the risk of breaking some use cases inadvertently.

@brusper

So, I guess your advice is for him to use the GUI for simple rules but use Blockly to design the conditions? Seems fair enough as I don’t think he will end up as a Haskell developer any day soon.

Yes, at least for this case where the previous state is needed. I also recommend always looking to the marketplace for rule templates that may do what you need before coding things yourself. Why write code when you can just install it?

@brusper

Speaking of scripts: There must be loads of discussions among openHAB developers/users regarding Blockly vs ECMAScript vs Rule DSL. Is there any document where the developers of openHAB describe the future of rules/scripting in openHAB? Like a roadmap if you will. Any pointer would be great.

Probably not as much that you may think. Each has their own maintainer and group of developers and there isn’t a lot of overlap between them. I can give you Rich’s opinion only.

UI Code

• UI Rules: I can’t imagine these going away at any point. Over time more interesting actions and conditions will be added making it able to support more complicated rules, but it will always be only for the most simple of use cases.

• Blockly: A lot of work has recently been put into Blockly to make it complete when it comes to OH features. And even when/if the underlying language that the Blocks “compile” into loses support, it can be adjusted to use a different supported language. So Blockly is likely here to stay.

“Legacy” Languages

• Rules DSL: will probably be pulled out of core and made a separately installable add-on at some point. It depends on the upstream Xtend project and when/if that ever stops being maintained, Rules DSL support will likely end in OH at some point.

• Nashorn JavaScript (ECMAScript 5.1): This is using a JavaScript engine built into Java 11. However, Nashorn is no longer included in later versions of Java so it should be treated as deprecated. There is an add-on that is in the Marketplace that enables the continued use of Nashorn in later Java versions when OH moves to Java 17. But it’s a really old version of ECMAScript so should be treated as maintained for legacy support. To write rules efficiently, this requires a third party library that is installed via a git clone and copy of the files.

• Jython: This provides Python 2.7 which is two years+ end of life. The upstream project’s support has way slowed down and there is no indication that a Python 3.x version will be forthcoming. It also depends on a separately installable helper library to write rules in it efficiently that is not a part of the openHAB project and requires cloning the repo and copying files around.

• Groovy: This is and has always been a niche language with just a few people using and writing about it. But it’s been supported in OH forever and I see no reason that would ever change. I’m not sure if it works in UI Script Actions and Script Conditions.

New Languages in OH

• JS Scripting (ECMAScript 2011): This is a much more recent version of ECMAScript. When Blockly needs to move off of Nashorn it will probably move here. This is the only rules language where the helper library is both a part of the OH project and included in the add-on so there are no extra steps to code efficiently. It also provides equal support in writing Script Actions and Script Conditions in the UI.

• jRuby: Of the modern supported languages it is the second most mature. My only dings on it are the helper library must be separately installed and it is not a part of the openHAB project and they were late to support UI Script Actions and Script Conditions. But if you like Ruby it’s a great choice.

• JRule: Lets you write rules in pure Java. Does not support UI Script Actions and Script Conditions at all.

Outside of OH Options

• There is at least one other language supported in the third party SmarthomeJ Marketplace that supports writing Java rules even in the UI Script Actions and Script Conditions.

• HABApp is a separate rules service written in Python 3 that interacts with OH through its REST API.

• Node Red is a separate graphical rules service that also interacts with OH through its REST API.

All of these are equally supported. Some have more continued development (e.g. JS Scripting and jRuby) than others (Nashorn and Jython) but all are equally supported.

I personally would stay away from Nashorn, Jython, and Rules DSL if you are just getting started. If you are not a coder I’d recommend Blockly. If you have no other preexisting preference for any of the specifically supported languages I’d choose JS Scripting because it’s the best documented and lest work to get up and running. Otherwise, choose based on your favorite language.