Is there any way to use newState in the UI rules?
I love the UI rules in OH3 - these are so easy to read, write and manage. I was looking to write a rule to sync my wifi plugs to my hue lights - I know this can be few lines of codes in rule DSL with newState, etc. but in the UI rules, newState doesn’t seem to be there. Would there be another easy way to copy state changes of one switch with another one?
Thanks
Within MainUI you have to choose „run script“ instead of item action.
there you can use newState
Do you refer to the blocklies and event.newState? Then the answer is “soon”. I have just implemented it and it is waiting to be reviewed and therefore released soon.
See here Extending Blockly with new openhab commands - #214 by rlkoshak
hmmm not the scripts I’m thinking of the “Rules” section in the UI - and have the ability to do “Add Action” and use in this screen the “newState”
In that case no, that’s not supported and I know of no one who is working on support for that. code less rules are intended to be for only the most very basic of rules. If we add all the little “but can we do this, and what about adding that” type stuff to it it doesn’t take too long before we end up with Blockly anyway.
Totally makes sense - the blockly stuff is really cool but if I understand correctly today to make a rule with it you need to follow these steps:
Is that the way it works? I haven’t figured out how to make a good use of the script section yet from OH3.
Not correct. Make a rule. Under “Then” choose “Run Script” and from there choose “Design with Blockly”. It’s rare that one would write a rule that calls other rules. That’s creating a Script Action. Calling another rule (e.g. something listed under Settings → Scripts) is done by choosing “Other rules” as the action.
Unfortunately the word “Script” has two meanings here which causes confusion.
The Settings → Script section is just a place to put a special class of rules that consist of only a single Script Action with no triggers or conditions.
They can be useful to experiment with. They can be useful to be called from other rules. And they definitely are a good place to keep a library of examples that you build up over time.
To underline what Rich has said, calling a UI script from Blockly has become very easy:
create a rule with blockly that can be triggered by anything and add this one block
and then create a script named “helloWorld” and add the following code
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
logger.info('helloWorld was called')
logger.info('Params are='+context.getAttribute('myKey1'))
logger.info('Params are='+context.getAttribute('myKey2'))
When triggering the blockly rule you will see the following in the log
[org.openhab.rule.helloWorld ] - helloWorld was called
[org.openhab.rule.helloWorld ] - Params are=10
[org.openhab.rule.helloWorld ] - Params are=45
Btw, I am also a pretty experienced Java Developer and used DSL rules for quite a number of rules but I moved to the blocklies for many of my rules (not saying all) because most of the rules are rather simple and in these case the blocklies have the big advantage that you can build them very quickly whereas with DSLs can you can easily end up having syntax errors or typos. So for “simple” stuff (even though complex things are doable) I used the blocklies, for complex things I keep my DSLs.
PS: @rlkoshak Maybe we should add a Block that allows to get context-values (context getAttribute) because then we could have even written the script with blocklies. What do you think?
Absolutely, though that’s a pretty advanced capability to I wasn’t going to push for it until later. It is also one of the things that changes between Nashorn and JScripting and may further change in JSScripting and figured we should wait for that to settle down so there is less rework in Blockly later.
But it’s a super easy add I think so it’s up to you if you want to add it now.