Aggregation functions for nested groups changed recently?

Setup, Configuration and Use Items & Sitemaps
1

I just upgraded 2 days ago from 2.2. release version to 2.3.0 Snapshot 1219.
I notice that the system behaves different for the handling of nested groups and I wonder if this is (new) expected behaviour or just a bug. I have grouped my lights in 3 groups (for each area/floor) and then grouped these 3 groups in one “main” group for all lights.
Here my item definition for the groups:

|Group:Switch:OR(ON, OFF) ||lights ||"All Lights [(%d)]" |
|---|---|---|---|---|
|Group:Switch:OR(ON, OFF) ||lights_eg ||"All Lights EG[(%d)]"  (lights)|
|Group:Switch:OR(ON, OFF) ||lights_og ||"All Lights OG[(%d)]"  (lights)|
|Group:Switch:OR(ON, OFF) ||lights_au ||"All Lights AU[(%d)]"  (lights)|

In my sitemap the group is displayed and until 2.2.0 release version the total number of all active lights was shown (e.g. 8 if there were 3 active lights in lights_eg and 5 active lights in lights_og). Now it seems that only the number of active subgroups is displayed at top-level (0,1,2 or 3) and the real number of lights is only shown within the subgroups where the lights are direct members:

grafik

grafik
grafik.png1395×174 6.29 KB

In the above example I would have expected to see 7 active lights on top-level and not 2.

Any ideas? How can I get back the total number on top-level?

2

There was a recent change to how the state of a group item is calculated.

You can get the top level group to display the total by changing the function it is using.

Group:Number:SUM lights "All Lights [(%d)]"
3

Thank you for clarification.
However the old solution was somewhat nicer as you could use the same group for switching all lights OFF und displaying the total number of active lights in just one line of sitemap. Now the ‘All Off’-Group will only show a non interesting number of nested groups below it while the additional “SUM”-Group will display the total number of real active items in an additonal line…

4

There is actually a way to achieve the same result as before:
Instead of adding the floor-groups to the top level group you should add all items individually to the top level group, too.
Your setup will the look like this:

Group:Switch:OR(ON, OFF) lights "All Lights [(%d)]"

Group:Switch:OR(ON, OFF) lights_eg "All Lights EG[(%d)]"
Group:Switch:OR(ON, OFF) lights_og "All Lights OG[(%d)]"
Group:Switch:OR(ON, OFF) lights_au "All Lights AU[(%d)]"

Switch sw1 (lights, light_eg)
Switch sw2 (lights, light_eg)
Switch sw3 (lights, light_og)
Switch sw4 (lights, light_og)
Switch sw5 (lights, light_au)
Switch sw6 (lights, light_au)

edit: fix switch item ids

5

this one is more logic than nesting Groups as you define at item-Level which Group it belongs to.
What would be the benefit of nesting Groups? I don’t know the exact changes in 2.3, but you couldn’t (and can’t ?) have the OR, AND, … stuff for nested Groups, can you?

6

The group behavior is all about item state now:

  • If you need a state for the group item itself, like in the examples above you can achieve this only by giving a group function. So a group will only have its own state when the state can be calculated by a group function via all group members.
  • If you simply want to aggregate items into a group e.g. to add navigation to the UI by displaying a single entry for the group you omit the group function. The group can then be seen as an alias for all its members.

When it now comes to calculating the state of a group by the defined group function there is difference on how the members of the group are treated by the group function:

  • Item members will treated by their respective states.
  • Sub-Groups without a group function (aka. alias groups) are transient to the parent group function and all the sub-members will be taken into account.
  • Sub-Groups with a group function and their own state will be treated like normal items as these group’s state will be taken into account.

This is now also reflected in the Eclipse SmartHome documentation.

2 Likes