Retrieving items in rules: itemRegistry vs. Items?

[jstro (John Strong)]

Hi folks,

This may be a question about personal preference but I have a hunch it goes deeper than that in ways I don’t fully comprehend. The question is this: what method should I be using in my rules (I’m using JS Scripting 2021) to retrieve an item state, or other item property? Is the answer simply, “whatever works”?

Here is the background to my question. It looks like there is at least three ways. One way is to use itemRegistry, as mentioned in the “But How Do I…?” section of https://openhab-scripters.github.io/openhab-helper-libraries/Guides

var item = itemRegistry.getItem("KitchenLight");

However, my understanding is that this retrieves a Java object so you need to evaluate it using Java types, e.g.,

if (item.state == runtime.ON) ...

Another method is to use the Javascript Standard Library, which is recommended in Home - Documentation

var item = items.getItem(“KitchenLight”);

This lets me retrieve item.state which is a string

if (item.state == "ON") ...

There’s a third way that I’ve seen used but haven’t spotted in the documentation yet. It seems like a shortcut way to get straight to the item state string variable.

if (items["KitchenLight"] == "ON") ...

Okay, given all that, are these all equally preferable for retrieving an item state, or are there advances/disadvantages, and is there possibility of complications if I use one way over another, especially concerning Java vs Javascript?

[rlkoshak (Rich Koshak)]

@jstro

The question is this: what method should I be using in my rules (I’m using JS Scripting 2021) to retrieve an item state, or other item property?

Are you sure? The itemRegistry isn’t there by default in ECMAScript 2021. You have to go out of your way to import it, and there is no reason to.

@jstro

Here is the background to my question. It looks like there is at least three ways. One way is to use itemRegistry, as mentioned in the “But How Do I…?” section of https://openhab-scripters.github.io/openhab-helper-libraries/Guides

Don’t use that as a reference for ECMAScript 2021. That’s for ECMAScript 5.1. JS Scripting has a wholly separate helper library.

@jstro

However, my understanding is that this retrieves a Java object so you need to evaluate it using Java types, e.g.,

correct

@jstro

Another method is to use the Javascript Standard Library, which is recommended in Home - Documentation

This is the method for JS Scripting. Do not mix and match between the two. When in doubt, do what the docs for JS Scripting says to do.

@jstro

There’s a third way that I’ve seen used but haven’t spotted in the documentation yet. It seems like a shortcut way to get straight to the item state string variable.

This is also not available by default in JS Scripting. This is a dict of name value pairs where the name is the Item’s name and the state is the Item’s current state.

@jstro

Okay, given all that, are these all equally preferable for retrieving an item state, or are there advances/disadvantages, and is there possibility of complications if I use one way over another, especially concerning Java vs Javascript?

The main takeaway is don’t try to apply examples and information from the ECMAScript 5.1 helper library to JS Scripting. They are wholly separate environments and the helper libraries have fundamentally different design and implementation philosophies.

JS Scripting goes to great lengths to free you from needing to deal with the “is this Object Java or is it JavaScript?” question. Except in certain very specific circumstances, you should only be working with JavaScript stuff in JS Scripting rules. That means only using what’s documented in the JS Scripting add-on docs, not what’s in the JSR223 page or the old ECMAScript 5.1 helper library.

Obviously there may be gaps in the JS Scripting library so you can get to the raw Java Objects when necessary. But this should be the exception rather than the rule.

In short, you should not import @runtime nor use anything from it except in situations where the JS Scripting helper library simply cannot support what you want to do. And in that case, please file an issue on the openhab-js library so it can be enhanced to support your use case.

[jstro (John Strong)]

@rlkoshak

The main takeaway is don’t try to apply examples and information from the ECMAScript 5.1 helper library to JS Scripting. They are wholly separate environments and the helper libraries have fundamentally different design and implementation philosophies.

JS Scripting goes to great lengths to free you from needing to deal with the “is this Object Java or is it JavaScript?” question. Except in certain very specific circumstances, you should only be working with JavaScript stuff in JS Scripting rules. That means only using what’s documented in the JS Scripting add-on docs, not what’s in the JSR223 page or the old ECMAScript 5.1 helper library.

Obviously there may be gaps in the JS Scripting library so you can get to the raw Java Objects when necessary. But this should be the exception rather than the rule.

In short, you should not import @runtime nor use anything from it except in situations where the JS Scripting helper library simply cannot support what you want to do. And in that case, please file an issue on the openhab-js library so it can be enhanced to support your use case.

Hi Rick,

Much appreciated! I was hoping you’d see my question. I should have been able to piece this together from all the helpful information you’ve already posted but somehow my brain didn’t make all the connections. This is quite clear to me now.