The documentation on rules does not say anything about whether we can have conjunction of trigger conditions in a rule. It says that we can have disjunctions. So can we have something like:
when
<TRIGGER CONDITION1> AND
<TRIGGER_CONDITION2>
then
<EXECUTION_BLOCK>
end```
?Not as such, but you can achieve it via the rule itself:
rule "blah blah"
when
Item ITEM1 changed to ON or
Item ITEM2 changed to ON or
Item ITEM3 changed to ON
then
{
if (ITEM1.state != ON || ITEM2.state != ON || ITEM3.state != ON)
{
logInfo("openhab", "not everything is on, quitting.")
return -1
}
logInfo("openhab","everything is on!")
sendCommand(TheRapture,ON)
}
end
No, rules are triggered by events so it makes no sense to have AND triggers - since events are triggered asynchronously. As TheKorn has shown, you have to setup your rules to trigger on each of your conditions (using OR) and then check each trigger state inside the rule.
On a sidenote, does anyone know if triggers can be built to be used like this
when
Item1 changed from NOT Uninitialized to ON
and/or - for numeric variables -
when
Item2 changed to GREATER 42
?
For now, I have been putting if-then-return at the beginning of each rule just as @TheKorn suggests, too, but that’s a hassle, eats performance, and often enough, you forget about it.
Usually, you keep believing that a rule works fine, except sometimes, and after more or less lots of fruitless trys and digging, it turns out that ‘sometimes’ is after a OH restart or rules file change (causing variables to be reset to Uninitialized state).
How does an if-return at the top of a rule eat performance? Yeah it’ll get executed a few extra times, but shouldn’t (in my mind) cause a performance drop that’s even remotely measurable. (Unless you’re running a processor with a KHz clock! 
) If it was 50 objects ANDed together then maybe… But even if it was (somehow) in the selection criteria, you’d still have to execute the comparison so would just be pushing the problem elsewhere, no?
Well, it’s not a real problem in terms of performance. It’s more about a programmer’s (me) discomfort of having to do things like that. It’s not elegant at all. And - more serious- it’s that you keep forgetting about it because intuitively, you are led to believe it’s handled in the trigger section even when it is not (simply because the trigger section IS there).
On the other hand, it encourages us to think about events as singular moments in time, rather than states. Triggers, not conditions.