This might denote a misunderstanding of how the PaperUI created Rules are supposed to work. First of all, everything rossko57 said is correct. PaperUI was never finished and has some significant bugs making it particularly unuseful.
But let’s assume that everything were finished and bug free.
First, let’s look at the parts of a plain old Rules DSL Rule:
rule "My rule's name"
when
some rule trigger or
some other rule trigger
then
if(some condition) {
block of code that does stuff
}
end
All of those things exist for PaperUI Rules too:
rule "My rule's name" // creating of the Rule itself, PaperUI also supports a description and tags
// the When... section of a PaperUI rule
when
some rule trigger or // Press the + icon to add triggers
some other rule trigger // Press the + icon to add triggers
then
// the but only if... section of a PaperUI rule, defines the conditions that must be true for the Rule to run
if(some condition) {
// the then... section of a PaperUI rule, what happens when the Rule triggers and conditions are met
block of code that does stuff
}
end // creation of the Rule itself
So, as you can see, except for the addition of the “but only if…” clause, the over all structure is exactly the same as the old Rules DSL Rules you are used to.
So you wouldn’t see something like a “Switch” command at the top level. That is something that would occur in the “then…” clause, also called the Action. You have a bunch of options there:
So, if you want to send a command to an Item, choose “send a command”. But almost all of the time you want to do something more involved and interesting. In that case you would chose “executes a given script” at which point you will be able to select from available languages. By default you will have JavaScript (ECMA) but can install Jython or Groovy. In OH 3 Rules DSL will be an option as well. That is where you would write the block of code that does stuff goes here
. For example:
Here’s a complete example from my thermostat:
Top level of the Rule:
I have one Rule trigger, two conditions and one action for this Rule.
The trigger is:
With would be equivalent to:
when
Item HeatingCtrl receive command
The conditions are:
Notice in both cases I have actual code that checks the states of various other Items to make sure that we can run the Rule. In the second conditional, I actually take corrective action before the Rule runs
If you just need to test for the states of Items or Things status or the like there are options for that that do not include writing code, similar to the triggers above.
Finally, the action:
This is the code that actually does the work.
This Rule in Rules DSL would look like:
rule "Heating Control"
when
Item HeatingCtrl receive command
then
// heating isn't in the right state already
val ok = true
if(HeatingPin.state == receivedCommand) ok = false
if(FanPin.state == ON &&
FanMode.state == "AUTO" &&
MainSwitch.state == ON &&
FanCtrl.state == ON) ok = false
if(!ok) return;
// Prevent Heating and Cooling to be ON at the same time
if(SystemType.state == 'US' &&
CoolingPin.state == ON &&
receivedCommand == ON) {
logWarn("heating", "Heating has been commanded ON but the Cooling is already ON")
CoolingCtrl.sendCommand(OFF)
Thread::sleep(1000) // this isn't a good idea in Rules DSL but OK in Scripted Automation and I want the code to be roughly equivalent
}
// Controls the HeatingPin and Heating2Pin
logInfo(heating, "Turning " + receivedCommand + " the heater: curr temp = " + MyTemp.state +
" setpoint = " + MinTempSetpoint.state +
" mode = " + HeatingMode.state)
var turnedOn = false
// turns ON/OFF heating and the Fan (if US type) if it isn't already
if(receivedCommand == ON){
if(MainSwitch.state != ON) MainSwitch.sendCommand(ON)
// Also turn on the Fan if US mode
if(SystemType.state != "US") {
if(FanMode.state != "AUTO") FanMode.sendCommand("AUTO")
if(FanCtrl.state != OFF) FanCtrl.sendCommand(OFF)
createTimer(now.plusSeconds(10), [ | if(HeatingPin.state != ON) HeatingPin.sendCommand(ON) ])
}
else if(HeatingPin.state == ON) HeatingPin.sendCommand(ON)
if(HeatingPin.state != ON) turnedOn = true
HeatingMode.sendCommand(HeatingMode.state)
}
else {
if(HeatingPin.state != OFF) HeatingPin.sendCommand(OFF)
if(SystemType.state == "US") {
createTimer(now.plusSeconds(10), [ |
if(FanCtrl.state != ON) FanCtrl.sendCommand(ON)
val mode = if(FanPrevMode.state != "ON") "OFF" else "ON"
FanMode.sendCommand(mode)
])
}
}
// yadda yadda yadda second stage heating code goes here
end
To cut a long story short, PaperUI generated Rules are structured very much like and can do pretty much anything that a Rules DSL rule can do. And they do so in pretty much the same way. That’s the main reason I went to the trouble to post the above.
In OH 3 there is a whole new UI with a whole new rules editor which will make creating rules like this a first class citizen. I even saw a screen shot showing a YAML version of the Rule which will be a lot easier to share and ask for help with on this forum than screen shots and the like.