Possible to use ScriptServiceUtil or similar to get list of Things that are Offline?

Hi all,

Would like to ask is it possible to use ScriptServiceUtil to get all declared Things which are not online? I have success to use ScriptServiceUtil to get all items with NULL state, and would like to improve my error detection rule to also report when Things are offline.
There is a static method in ScriptServiceUtil to get ItemRegistry but there is no static method to get ThingRegistry unfortunately. Is it possible to accomplish what I want and if so how?
Many thanks in advance!

What languages? I’m Rules DSL you are out of luck. You can’t get to the ThingRegistry. I’m any of the other languages including Blockly, you have direct access to the ThingRegistry. In JS Scripting you just use things.

For this and other reasons I recommend against users doing new development in Rules DSL. Even Blockly is superior to Rules DSL in pretty much every way.

Hi @rlkoshak : thank you for your reply!
I’m actually not sure what language I use, but it has the Java syntax with “when … then … end” structure, and most examples that I find online are based on this language so I assume it is DSL.
Given that there are multiple languages for rules, do we have a good article on pros/cons? I have many rules in DSL and not sure if it worth the effort to migrate.

I saw in the rules documentation it is possible to listen to Thing status change:

status changed Thing when a Thing’s status changed (e.g. went OFFLINE)

But Thing doesn’t have Group concept, would it be possible in a syntax to write if any Thing changed status to OFFLINE? If so it’s a better than polling status of Things I think.

Thanks!

Again, not using Rules DSL.

JS Scripting, UI rules, and jRuby for sure have access to the generic rule trigger which could do that. Or you could use the (rule template)[Thing Status Reporting [4.0.0.0;5.9.9.9]].

Not really. They are all pretty good except for Nashorn JS and Rules DSL.

If you didn’t already know how to program choose Blockly. If you do, choose the language closest to one you already know.

You don’t have to migrate your old rules. That can remain Rules DSL. My recommendation is to not do new development using Rules DSL. The simplicity of the language had been surpassed by Blockly and yet even Blockly better supports common programming features like functions and supports the full OH API. Even the most powerful languages like jRuby and JS Scripting can be just as easy to use as Rules DSL when using their helper libraries.

The issue is I’m a Java guy and doesn’t really like JavaScript…
Is Blockly only UI based or can I code complex logic there?

Did you check JRule…

Groovy or jRuby might be good choices.

Blocky can build code as complex as you need it to be. About the only limitation is there is no equivalent for map/reduce so you have to use for loops for that.

But it’s UI only. You can’t drag and drop blocks in vim. The blocks themselves “compile” to JS.

If you like Python the Jython add-on is receiving updates again or there’s HABApp.

@hmerk already pointed out the JRule add-on and I think there’s another Java automation add-on on the Snarthome/J marketplace.

1 Like

Thank you!

To get a list of all offline Things in jruby

offline_things = things.select(&:offline?)
logger.info "Things that are offline: #{offline_things.map(&:uid)}"

# item.state? returns true if its state is not NULL or UNDEF
# rejecting them will give us only items whose state is NULL or UNDEF
null_or_undef_items = items.reject(&:state?)
logger.info "Items whose state is NULL or UNDEF: #{null_or_undef_items.map(&:name)}"

# This will exclude items that aren't linked to a thing, because item.thing will be nil
# &. is a safe navigation operator, it will return nil if the receiver is nil, and therefore be excluded from the result
items_whose_thing_is_offline = items.select { |item| item.thing&.offline? }
logger.info "Items whose thing is offline: #{items_whose_thing_is_offline.map(&:name)}"

Note the syntax .map(&:uid) is a shorthand for .map { |object| object.uid }

1 Like

I’m on DSL (there are limitations but I don’t feel it lacks major features) but thanks for the illustration.
Hope OH not plan to remove rule dsl in the further versions?

Rules DSL lacks

  • ability to call another rule with arguments
  • ability to call another rule without arguments
  • ability to be called from another rule with arguments
  • access to the ThingRegistry
  • access to the RulesRegistry
  • ability to use GenericTrigger
  • access to the Item metadata registry
  • ability to create Items, Things, or rules from a rule
  • ability to enable/disable another rule or itself
  • in managed rules a way to import classes
  • ability to create and import libraries

In addition Rules DSL

  • is slow to implement new features (e.g. triggeringGroupName had been available in other languages for a year or so iirc and was only added to Rules DSL in the past couple of weeks)
  • has a half assed “typeless” system that fails fairly frequently
  • lacks proper data structures like classes
  • lacks proper functions
  • upstream long term support for Xtend is sometimes in doubt
  • Xtend is often the source of thorny performance problems and hard to determine bugs in OH

Until Blockly, JS Scripting, and jRuby all of these limitations and missing features could be ignored because the benefit provided by the simplicity of the language were that great. But now any one of these three are just as easy to program in as Rules DSL and yet have none of the limitations or lack of features (you can even create reusable libraries for Blockly).

I cannot recommend new development of rules in Rules DSL any more now that other options have all the same simplicity without the limitations and lack of features.

1 Like

@somy You just gave me an idea to allow triggering on wildcard Things in jruby

rule "Warn when Thing goes offline" do
  changed things, to: :offline
  run do |event|
    Notification.send "An openHAB Thing  #{event.thing.label} (#{event.thing.uid}) went offline"
  end
end

This is now supported in the latest jruby library.

1 Like

I think I’ll need to look into other languages for my existing rules - could start with this, has it been added to 4.2?

If you’re asking about jruby library, yes. It is available for openHAB 3.4.x all the way to 4.3-snapshot.

The way jruby helper library works is that no matter which openhab version you’re using, you’ll always get the very latest helper library version, and if there’s a new version out, you simply need to restart openhab (or restart the jruby addon) to update to the new version.

If for whatever reason you want to “pin” the helper library down to a specific version, and prevent automatic upgrades, you can do that too, but there’s generally no reason to do so.

1 Like