The property names are different with jsscripting. Try these
event.itemName,
event.itemState,
event.oldItemState,
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.
utils.dumpObject(event)
console.log(event.itemState)
console.log(event.oldItemState)
console.log(event.itemCommand)
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) = org.openhab.core.items.events.ItemStateChangedEvent
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) = org.openhab.core.items.events.ItemCommandEvent
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/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__
@florian-h05
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
2 Likes
oh, i see. You even described the conversion I was having problems with. 
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
Cheers,
Sascha
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).
I have the same issue. Also reverted back to M3 and all is fine.
I was also not able to import the backup JSON file.
I’ve seen it in other context. When you use a registry infrastructure there is an implicit dependency on a “managed provider” which is capable of removing elements. In other words, if you see this error it means that you try to remove an element but there is no known managed provider which is capable of dropping a given element.
There is a logic in PR which does that:
If you see such error it means that condition was not satisfied and you ended up with miss-interpreted provider which is managed, but not detected as one.
Second look at openhab-webui/oh3storage.service.js at main · openhab/openhab-webui · GitHub discloses reason.
The HABpanel did assume that all ui related components are writable which was true until above commit/PR. Once this PR was introduced there is no default UI component provider for HABpanel which could manage its state.
All what is need is below. It is a basic component provider which will simply match HABpanel json file (uicomponents_habpanel_panelconfig.json):
@Component(service = {Provider.class, ManagedProvider.class, UIProvider.class})
public class ManagedHabpanelProvider extends UIComponentProvider {
@Activate
public ManagedHabpanelProvider(@Reference StorageService storageService) {
super("habpanel:panelconfig", storageService);
}
}