OpenHAB2 rules and Boolean operators

When switching to OpenHab2 one of the rules which had been working well for 1.x versions stopped working. The rule is very simple and looks like:

rule “FF_Corridor_Motion_ON”
when
Item Motion_FF_Corridor received update ON
then
if (isNight == true && sunDown == true) sendCommand (Light_FF_Corridor_Table, ON)
end

For troubleshooting I simplified the rule and found that it works with either of the boolean conditions but the problem comes when combining them with the && operator. Based on this I did rewrite the rule to:

rule “FF_Corridor_Motion_ON”
when
Item Motion_FF_Corridor received update ON
then
if (isNight == true) (
if (sunDown == true) sendCommand (Light_FF_Corridor_Table, ON)
)
end

This works so the problem is solved. At least to me the non-working syntax is correct (but I have been wrong before :-)) why there seems to be a change to how rules are parsed in OpenHab2. Also, as mentioned above, the rule worked for all 1.x versions I have had.

@mebj

for me this works as intended.
But you could save some code and time.

if (isNight && sunDown ){
    logInfo("Test", "both") 
 }

I see you use normal brackets, this should be curly bracket for the code block of the if-statement.

1 Like

Thank’s for the reply. Wonder why it is not working for me, especially since I had no problems on the 1.x versions. My guess was that it might be caused by how the priority of operators is handled between versions.

Just another one of the mysteries of programming. Anyhow, it works with the modified code.

The brackets should be curly but it seems to always work with the plain version also.

I seldom use the “short” version of various pieces of code. Over the years I have found that it may save me from making mistakes when coming back to work on “old and forgotten” code.

It would help if you showed where isNight and sunDown are declared.

Both are declared as boolean right after the includes and are available to all parts of the code. They do not have a role in this issue which also can be seen from the code working versus code not working examples.

I just created a new rule to test the && issue:

rule "mqtt"
when
    Item TestMQTT changed
then
    if (TestMQTT.state==ON && TestMQTT.state==ON){
        logInfo("MQTT", "1") 
    }
end

It works flawlessly using OH 2.2.

I would recommend using the correct syntax as suggested.

And another rule using booleans:

var Boolean Bool1=false
var Boolean Bool2=false
rule "mqtt"
when
    Item TestMQTT changed
then
    Bool1=TestMQTT.state==ON
    Bool2=TestMQTT.state==ON
    if (Bool1 && Bool2){
        logInfo("MQTT", "1") 
    }
end

Also working flawlessly.

Thank’s a lot for taking the time to test this.

I am on version 2.2 also and made a complete new installation from the stable packages because I noticed this issue earlier but I then used several generations of the snapshot versions.

Hope to find what is wrong some day, in the meantime I have a working solution as well as a knowledge that others can not duplicate the issue. Of course I use the { } but like with everything else - shit happens :slight_smile:

One thing I would say, whenever you save a rules file, all variables contained in that file are reset to an undefined state (ie. they are null), unless you declare them with a initial value (as in my example).

If such variables are accessed before they are initialised they will have a value of null and cannot be used for simple boolean comparison (unless you cheat and compare boolval!=true, which would default to false if the object is either undefined or actually false).

Since I see no initialisation of variables in your code snippet (which is why I asked to see where they were declared), I can only assume those boolean variables are set in another rule, in which case that rule would have to fire before your rule.

It also helps to restart the server if all else fails, sometimes that magically solves little glitches after modifying files.

Thats what comments are meant for :wink:

But in this case it also safes time as you reduce the the comparison, in worst case, from to 2 ( true && true) to 2 comparisons and two evaluations. And if this happens a lot this will add uneccessary workload. IMHO.

I found the error and will try to explain it in case it will aid others when troubleshooting.

During traceing of the boolean variables isNight and sunDown in the code of my initial post I found that those sometimes had the values I expected and sometimes not. This explained why one piece of could work and another piece not and was a new finding compared to the troubleshooting I earlier made for the Openhab 1.x version of the code.

These variables were set in pieces of code looking like:

rule “isNight reset”
when
Item isNight_start received command
then
if (isNight_start.state == ON) {
isNight = true
}
.
.
end

when changing the trigger from “Item isNight_start received command” to “Item isNight_start received update” everything started to work also in Openhab 2.

My conclusion is that in Openhab 2 the timing is so that when a command to change “Item isNight_start” ocurred and this triggered the rule above the “Item isNight_start.state” had not yet changed. In Openhab 1.x this worked differently.

It is obvious that sending a command to change a state does not necessarily mean that the change has taken place when testing on the change. This was the trap I fell into, my error.

I have not checked if disabling the “autoupdate” would have made any difference but most likely it is so.

Thank’s a lot to all having taken time to comment, the comments aided me in finding the error and I have learnt something once again :-). Hope the explanations make sense but if not please ask.

@mebj yes that’s how it is. It is not intuitiv but lies in the way of how it is implemented. Received command does not garanty that the state is updated. That’s why Implicit variables where introduced.