Which Rule and Script enginge to use for projects in the future?

Setup, Configuration and Use Beginners
1

Hi All,

i’m using OH now in version 4 and used until now the RULES file and ITEMS file mixed with same in the OH web UI. Meaning creating items and rules via UI.

Now i have a new project upcoming - floor heating with shelly’s - and want to know which direction i should go as read so many different opinions.

Should i continue using the route of using the file system way making use of visualcode etc like myrule.rules plus myitems.items etc. or is there a preferred way to do especially the rules and scripts in the UI. If so, which engines are the preferred ones.

2

I personally do not recommend using Rules DSL for development of new rules.

As for using text files or the UI, that’s going to be based on personal preference. Of course, if you use Blockly you only have one choice but to create rules in the UI. Beyond that all the officially supported add-ons support both text file based as well as UI based rules.

As for which language to pick?

  • pick one you already know
  • if you don’t know programming or only know Rules DSL, consider Blockly
  • if not you won’t go wrong with any of the automation add-ons

JS Scripting is probably the most used but jRuby, Groovy, and soon Jython (again) will all be equally capable.

3

Also using Blockly gives you a quick and flat learning curve to start with simple rules and as it creates JavaScript rules you can learn from them and further use them for more complicated rules in the future you don’t want to create visually.

4

Hey Both,

thanks for your swift reply. Yes you are right. Already playing with blockly to get used to it and to learn more JS.
And i already came to general question on Blockyl vs JS: is blockly not having the concept of listening to event change? Is it here being done by using time intervalls(timers)? For example to listen if a switch has been hit or a value of an item has changed. You in DLS approach you use:

rule "XYZ"
when
    Item Switch_XYZ changed
then
5

Sure it does. This comes into play when you configure the trigger of the rule: See the tutorial here:

6

I just want to add that when creating managed rules, the rule triggers, actions, and conditions are all defined independently. Each time can have any number of each and each one is independently defined.

In comparison, Rules DSL each rule can have many triggers, but only one action (the body) and doesn’t support conditions at all.

Because there can be more than one condition and action and each is independently defined, it’s possible to have one rule that uses multiple different languages at the same time. For example there could be a script condition that uses Rules DSL and an action that uses Blockly.

Since a Blockly script can only be defined in a managed rule, you almost never see the rest of the rule when it’s posted to the forum. But if you want to see everything (which is greatly appreciated by helpers on the forum), click on the code tab of the rule. That shows all the triggers, conditions, and actions in context.

7

Thank you again!
So what i took away from your advises is that it as actually a mix of OH Rules and Scriptst in order to automate.

When you say:

you mean then this ones from rules?

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Temperatur_Whz
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      ruleUIDs:
        - aebee5afd3
    type: core.RunRuleAction

I think i start really liking this approach. It gives me far more flexibility.

8

Yes. With that I can see the to triggers on changes to Temperatur_Whz and then runs the rule aebee5afd3.

9

Yes i’m currently trying to get my project done with that. Dev phase i would say.
However i really start loving this approach. I’ll post once in state when ready to share with community.

Thanks again for your great support.