Raspberry Pi 3 with openhabian
openhab 4.0
openhab-js 4.2.1
ECMA-script 2021

I’m trying to use the simplified access to the ItemSemantics in openhab-js 4.2.1, trying to retrieve the location of a triggering Item;;
var it = items[event.itemName]

Unfortunately, this produces an error:

2023-04-24 12:35:06.281 [INFO ] [enhab.automation.script.ui.appliance] - 4.2.1
2023-04-24 12:35:06.306 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: TypeError: items.getItem is not a function
	at <js>.get location(/etc/openhab/automation/js/node_modules/openhab/items/item-semantics.js:109) ~[?:?]
	at <js>.:program(<eval>:3) ~[?:?]

It’s probably a stupid mistake on my side, but I somehow thought, that openhab-js has taken away the need to access the rawItem in order to collect the semantic information.

Any help much appreciated.

I’m not sure what to make of this error.

I tried it myself and got the same error (I’ve not yet tried to use these new methods.

I think this is a bug so my best advice is to file an issue.

In the mean time you can use the following work around.

var location = items[actions.Semantics.getLocation(items[alertItem]).name];

I will have a look at this, I think it is just some type of wrong import.

1 Like

Unfortunately, this is a hard issue:

  1. You call items.getItem(itemname).semantics.location
  2. location calls items.getItem() to get the location Item, however to construct a new Item, semantics have to be imported.
  3. Trying to import semantics, getItem has to be imported.
  4. Congratulations, you have a circular dependency which leads to items being undefined inside item-semantics and therefore having the getter fail.

Possible solutions: either don’t report an Item (not nice) or move the ItemSemantics class to the same file to avoid having to import that whole stuff.

It’s not quite so bad to return the name instead of the Item. Once the user has the name they can use items to get access to the Item if they need it. It’s an extra step but at least we don’t need to mess with the raw Java Item.

I’m not sure the impact of moving the semantics stuff to the items.js file. That file is already over 600 lines long, what another 122?

Instead of importing items, could we pass it in the constructor to ItemSemantics?

Good idea, it works :+1:
Let’s do it that hacky way!

1 Like

Great that you are quick to look for pragmatic solutions. I’m really keen to clean up my mixed language rules jungle and move to a clean javascript based rule skeleton, only, without too much mingling with the underlying Java and fully exploiting the semantic model (instead of trying to code the semantics into the item names). Happy to participate in some new feature testing!

I haven’t checked this one, but I suppose the same issue exists for items[event.itemName]

When do you think, this feature will be included in the next openhab-js version?

Many thanks, once again!


It’s already coded and merged into main. A new version of the library hasn’t been released so you can either wait for the next point release or clone the main branch of the openhab-js repo and put that in the $OH_CONF/automation/js/node-modules folder (you’ll need to remember to remove it once the release does occur, it’s better to use the built in library most of the time).

It will definitely be a part of OH 4.0 release.

Yes, this is fixed as well.

You don‘t even have to to a git clone (which would be missing the dependency installation), npm install git+ does the npm install right from the main branch.

I am planning to release a new version in about one or two weeks.

1 Like

@Dirk_Albrecht I’ve released a new version that included that fix yesterday!

It will be included in the next SNAPSHOT build of the addon, or you can manually install it with npm. Just remember to configure JS Scripting to not use the internal library then.