Thing Status Reporting [4.0.0,)

logo

A rule that triggers when a Thing changes its status and calls a user defined rule with the Thing and information about the Thing. The conditions of the called script are enforced so events can be filtered there (e.g. only process changes from ONLINE to some other status).

The following properties are passed to the called rule:

Property Contents
thingID The UID of the Thing that changed status
oldStatus The status the Thing was in before the change
oldDetail Some Thing statuses have additional detail. For example, a Thing that has been disabled would have a status of UNINITIALIZED with detail DISABLED. If there is no detail, it will be ‘NONE’.
newStatus The status the Thing changed to.
newDetail The detail the Thing changed to, or NONE.
thing The actual JS Scripting Thing Object (see Thing - Documentation)

The original Java Thing Object can be reached through thing.rawThing. The Most of the properties besides the thing are included to make writing the rule called by this one easier to write in Blockly.

Additional conditions can be placed on this rule or on the called rule to further limit when it runs (e.g. don’t run at night).

Feel free to customize this rule as much as desired to meet your needs. You could even replace the code that calls your rule and put that processing inline.

An important note, this version works significantly differently from the older OH 3.x version of the rule template. But it works much closer to how I envisioned the original one to work in the first place but didn’t know how to configure the trigger properly.

Language: JS Scripting (ECMAScript 2021 with the openhab-js helper library injection enabled)

Dependencies:

  • OH 4.0.0 +
  • JS Scripting add-on installed

Changelog

Version 0.1

  • initial release

Resources

uid: rules_tools:thing_status
label: Thing Status Reporter
description: Calls a user supplied script when a Thing changes it's status.
configDescriptions:
  - name: script
    label: Rule to call
    description: Rule to call when one or more Things match the comparison.
    type: TEXT
    context: rule
    required: true
triggers:
  - id: "1"
    label: GenericEventTrigger
    description: GenericEventTrigger with filter
    configuration:
      eventSource: ""
      eventTopic: openhab/things/*
      eventTypes: ThingStatusInfoChangedEvent
    type: core.GenericEventTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: |
        console.loggerName = 'org.openhab.automation.rules_tools.Thing Status';
        console.debug('ThingStatusInfoChangedEvent:' + event.toString());

        var parsed = JSON.parse(event.payload);

        var data = {};
        data['thingID'] = event.topic.split('/')[2];;
        data['thing'] = things.getThing(data['thingID']);
        data['oldStatus'] = parsed[1].status;
        data['oldDetail'] = parsed[1].statusDetail;
        data['newStatus'] = parsed[0].status;
        data['newDetail'] = parsed[0].statusDetail;

        rules.runRule("{{script}}", data, true);
    type: script.ScriptAction

Did you see this discussion: rework GenericEventTrigger and GenericEventCondition by ccutrer · Pull Request #3299 · openhab/openhab-core · GitHub?

I have but didn’t really read it closely to understand what it says. But on a closer read, none of the changes seem to invalidate what I’m trying to do here. They are just some changes to the names of the configuration properties and the way the matching filter works (if I read that issue correctly). I fully expect I’ll need to adjust most if not all of my rule templates over the coming months so that sort of thing doesn’t bother me. This one was a simple one that will let me experiment with the marketplace and such.

I don’t plan on adding the “published” tag until we get closer to release so changes I have to make shouldn’t be too disruptive.

However, if I’m misunderstanding the PR and I can’t actually use the GenericEventTrigger to trigger a rule on ThingStatusChangedEvents at all I’ll have more concerns.

Ideally, this whole rule template would best be replaced with something like a Member of trigger except for Things. So I look at this as a stop gap (perhaps a long term one :wink: ).

Thanks for the heads up!

1 Like