Im pretty sure this line of code is not working correctly, but I have been wrong before.
Set Allow to (AutoLR XOR LOCAL)
Allow is a boolean local variable
AutoLR is a boolean global variable
LOCAL is a boolean local variable
When AutoLR = F and LOCAL = T
Allow is set to F by the statement Set Allow to (AutoLR XOR LOCAL)
I don't know about RM, but "false" and "true" are both valid values for Boolean variables. So it seems reasonable that AutoLR would take the first valid value received (which in this case is "false").
I agree that (0^1) = 1 in general... Maybe a bug...
I can reproduce this behavior. My simple test case was this:
This produces the unexpected result:
Where myTestVariable gets set to false in both cases (I tried two in case operand affected the results) where as it should get set to true under the conventional interpretation of XOR, which it looks like @JasonJoel also thinks.
But then I dug deeper.
I tried a plain OR, which under any reasonable interpretation should set myTestVariable to true in the above. But instead:
Identical results as with XOR: false in both cases.
For fun, I tried NAND just in case this was a general problem with the type of action I was using:
This produced the expected result. Then I tried something that I knew should give a false result, like AND. That worked as expected, so then I tried a "weird" operator again, XNOR, that should have also resulted in false. Nope:
@bravenel, I think there might be problems with at least a few of the logical operators in the "Set Variable" feature of RM when used like this (or with at least a few other operators besides XOR):
FWIW, XOR (the most unusual operator I have the option of choosing there 
) appears to be fine when used in conditionals:
Download the Hubitat app
