Note that for now at least, this will cause problems in the UI.
const cannot be used at the global level of a UI Script because the script gets reused on every run. The script will run fine the first time and then fail saying that
item already exists or you cannot assign to a const or something like that.
It’s a known problem but the solution is not straight forward and will require changes in core. So for now you’ll have to use
var or, as you did below, wrap your whole script in an immediately called anonymous function.
There is some weirdness about
event right now with some differences between file based rules and UI based rules that I don’t fully understand yet. The file based rules event seems to be different from JSR223.
The most comprehensive docs I’ve seen for what event might contain (it depends on how the rule was triggered, and for manually, system, and cron triggered rules there isn’t even an event Object at all) is located in the old Helper Libraries docs which you already found.
But you can also experiment and see for yourself what’s there. Add
console.log(event); to your rule and it will log out all the properties of the Object.
event.itemState, at least in UI rules. In file based rules I think the names match the Rules DSL implicit variable names.
Here is a place where differences between UI rules and file based rules have a gap. One of the biggest problems users have in OH is dealing with type, and in particular dealing with the fact that some types will be Java and other types will be native to the language and sometimes those types are compatible and other times they are not.
In an attempt to solve this openhab-js does what it can to abstract and hide all the Java stuff so that you only have to worry about pure JS types in your scripts. So
However there are a few places where there are gaps. The
event.itemState is going to be the Java State Object.
Note that you can get at the Java state Object using
items.getItem('MyItem').rawState which is particularly useful when dealing with QuantityTypes and stuff like that. The original developer of openhab-js decided that it was easier to just deal with strings all the time than mess with all these Java Classes so
.state returns the
toString() of the Item’s state (except for QuantityTypes where it strips off the units before returning the string ).
If you change the rule to trigger on updates I think you can skip this which will prevent the rule from triggering again on this reset. This is an unbound Item so it’s not going to be updated periodically on a polling period or something like that.
Alternatively you can add a Condition to the rule to prevent it from running when the message is blank. The rule would still trigger but the script action wouldn’t be run if the condition is false.