openHAB 3.3 Milestone discussion

I upgraded from 3.3M2 to 3.3M3
Everything was just fine in M2… I just have a compulsion to live on the bleeding edge.
After the upgrade (using apt in ubuntu), 3 of the 13 zwave devices would not initialize.
They were 3 of 4 Leviton Fan controllers.
The errors all were


{config_7_1=The value -1 does not match allowed parameter options. Allowed options are
[ParameterOption [value=“0”, label=“LED Off”], ParameterOption [value=“254”, label=“Status Mode”],
ParameterOption [value=“255”, label=“Locator Mode”]]}

On one of the failing devices, in the UI, I updated parameter 7, and it came online.
The other 2, the updated value appeared to save but would not and the devices remained in the above error state

I uploaded a gist of my zwave.log file.

Any suggestions to avoid redoing my zwave things?

The Z-Wave databade probably needs an update/fix.
Did ypu open an issue?

There are already some similar problems reported but no solution so far.

Not sure if this is a M3 problem, but…
I cannot get the old or new state, nor the command of an event in JS 2021 scripting.

Neither with Command triggers nor item changed triggers. The only thing I can get is

All others are undefined, like

I trey to get the state myself with items.getitem().state, but at the command time the state is not always right yet.

Any suggestions? Is this a milestone problem?

Well, I finally just went in and edited org.openhab.core.thing.Thing.json file.

I found the 2 Things and changed the parameter 7 value for each.

I restarted OH and everything was hunky dory.

Would you guess this is a zwave binding issue or a OH core issue?

The property names are different with jsscripting. Try these


Source Some JS Scripting UI Rules Examples - #2 by rlkoshak

I also find it hard to find the canonical documentation on this…

1 Like

Hello @ssalonen @openhabber,

in file-based JS Scripting the event has these properties:

For UI-based however it is really different, I would recommend using utils.dumpObject(event) to analyse it.

This is due to JS Scripting is able to format the event data in file-based but not in UI-based.

I think it will probably take some time until this docs get merged into the JS Scripting docs.

@ssalonen thank you!
For commands, it is event.itemCommand, if anyone is wondering.

I really searched for that. Maybe the docs should at least mention them?
It’s not mentioned at
GitHub - openhab/openhab-js: openHAB Javascript Library (only file-based, as you said)
Home - Documentation
JavaScript Scripting - Automation | openHAB

In addition, the autocorrect on the UI editor predicts the wrong elements.

Also the dump does not seem that helpful.


For an item change:

2022-04-24 11:05:43.254 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 11:05:43.257 [INFO ] [org.openhab.automation.script.utils ] - typeof obj = object

2022-04-24 11:05:43.259 [INFO ] [org.openhab.automation.script.utils ] - Java.isJavaObject(obj) = true

2022-04-24 11:05:43.260 [INFO ] [org.openhab.automation.script.utils ] - Java.isType(obj) = false

2022-04-24 11:05:43.263 [INFO ] [org.openhab.automation.script.utils ] - Java.typeName(obj.class) =

2022-04-24 11:05:43.267 [INFO ] [org.openhab.automation.script.utils ] - getAllPropertyNames(obj) = [object Array]

2022-04-24 11:05:43.270 [INFO ] [nhab.automation.script.ui.b81e419f18] - Automatik

2022-04-24 11:05:43.271 [INFO ] [nhab.automation.script.ui.b81e419f18] - Aus

2022-04-24 11:05:43.273 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined

For an item command:

2022-04-24 11:07:27.843 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 11:07:27.846 [INFO ] [org.openhab.automation.script.utils ] - typeof obj = object

2022-04-24 11:07:27.852 [INFO ] [org.openhab.automation.script.utils ] - Java.isJavaObject(obj) = true

2022-04-24 11:07:27.853 [INFO ] [org.openhab.automation.script.utils ] - Java.isType(obj) = false

2022-04-24 11:07:27.863 [INFO ] [org.openhab.automation.script.utils ] - Java.typeName(obj.class) =

2022-04-24 11:07:27.874 [INFO ] [org.openhab.automation.script.utils ] - getAllPropertyNames(obj) = [object Array]

2022-04-24 11:07:27.878 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined

2022-04-24 11:07:27.879 [INFO ] [nhab.automation.script.ui.b81e419f18] - undefined

2022-04-24 11:07:27.887 [INFO ] [nhab.automation.script.ui.b81e419f18] - Automatik

Hello @openhabber,

For commands, it is event.itemCommand, if anyone is wondering.

You mean UI-based, right?

I really searched for that. Maybe the docs should at least mention them?

Maybe, but I think would be better if it event is the same in UI-based and file-based. In file-based, the event is formatted by this function: openhab-js/rules.js at 394fb9959ce92f57766d495fb98c298276d78615 · openhab/openhab-js · GitHub
If I am able to apply this in UI-based, it would be the same - I will take a look at it later.

In addition, the autocorrect on the UI editor predicts the wrong elements.

Yes, I have also noticed this, that’s one of the things that have to be changed in the codecompletion.

Also the dump does not seem that helpful.

Oh sorry, I forgot that dumpObject() had an issue that was recently solved but no new version was published yet.
On my system (with the fixed dumpObject()), it looks like the following for file-based ItemCommandTrigger:

2022-04-24 12:12:43.326 [INFO ] [org.openhab.automation.script.utils ] - Dumping object...

2022-04-24 12:12:43.329 [INFO ] [org.openhab.automation.script.utils ] -   typeof obj = object

2022-04-24 12:12:43.332 [INFO ] [org.openhab.automation.script.utils ] -   Java.isJavaObject(obj) = false

2022-04-24 12:12:43.335 [INFO ] [org.openhab.automation.script.utils ] -   Java.isType(obj) = false

2022-04-24 12:12:43.340 [INFO ] [org.openhab.automation.script.utils ] -   getOwnPropertyNames(obj) = eventType,triggerType,receivedCommand,oldState,newState,itemName,module

2022-04-24 12:12:43.353 [INFO ] [org.openhab.automation.script.utils ] -   getAllPropertyNames(obj) = eventType,triggerType,receivedCommand,oldState,newState,itemName,module,__proto__,constructor,hasOwnProperty,isPrototypeOf,propertyIsEnumerable,toLocaleString,toString,valueOf,__defineGetter__,__defineSetter__,__lookupGetter__,__lookupSetter__

Thanks for your fast reply.
Yes, indeed, in UI-Based rules.

I also noticed that event.itemCommand for example is of type “Object”, and a comparison to its value as a String fails.

This is false:
event.itemCommand === “Kino”
event.itemCommand == “Kino”

This is true:
String(event.itemCommand) === “Kino”
String(event.itemCommand) == “Kino”

If this is not okay to discuss here, please tell me, and we can move somewhere else.

1 Like

@openhabber @florian-h05 I introduced PR to improve the docs and explain the gotchas: Docs: document UI rules event and @runtime by ssalonen · Pull Request #110 · openhab/openhab-js · GitHub

EDIT: Good example that one with String items, it’s worse than I thought… I added that one to documentation.

EDIT2: I also found out that the autocomplete is incorrectly suggesting entries, causing further confusion. Ticket created: Autocomplete incorrect with ECMAScript 2021+ · Issue #1358 · openhab/openhab-webui · GitHub


oh, i see. You even described the conversion I was having problems with. :slight_smile:

One more problem:

event.itemState and so on seem to always be strings.
So I get something like “21.5 °C” or “220 kcal”.
When accessing items with items.getitem, I am using .rawState instead of state for that reason.

Do I overlook something, or what is the correct way to get a number out of an event?

In DSL you could just say event.newState as Number.

Not if you are dealing with units of measurement. Even in Rules DSL you have to deal with that differently, ultimately calling .floatValue() or converting the value you are doing math with to a QuantityType with proper units too.

And you can do the same in JS Scripting too.

If it’s just a plain old number, JS itself is smart enough to recognize when you have the String representation of a number and do the conversion to number for you.

The vast majority of the time, the string version of the state will work exactly as you need it to work. The only two exceptions are quantity types and datetime types.

Is it because I have state descriptions?
My temperatures should only have one decimal, so I have %.1f °C in place, allthough being tagged as number: temperature. I will try this out later. Thank you.

Just to not leave this hanging out, it’s because you have the Item defined as a Number:Temperature. If you need help beyond this, I recommend opening a new thread to keep this thread on topic.

I have a beginners Issue which I suppose is not related to 3.3, thus I posted a dedicated discussion thread here.
However I am using the latest image from docker hub (3.3.0-snapshot-alpine from Today (April 27th)) which for the sake of completeness I post this here as well, just in case it could be a version-related Issue after all.

As I couldn’t find anything regarding this:

Using the latest snapshot-alpine in docker works but for the go-e charger binding. The already created things work and all linked items also but I can’t create new things (“No thing types can be added with this binding.”):

I’ve already cleared the cache and reinstalled the binding resulting in exactly the same situation.

Anything I can do about it?

EDIT: Seems to be known already: Go-E Charger Wallbox Binding - #99 by kreutzer_peter


After migrating to 3.3.0M4, there was an error in the log that a rule failed and after a little investigation, it appears that the marketplace Blockly Date and Time extension that I had added was removed in the migration, and I can’t add it in the marketplace.

More details at Rule Using Blockly Date and Time from Marketplace Failed after migration to 3.3.0M4

After updating from M3 to 3.3.0M4, all my (different) HabPabel-configs seems not not be available anymore. Does somebody else facing issues with HabPanel Configs?

I ran three different configs for three different tablets - and the configs are not choosable anymore.

When importing a config into HabPanel and executing it I see in the log:

[ERROR] [internal.JSONResponseExceptionMapper] - Unexpected exception occurred while processing REST request.
java.lang.IllegalStateException: ManagedProvider is not available

Any ideas?
I went back to M3 - everything fine (again).