First thing to do is check whether the Rule is actually firing. So look at events.log to make sure the events are occurring that trigger the Rule. Then add as the first line of the Rule a log statement to confirm that the Rule is firing.
Once you’ve proven that the events are occurring and Rule is triggering then you know that the problem is with the if/else statements. So log out the relevant values you are comparing against and work through the code line by line and figure out what the code it doing by “executing” the code on paper or in your mind.
That is one approach to diagnose this sort of problem. But often, especially for programmers with a little more experience, it is faster to restructure the Rule in a way that makes it simpler/easier to understand like Udo did.
As a case in point, I’d further refine Udo’s Rule as follows:
rule "Automatic control of all skylight windows"
when
Item NetamoUdendoersTemperature changed
then
// Exit the rule when there is nothing to do
if(alarm_totalalarm.state != OFF ) return;
if(!(Node13_SensorLuminance.state instanceof Number)) return;
if((Node13_SensorLuminance.state as Number) < 100 ) return;
if(!(NetamoUdendoersTemperature.state instanceof Number)) return;
// Calculate which velux to send the ON command to
val Number fTemp = NetamoUdendoersTemperature.state as Number
var velux = VeluxAlleLuk
switch fTemp {
case fTemp >= 25 : velux = VeluxAlleAaben100
case fTemp >= 23 : velux = VeluxAlleAaben75
case fTemp >= 20 : velux = VeluxAlleAaben50
case fTemp > 18 : velux = VeluxAlleVent
}
// Send the command
velux.sendCommand(ON)
end
I call this the 1-2-3 Rule structure and I wrote it up here.
The advantages are admittedly minor. The switch statement looks a little less complex. All of the side effects are centralized at the bottom of the Rule so if at a later date you want to do some additional checks (e.g. is it the right time of day?) before sending the Item the ON command.