[Rules DSL] Get item from string name!

Tags: #<Tag:0x00007f616db70ea0> #<Tag:0x00007f616db70dd8> #<Tag:0x00007f616db70c48>

Could something like String toLowerCase() help?

No, it’s case sensitive and there is no way around that.

OK, i rewrote my map file to handle it. However I have another issue now:

val dimmer=ScriptServiceUtil.getItemRegistry.getItem(roomName +"_Dimmer") as DimmerItem

Makes my rules fails if the item does not exist:

2019-04-23 22:02:23.284 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Update lights': Item 'Hallway_Dimmer' could not be found in the item registry

Is there aworkaround this issue? I just want to ignore the item if it does not exist:

if (triggeringItem.state ==0) {
		logInfo("Notification", "Group to set OFF: " + group.name)
		group.members.forEach[ i | i.sendCommand(OFF) ]
		dimmer.postUpdate(OFF)// ignore this if dimmer does not exiost

You should create a new topic to request help with your rule, as it is not pertinent to this tutorial. Include your full rule and the functionlaity you are trying to achieve, as it looks like you may be making things more complicated than they need to be. Ping me on your new topic and I’ll be glad to assist.

@5iver Point taken,
However I have used ur tutorial with great succsess until today when an item does not exist in the register:

Rule 'Update lights': Item 'Hallway_Dimmer' could not be found in the item registry

So if there is no workaround, is it possible for you to update your original post with this line:

Note when using ItemRegistry it is important that the item EXIST otherwise your rules will FAIL!

You’re rule has a configuration error, as it’s trying to get a nonexistent Item from the ItemRegistry. If the Item does not exist, ItemRegistry.getItem() throws an ItemNotFoundException. To avoid or workaround the exception, you could wrap it in a try/catch…

var GenericItem sceneGroup
try {
    sceneGroup = ScriptServiceUtil.getItemRegistry.getItem("bad_item_name")
} catch (ItemNotFoundException infe) {
    logInfo("Rules", "bad Item")
if (sceneGroup !== null) {
    logInfo("Rules", "sceneGroup=[{}]", sceneGroup.name)

However, I do not see why this would even be needed for use in a rule, since this exception would only occur due to a rule configuration error. Fix the rule and you won’t get the error!

To be fair, there are uses for running a search that may “fail” and dealing with it tidily.
You may have a large set of Items to handle, only some of which have some associated Item - a related device say - so seeking the associated Item will sometimes fail.

I’m curious to see an example where other means could not be used to ensure that the Item exists. Using the ItemRegistry may be the easiest, but it comes with a performance hit, so it would be best to find another way. That said, there are other useful ItemRegistry methods. In Jython, I use this to check for the existence of an Item…

if ir.getItems("Current_Timestamp") == []:

This is not used in a rule, but in a script that is creating Items if they do not already exist. This uses ItemRegistry.getItems() (note the ‘s’), which returns a collection of Items matching a regex. The regex being a literal string. The same could be done in a DSL rule using…

if (ScriptServiceUtil.getItemRegistry.getItems("item_name_to_check_for_existence") == newArrayList) {

This could potentially be used as another workaround for checking existence of an Item given an Item name as a string. For example…

val test = ScriptServiceUtil.getItemRegistry.getItems("bad_item_name")
if (test == newArrayList) {
    logInfo("Rules", "Bad item")
} else {
    logInfo("Rules", "Test [{}]", test.get(0).name)

Oh, there’s always other means :smiley:

My point was just that “searching” for a non-existent Item name is not necessarily something terrible to be avoided, and that having methods to deal gracefully with the situation are useful.

You’ve provided just such a method already, so thankyou :heart:

The kind of task I was thinking about would be something like a bunch of lights, where only some have some extra “property”.


Curious about this, be interesting to compare with the “traditional” searching/filtering of a Group by name-strings. I imagined the underlying mechanism was much the same.
Group limits the scope of search, so maybe of more benefit in large OH system (many Items)

I agree. By performance hit, I mean unneeded processing. In your example where only some Items have associated Items, put them in a PreferredColor group and use that for when it’s time to change the color. I just do everything I can to make my rules run as fast and efficiently as they can. I had to point this out for others that are as obsessed as I am in the speed with which their lights turn on :wink:. We’re talking milliseconds!

You are (all) very welcome! Now go use JSR223 for scripting your rules and you won’t have to bother with ScriptServiceUtil any more! :stuck_out_tongue_winking_eye:

In Rules DSL I’m kind of with you. I’m all in favor of adding lots of error checking to Rules. But I’m not seeing the use case.

However, when you go to Rule Templates I can totally see where checking for the existence of an Item in the Rule would be more important. But I’ve no problem with using an exception in that case as appears to be the case now.

An alternative is

if (ScriptServiceUtil.getItemRegistry.getItems("item_name_to_check_for_existence").isEmpty) {

That way you don’t have to create a new empty array list to compare to. .size == 0 would also work.


How i solved it in the end can be found here, feel free to comment on it or even improove it

Did you get something on the hunt? I’m having trouble getting a State from a DateTimeItem coming from the ScriptServiceUtil.

In the rule I’ll loop through 6 different calendar entries and try to get their states (DateTimeItems and StringItems)

	var DateTime EmailTime = ScriptServiceUtil.getItemRegistry?.getItem("Calendar_GoogleFamily_Event"+i+"_EmailTime") as DateTimeItem
	var String Summary = ScriptServiceUtil.getItemRegistry?.getItem("Calendar_GoogleFamily_Event"+i+"_Summary") as StringItem
	logInfo("Familienkalender", "Item from DateItem-Definition: [{}]",Calendar_GoogleFamily_Event1_EmailTime)
	logInfo("Familienkalender", "State from Item-Definition [{}]",Calendar_GoogleFamily_Event1_EmailTime.state)
	logInfo("Familienkalender", "State from String-Definition [{}]",Calendar_GoogleFamily_Event1_Summary.state)
	logInfo("Familienkalender", "Item from DateScriptServiceUtil: [{}]",EmailTime)
	logInfo("Familienkalender", "State from DateScriptServiceUtil: [{}]",EmailTime.state)
	logInfo("Familienkalender", "State from StringScriptServiceUtil: [{}]",Summary.state)

I’ll then get in the logs:

2020-01-10 08:26:00.044 [INFO ] [rthome.model.script.Familienkalender] - Item from DateItem-Definition: [Calendar_GoogleFamily_Event1_EmailTime (Type=DateTimeItem, State=2020-01-10T07:46:00.000+0100, Label=FamKal Ev1 Email, Category=calendar, Groups=[gCalendar, gCalFamilyNotification])]
2020-01-10 08:26:00.050 [INFO ] [rthome.model.script.Familienkalender] - State from Item-Definition [2020-01-10T07:46:00.000+0100]
2020-01-10 08:26:00.055 [INFO ] [rthome.model.script.Familienkalender] - State from String-Definition [dingsbums anrufen]
2020-01-10 08:26:00.059 [INFO ] [rthome.model.script.Familienkalender] - Item from DateScriptServiceUtil: [Calendar_GoogleFamily_Event1_EmailTime (Type=DateTimeItem, State=2020-01-10T07:46:00.000+0100, Label=FamKal Ev1 Email, Category=calendar, Groups=[gCalendar, gCalFamilyNotification])]
2020-01-10 08:26:00.064 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Binder Familienkalender': 'state' is not a member of 'org.joda.time.DateTime'; line 33, column 72, length 15
2020-01-10 08:23:03.134 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Binder Familienkalender': 'state' is not a member of 'java.lang.String'; line 33, column 74, length 13

The items from the .items-file and the ones generated via ScriptServiceUtil seem to have the same attributes - but it seems I can’t access them…
I’d also like to make comparisons with the “EmailTime”-Date and stuff I can with the .items-generated items…

No. There is no way to access Item metadata from the rules DSL. The solution is to use scripted automation, which is the future of automation for OH and metadata can be easily accessed using the core helper libraries. My plan is to make this functionality available through a Scripting API, so that the core helper libraries are no longer needed. If you’re interested, it’s getting easier to get them setup…

There are some issues with your casting. In the DSL, it is best to be only as specific as you need to be. Try being less specific and let the DSL do the work for you…

var EmailTime = ScriptServiceUtil.getItemRegistry.getItem("Calendar_GoogleFamily_Event"+i+"_EmailTime")
var Summary = ScriptServiceUtil.getItemRegistry?.getItem("Calendar_GoogleFamily_Event"+i+"_Summary")
1 Like

That’s great! at least I now get:

2020-01-10 10:18:02.748 [INFO ] [rthome.model.script.Familienkalender] - Item from DateItem-Definition: [Calendar_GoogleFamily_Event1_EmailTime (Type=DateTimeItem, State=2020-01-10T07:46:00.000+0100, Label=FamKal Ev1 Email, Category=calendar, Groups=[gCalendar, gCalFamilyNotification])]
2020-01-10 10:18:02.750 [INFO ] [rthome.model.script.Familienkalender] - State from Item-Definition [2020-01-10T07:46:00.000+0100]
2020-01-10 10:18:02.752 [INFO ] [rthome.model.script.Familienkalender] - State from String-Definition [dingsbums anrufen]
2020-01-10 10:18:02.754 [INFO ] [rthome.model.script.Familienkalender] - Item from DateScriptServiceUtil: [Calendar_GoogleFamily_Event1_EmailTime (Type=DateTimeItem, State=2020-01-10T07:46:00.000+0100, Label=FamKal Ev1 Email, Category=calendar, Groups=[gCalendar, gCalFamilyNotification])]
2020-01-10 10:18:02.755 [INFO ] [rthome.model.script.Familienkalender] - State from DateScriptServiceUtil: [2020-01-10T07:46:00.000+0100]
2020-01-10 10:18:02.757 [INFO ] [rthome.model.script.Familienkalender] - State from StringScriptServiceUtil: [dingsbums anrufen]

Do you have an idea, how I can compare the corresponding DateTime?

	val jetzt = now.minusSeconds(20)
(line 37:)
	if (jetzt.isBefore(new DateTime((EmailTime as DateTimeType).getZonedDateTime.toInstant.toEpochMilli))) {

leads to:

2020-01-10 10:21:02.852 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Binder Familienkalender': Could not cast Calendar_GoogleFamily_Event1_EmailTime (Type=DateTimeItem, State=2020-01-10T07:46:00.000+0100, Label=FamKal Ev1 Email, Category=calendar, Groups=[gCalendar, gCalFamilyNotification]) to org.eclipse.smarthome.core.library.types.DateTimeType; line 37, column 36, length 25

it seems, the “EmailTime”-defintion (without all those DateTime-references) gets the right values, but I’m still lacking understanding on how to cast accordingly… (I’m no devloper, casting and stuff is not in my blood :wink: ). The if-condition works with “real” items, as I use it elsewhere (also partly copied from the forum)

EmailTime is an Item. EmailTime.state is a DateTimeType. Your issue is that you are using EmailTime instead of EmailTime.state.

if (jetzt.isBefore(new DateTime((EmailTime as DateTimeType).getZonedDateTime.toInstant.toEpochMilli))) {

This should be…

if (jetzt.isBefore(new DateTime((EmailTime.state as DateTimeType).getZonedDateTime.toInstant.toEpochMilli))) {

This is much simpler as…

if (jetzt.isBefore(new DateTime(EmailTime.state.toString))) {

Personally, I’d stop using Joda (removed in OH 3.0) and use ZoneDateTime

val jetzt = new DateTimeType().zonedDateTime.minusSeconds(20)

if (jetzt.isBefore((EmailTime.state as DateTimeType).zonedDateTime)) {
1 Like

Thank you very much. Now it’s working as intended!
I’ll have to get my head around all that time-stuff and casting and whatnot… :wink:

I’d like to beta-test the Jython-thingy also, but first must move my OH2.5 to a new raspberryPi4…

1 Like

Can you use a ZoneDateTime in the call to createTimer?

In OH 2.5, createTimer uses org.joda.time.AbstractInstant, so to use a ZonedDateTime…

test_timer = createTimer(new DateTime(new DateTimeType().zonedDateTime.plusSeconds(5).toString()))[|

Although, I bet you were asking if a ZDT could be fed to createTimer without using Joda, and the answer to that is no.

The createTimer Action is part of the old rule engine, which will be removed in OH 3.0. Something similar will need to be created for the new rule engine, along with the other Core Actions. These will be made accessible for use within scripted automation through the scripting API. The mechanism will likely be a ScriptExtension, possibly through a default preset.

1 Like

My question was kind of self serving.

Does it make sense to push people to move to ZonedDateTime before exceptionally commonly used Actions like createTimer can accept it? When I look at my use of Joda DateTime in all of my rules, about 80% of the uses are related to calls to createTimer. Thus, it doesn’t make sense for me to migrate until I can use a ZonedDateTime in createTimer. It will be more work for me to switch now and then again when the replacement for createTimer comes along. I imagine I’m not unique in that.