[SOLVED] Help with Rule generated error. Rule 'rulename': null

Setup, Configuration and Use Scripts & Rules
1

Platform information:
Hardware: Raspberry Pi 3 Model B Plus Rev 1.3
OS: Raspbian GNU/Linux 9 (stretch)
openHAB version: 2.5.0~S1496-1 (Build #1496)

Unknown reason for error message. I am periodically seeing the following error appear:

[ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'gPower Count': null

I believe that this is being generated from the following rule:

rule "gPower Count" 
when
    Item gPower received update 
then 
    val numberOfDetectors = gPower.allMembers.size
    var numberOfDetectorsON = gPower.allMembers.filter(s | s.state == ON).size
    if(numberOfDetectorsON==null) { numberOfDetectorsON = 0 }
    val outputString = numberOfDetectorsON.toString + " / " + numberOfDetectors.toString
    //logInfo("systemInfo.rules","gPower: " + outputString)
    postUpdate(PowerCount, outputString)
end

I have virtually identical rules for also counting (and displaying on HabPanel) the stats for the lights, motion sensors, etc and these do not produce the error (the only difference in the rules is the group that they reference so instead of gPower is would be gLights, gMotion, etc)

What I do not understand is what is causing this error, if I uncomment out my debug line to log the outputString variable to the log then the error message is never seen again??

Whilst this is more of an annoyance, as the rule is doing what I want, I would like to discover the underlying reason for the error and fix it - An error is only there is there is actually an error!!

Definition in items file is:

String   MotionCount                            "Motion Count"
String   LightCount                             "Light Count"
String   PowerCount                             "Power Count" 

Group:Switch:OR(ON, OFF)   gLight                    "Lights"                                  <light>                (Home)
Group:Switch:OR(ON, OFF)   gLightGF                  "Lights Ground Floor"                     <light>                (Home)
Group:Switch:OR(ON, OFF)   gLightFF                  "Lights First Floor"                      <light>                (Home)

Group:Switch:OR(ON, OFF)   gPower                    "Power Outlets"                           <poweroutlet>          (Home)
Group:Switch:OR(ON, OFF)   gPowerGF                  "Power Outlets Ground Floor"              <poweroutlet>          (Home)
Group:Switch:OR(ON, OFF)   gPowerFF                  "Power Outlets First Floor"               <poweroutlet>          (Home)

Group:Switch:OR(ON, OFF)   gMotion                   "Motion"                                  <motion>               (Home)
2

I think this is going to be a reeentrancy thing.
openHAB groups exhibit a quirk - when there is a change in member states, the system (not rule as I first said) must recalculate it’s state. It’ does this in an iterative manner, that’s to say OH loops around many times issuing state updates.
The effect we users see is that a single member Item change can result in many Group updates. As many as members, I think.

So most likely there are multiple copies of your rule running at the same time, triggered at different instants, and all trying to operate on the same Group, which is still changing while they work

Adding your logInfo line will change timing, and maybe impose some order by queuing log messages too.

Do you really need to trigger from update? I think I’d change to trigger from changed
In the worst case maybe add a tiny sleep at the head of the rule to allow the Group to stop thrashing before calculations.

There are ways to get counts of members from Groups directly, but I’m a bit vague on those.

3

Thanks for that; what you have explained makes perfect sense.

Also thanks for spotting that I was triggering on **received update **, you are correct in that there is absolutely no reason for doing this, have changed the rules to trigger on changed

Will monitor to see if the issue goes away, but certain that it will have been solved.

4

N-1 where N is the number of members. The first update is the result of the calculation from the first two members of the Group and then the second update is the result from the previous calculation and the third member and so on resulting in N-1 updates.