Disadvantages with using group item summary functions?


I really like the group summary function functionality of OH, so I have been using it a lot, everywhere almost :-), in my item configuration files.

Now, I have not gone into rules very much yet, but I ask myself now what the downsides of my approach would be.

For instance, I have a group like this

Group:Number:SUM gLights "The number of lights that are on right now [%d]" <light>

which I understand will work well with Switch items to get me a nice count. The type of the group makes me wonder though, whether this group will allow me to do the things I want.

Will I for instance still be able to do a

gLights.allMembers.forEach [ item | 
	sendCommand(item, OFF)

when the Group item is defined as a number?

Or, do I have to have Group item pairs like these:

Group gLighting "Lights" <light>
Group:Number:SUM gLightsON "The number of lights that are on right now [%d]" <light>


Please tell me how this works.

First of all: it is recommended to use the same item type for the Group as its members.
Most likely, you have Switch type of items as members, so you should define your Group to use the same type:

Group						gAll
Group:Switch:OR(ON, OFF)	gLights	"All Lights [(%d)]"	<light>	(gAll)

This will give you in the label, the number of lights that are on. No need to use the Number:SUM type and function.

Then, in your sitemap you can have: Switch item=gLights and this will switch on/off all group members (and show you how many are on).

Using this config (Switch:OR(ON, OFF)), if any member of the Group changes to ON, the Group state will change to ON also.

For your rules, the forEach loop will work fine either way (I think).


Ps: By the way, instead of sendCommand(item, OFF) use: item.sendCommand(OFF). It’s the same thing in essence.

1 Like

Yes, this will work no problem. .members returns a List<Item> no matter what type the Group is.

+1 to everything @dim said.

1 Like