Confused on what kind of rules / rules engine I should be using

Setup, Configuration and Use Beginners
4

And you have the author here so ask if anything is confusing or not clear.

That’s pretty much the main reason I don’t use it too. That and in order to keep up my chops to help on this forum I need to be using what most newish users will be using. And Rule Templates which, I’m sorry there are not more people writing.

HABApp is very capable, is well supported, and has a lot of users so no one would go wrong by using it.

There is some:

image
image760×344 53.5 KB

It’s more or less capable depending on the language you are using. It’s not super but for JS Scripting at least the entire helper library is in there in addition to what you’ve defined in that Script already.

I think Java rules support debugging. It might be possible in the other languages too. I never really hit a point where I’ve said “I wish I could attach a debugger to this!”. Rules should be relatively short and sweet, independent, and simple most of the time. A few debug logging statements is plenty for me so far. Most of my rules (that are not based on a template) look something like this:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Large_Garagedoor_Opener
    type: core.ItemCommandTrigger
  - id: "2"
    configuration:
      itemName: Small_Garagedoor_Opener
    type: core.ItemCommandTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      type: application/javascript;version=ECMAScript-2021
      script: items.getItem('vCerberos_Status').state !=  'ON' ||
        items.getItem('Cerberossensorreporter_Onlinestatus').state != 'ON';
    type: script.ScriptCondition
actions:
  - inputs: {}
    id: "4"
    configuration:
      type: application/javascript;version=ECMAScript-2021
      script: >-
        var {alerting} = require('rlk_personal');

        alerting.sendAlert('Attempting to trigger a garage door but cerberos is not online!');
    type: script.ScriptAction

Note: that’s what you see on the “Code” tab and it’s a YAML presentation of the underlying JSON.

Notice the actual JS code here just a few lines of JS code. The rest is defining the triggers and rules proforma. The average lines of code for my non-templated Script Actions and Script Conditions is around 10, maybe less. A debugger would just get in the way for something so short.

But if you look at most of my rule templates (especially the ones I rewrote in GraalVM JS Scripting for OH 4) you’ll find they are way longer but also that easily half if not more of the code is checking the configuration so that it can produce meaningful errors for the end users. If I were writing these for myself, they’d be much simpler and much less informative with the error messages and they would easily be half the length and complexity.

There’s also the problem that stopping a rule in the debugger can have knock on effects as subsequent triggers of the rule queue up.

The help will be in the docs for the most part.

Specifically for JS Scripting you’d look at:

  • Rules | openHAB : parts of the rules and core concepts that apply no matter what rule language you use
  • Rules - Advanced | openHAB : really you should have gone through the whole Getting Started Tutorial if you haven’t already. Those users who have the most trouble with OH 3 are not new users, it’s OH 2.x users who neglected to review Getting Started
  • JavaScript Scripting - Automation | openHAB : reference guide for coding rules in GraalVM JS Scripting, the other automation add-ons will have similar reference guides or links to similar reference guides (note that except for Rules DSL, documenting the base language is outside the scope of the reference, if it’s generic JavaScript you’ll not find it documented there and need to look elsewhere like W3Schools or StackOverflow or something)
  • JSR223 Scripting | openHAB : documents all the core openHAB API stuff for rules; it’s yucky which is why there are helper libraries for most of the languages but my rule templates written for OH 3 were written with Nashorn JS without a helper library if you want to see what coding with the raw API looks like

If you wanted to code jRuby instead, you’d replace the third link with the link to the jRuby add-on docs.

These pages kind of build on each other. First you find the core concepts that make up a rule that apply no matter what language you are using. Then Getting Started gradually builds from the simplest of rules through Blockly until finally a Script Action and Condition example using JS Scripting. Then the JS Scripting add-on documents the add-on and the helper library that tells you how to interact with OH in that language. Finally, if there is something that the helper library doesn’t support, you can muck around with the raw OH API (and file an issue to get it added to the helper library).

Yes, with these docs that’s all I really needed. I have the logs on one screen, MainUI on another, and the docs open in a tab somewhere behind and away I go. I wrote the Debounce rule template in an afternoon. Time of Day State Machine took a couple afternoons. Threshold Alert I’m not sure I still have right, but it’s such a Swiss army knife of a rule that I’m not sure I’ve covered all the edge cases.

Most of the time, when I do run into a thorny trouble, it’s going to be something to do with timing between events/triggers or the like which would turn into a Heisenbug if I were to attache a debugger anyway.

5 Likes