You code Rule 1
You create Rule 2 from the Template, filling out the properties as desired.
The data flows:
Rule 2 → Rule 1
The data is a List of Thing objects named “things”.
Rule 2 collects the Things that match the criteria and passes them to Rule 1 for further processing. All that the rule template above does is create that list of Things (e.g. all Things that are not ONLINE). Nothing more.
You need to be on the latest milestone. Then go to Settings → Automation and add the template from the list.
Which seems to work fine.
However, the things are cryptic: org.openhab.core.thing.internal.ThingImpl@bc5a35e
Is there a way to translate this?
I know how to work with transformations like MAP, but where to look for the reference of this thing?
(your Threshold Alert rule returns the ItemLabel if I am not wrong)
Threshold Alert sends a List of the Items that are NULL or UNDEF, a comma separated string of the labels of the Items that are NULL or UNDEF, a List of the items that meet the criteria, and a comma separated string of the labels of the Items.
It’s all explained in the Marketplace posting.
The Thing Status rule template sends a List of the raw Thing Objects that match the criteria. What you are seeing and call cryptic is the name of the Class that implements the Thing and the @bc5a35e is the address in memory.
You will need to call methods on the Thing Object to get information out of it and I’m not sure Blockly supports that. Consider using Rules DSL (since I bet that’s what you know best) for this one Script action. It’s not a problem to have more than one language going in your set up.
The reference for this and all other openHAB classes are at Overview (openHAB Core 3.3.0-SNAPSHOT API) (or something like that, I’m having weird issues on my phone bringing up pages right now so can’t double check). Search for “thing” and you’ll find the doc for that class.
That’s not neccessary, Rich.
Even a single check from you is more than enough.
So, thanks for the explanation I will build in my DSL rule stuff for this topic then.
I have a lot of well working DSL rules, but try to move as much as possible over to mainUI rules - (preferrably Blockly). Maybe it’s better to move slowly on my migration path.
Yes, thank you.
I did this for some rules (e.g. geofencing with Location items within a group).
Maybe I should look into JS direct for the future, but will start with my DSL code for now.
Again, thanks for your help, Rich.
But what about this:
which in code is this:
is this the same like
you are referring to in the threshold-alert thread?
or is there no way to get the context attribute from the Threshold-alert in Blockly?
You can get the things and you can probably even manipulate the List of Things. But I don’t think you can then call any of these methods on the Thing Objects which means you can’t even get the name or uid of the Things that are offline from Blockly.
I assume though that you can get to the variables passed to the script using Rules DSL. In Nashorn it’s called context and it has a comtext.getAttribute('key'). In JSScripting the passed in stuff just appears as a variable. So the things is just directly accessed (see below).
I don’t know whether or how it appears in Rules DSL. I would assume it’s one of these two ways.
Here is my script that gets called by the Thing Status Alert for reference. It’s in JSScripting.
configuration: {}
triggers: []
conditions: []
actions:
- inputs: {}
id: "1"
configuration:
type: application/javascript;version=ECMAScript-2021
script: >-
var logger = log('Thing Status Processor');
logger.debug("There are " + things.length + " things that are not ONLINE");
type: script.ScriptAction
@NCO sorry for resurecting this, but I was wondering if you had found a solution to display a “readable” list of things that were offline and if you would mind sharing it?
I know i resurect an old topic, but i think it complements nicely the Thing Status Reporting.
Thanks,
update: Don’t use the following blockly example. There is a better one further down that uses the original marketplace rule from Rich.
Hi Rich (and @NCO, @thefathefa),
I changed/extended your rule a bit, especially since I wanted to see readable names (labels) of the offline things… but then I did a little bit more… Maybe you can use something for your next revision, or somebody else likes it. I thought the whole solution might be nice for the marketplace but I didn’t want to steal Rich’s code. Tell me if it’s better to start a new thread. The changes are:
Filter all things that are not ONLINE or UNINITIALIZED (to see things with initialisation problems too. You get the things with status INITIALIZING, OFFLINE, REMOVED, REMOVING, UNKNOWN for further processing.
Export of labels, IDs and status. (As far as I understand, the values of the context hashmap are passed as strings. Please tell me if there is a better way than passing as arrays)
evaluation rule with Ignore-list for things to be skipped, that sends telegram messages when things are offline (love it).
Cron-rule with changes at the end
if(typeof(require) === "function") Object.assign(this, require('@runtime'));
var logger = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.model.script.rules_tools.Thing Status Change");
var ThingStatus = Java.type("org.openhab.core.thing.ThingStatus");
var FrameworkUtil = Java.type("org.osgi.framework.FrameworkUtil");
var ScriptHandler = Java.type("org.openhab.core.automation.module.script.rulesupport.shared.ScriptedHandler");
var _bundle = FrameworkUtil.getBundle(ScriptHandler.class);
var bundle_context = _bundle.getBundleContext();
// Get the Thing Regsitry
var classname = "org.openhab.core.thing.ThingRegistry";
var ThingRegistry_Ref = bundle_context.getServiceReference(classname);
var ThingRegistry = bundle_context.getService(ThingRegistry_Ref);
// Get the RuleManager
var classname = "org.openhab.core.automation.RuleManager"
var RuleManager_Ref = bundle_context.getServiceReference(classname);
var RuleManager = bundle_context.getService(RuleManager_Ref);
var things_Label = []
var things_Id = []
var things_Status = []
// Get Things that are not online
ThingRegistry.stream().filter(function(t) {
return (t.getStatus() != ThingStatus.ONLINE) && (t.getStatus() != ThingStatus.UNINITIALIZED)
})
.forEach (function(t) {
things_Label.push (t.getLabel() );
things_Id.push (t.getUID().getId() );
things_Status.push (t.getStatus() );
})
logger.debug("There are " + things_Id.length + " things that are not online");
// Call the handler rule with the lists of IDs, Labels and status
if (things_Id.length > 0) {
var data = new java.util.HashMap();
data.put("id", things_Id);
data.put("label", things_Label);
data.put("status", things_Status);
RuleManager.runNow("Alarm_offlineThing", true, data);
}
else {
logger.debug("No items match the criteria");
}
evaluation rule (blockly). To use paste it in the code tab of an empty rule
The blocky rule should look like this. You need the telegram binding and the telegram-with-chat-ids blockly library from the marketplace. Finally you have to change the bot and chat-id to your needs (see doc of telegram binding).
The original rule template supports this too. Choose ONLINE for the status and != for the comparison.
This is why I pass the full Thing Object to the called script. With the Thing Object you have access to all of the properties of the Thing.
I think it’s better to keep it to passing the Thing Object because you get not just these three properties but access to all the Thing info like the Channels, location, properties, the ID of the bridge, and the ability to change the Thing (e.g. change the properties).
This is deliberately left as an exercise to the user to implement in the called rule. The end user writes a script to filter the list and send alerts or taking what ever remedial actions they want to take. That part is custom. The rule template should not make assumptions about what the user wants to do with the list of Things that match.
The rule that’s called can define a condition to only run when certain Things appear in the list. They are passed as a Map so all you need to do is check to see if the Thing ID you care about is in the keys.
Given this, I’m not seeing what this does differently beyond remove some capability from the original. Because it’s not a rule template, it cannot be installed and instantiated. The Thing status it looks for is hard coded. And it passes less information to the called rule. But it does show that there might be something I can do to improve this template’s use for Blockly users, but that needs to be in addition to, not in place of passing the Thing Object.
The Blockly rule you’ve posted is a good example of the sort of thing that can be done in response to being called though and with only minor modifications it should be able to work with the original, though you might need to use the script block to access the properties of the Thing Objects.
Note, when posting Blockly, post both a screen shot and the contents of the “code” tab in code fences.
```
code goes here
```
This rule template will be completely rewritten for OH 4 by porting it to ECMAScript 2021, taking advantage of the JS Scripting helper library and my own helper library, and possibly changing the triggers so it can run based on events rather than a polling period.
Generally speaking, if your goal is to suggest improvements to the original it’s proper to post here. If your goal is to provide an alternative to the original, it’s probably best to start a new thread. However, pay mind to the marketplace rules. The moderators want to avoid a proliferation of lots of alternative implementations of the same thing, confusing end users and making it difficult to keep track of. So it would probably be posted to the tutorials and solutions category.
I like the example for a script to be called by the original script in your blockly and it appears your aim is to improve the original script so I think it’s appropriate here.
I tried but somehow could not access any properties in the called rule. That’s why I thought the object is not passed as a reference.
That’s basically what my called rule does, not in the condition but in the action.
I tried that, but .getLabel() returned nothing. But I’ll try again after the transfer to ecma 2021.
That’s what I did. You have the code collapsed under “…evaluation rule (blockly)…” above the screenshot (in code fences of course;).
Anyway, thanks for your reply and helpful hints.
It was ecma 21 in text based script action.
Today I tried again in blockly and… it worked on the first try . I cannot tell what I did wrong.
Now it works with your template rule.
Here the code (for pasting in code-tab of new rule):
I am a little lax on the rules but please do keep in mind the rules for marketplace postings. The discussion thread should be strictly about the top post. It’s not a place to post alternative implementations unless they are suggestions to merge with the original post.
The marketplace isn’t like other sections of the forum. These are not tutorials. These are published artifacts visible from and installable from MainUI directly. The threads should remain very on topic to avoid confusion and to keep them from becoming too long to manage.
Finally, as with all of my rule templates, this one has been rewritten in ECMAScript 2021 for OH 4. See Thing Status Reporting [4.0.0.0;4.1.0.0). The capabilities of the rule have also improved.
the rule now triggers on all Thing events instead of polling
it passes the thing ID, old status, old detail, new status, and new detail, and the actual Thing Object to the called rule instead of a collection of all the Things that are in the given state
I would like to try the 4.0 version of the template but I don’t know how to read the passed parameters from the called script. I didn’t find anything about it…
It would have made more sense to comment on the 4.0 version of the template’s post.
How you access the passed in parameters depends on the language being used in the called script. If JS Scripting you just reference it by name. If Blockly it’s in the context block. Nashorn it’s in context. I don’t know about Rules DSL or jRuby.
. I cannot tell what I did wrong.
