[wiki] Getting Started with OH3: rewriting the tutorial - 8. Rules

Development Documentation
,
21

Conditions are AND. they all have to be true to run the rule.

1 Like
22

Is there a way to tag DSL file rules with “schedule” to show their cron time in the schedule section?

23

I don’t think so, at heart not in .rules files. There is no way to define a tag.

24

You could add that OR logic is used when multiple conditions are used.

You could add that AND logic is used when multiple conditions are used.

25

I also highly recommend to move all those But How Do I…? — openHAB Helper Libraries documentation to the documentation part of openhab. It just does not belong that seperated in my opinion.

26

As long as the Helper Libraries are not a part of the openHAB project, it’s docs cannot be a part of the openHAB docs.

27

hi @rlkoshak, in your example above, how would add an else statement? ie, if it doesn’t meet that condition, else OFF.

28

The conditions are used to determine whether or not to run the rule. There is no else. Either the rule runs or it doesn’t run.

If one is being pure, the Conditions should not cause any side effects (e.g. updating or commanding an Item). And indeed when using the built in conditions you can’t cause any side effects. That’s the job for the Actions.

However, one can create a Script Condition where you can write any arbitrary code so long as the last line executed returns true or false. So you could sendCommand to your light from the Script Condition.

Perhaps a better way would be to eliminate the Conditions entirely and use a Script Action. In the Script Action you would have if statements to check the conditions and send the command ON or OFF based on those conditions.

In either of the above two approaches though you will have to write code. To do this without writing code, create another rule to send OFF to the light under the desired conditions.

For example, here are my Cloudiness rules:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: vCloudiness
    type: core.ItemStateChangeTrigger
conditions:
  - inputs: {}
    id: "2"
    label: vCloudiness > 50 %
    configuration:
      itemName: vCloudiness
      state: 50 %
      operator: ">"
    type: core.ItemStateCondition
  - inputs: {}
    id: "4"
    configuration:
      itemName: vIsCloudy
      state: ON
      operator: "!="
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: vIsCloudy
      command: ON
    type: core.ItemCommandAction

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: vCloudiness
    type: core.ItemStateChangeTrigger
conditions:
  - inputs: {}
    id: "4"
    configuration:
      itemName: vIsCloudy
      state: OFF
      operator: "!="
    type: core.ItemStateCondition
  - inputs: {}
    id: "5"
    configuration:
      itemName: vCloudiness
      state: 50 %
      operator: <
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: vIsCloudy
      command: OFF
    type: core.ItemCommandAction

Codeless rules are intended for only the simplest of circumstances. When that is no longer sufficient you will have to write some code. Luckily, Blockly is an option which can let you graphically build the code (a la Scratch) for relatively simple stuff and soon even more complex stuff.

29

Thanks so much. Was thinking I was just missing something. I use two rules now but was trying not to have two rules to manage one thing. It happens though. I was also trying to use as much of the ui as well. Getting used to it and it makes it pretty easy to write the rules so kudos to the team that made that happen. I am sure that was not easy task.

Thanks for your example as well. Very helpful!

30

Hello,

can you please tell how long is it planed to support within openHAB to run Rules DSL?
I’m developing since 5 years DSL Rules, is there a automated way available to transform DSL Rules files to javascript rules files?
If I should migrate, please tell me which should be the best language, I like text file based rules.

THX

Klaus

31

For as long as the upstream Xtend and Xtext projects are maintained. There are not plans to remove Rules DSL but we are dependent on external projects who may stop supporting them. We can’t predict when that will happen but there are already signs that it likely will happen at some point.

No, they are completely different in far too many ways to write something can can translate from one to the other.

My recommendation for all Rules DSL users is to migrate to Blockly. But if you insist on files :person_shrugging: . I’d avoid ECMAScript 5.1 and Jython but beyond that it’s up to personal preference. The JS Scripting add-on provides probably the best out-of-the-box experience next to Blockly.

32

many THX for your answers

THX

Klaus