Group issues

In the documentation of groups there should maybe a line that all items needs to be initialized, so if a sensor looses connection and get the value UNITIALIZED the whole group will fail even if it compatible types…
rewrite this?
Note that aggregation functions can only be used on compatible Item types. Incompatible Item types within a Group may result in the invalid aggregation result UNDEF.

to:

Note that aggregation functions can only be used on compatible Item types. Incompatible Item types within a Group may result in the invalid aggregation result UNDEF. In addition all items needs to have a value, so considered using startup rules and persistence to avoid have items contain values like UNDEF or UNINITIALIZED

Also how can I add aggregation group to another group? I would like to add the group below to my chart group?

Group:Number:AVG Group_Temperature_LivingRoom(Group_Chart)	"Avg. Indoor Temperature [%.1f °C]" 	<temperature>	


// Moisture
Group:Number:MIN Group_Moisture_LivingRoom	"Minimum Moisture [%.1f °C]" 	<temperature>	

// CO2
Group:Number:Max Group_MaxCO2	"Maximum CO2 level [%.1f ppm]" 	<temperature>	

Group Group_MyOpenhab // for Items that are exposed to IFTTT
Group Group_Chart     // for Items to persist for charting
Group Group_History   // for Items to preserve their history

This made my whole persistence crash and all items below Group_Temperature_LivingRoom in the item file, without any errors in the logs!! Except saying that sitemap could not find Group_Moisture_LivingRoom How come no better error logs?..

This works as expected:
Group:Number:AVG Group_Temperature_LivingRoom "Avg. Indoor Temperature [%.1f °C]" <temperature>

It is good to discuss this here, but unless you file an issue here it is unlikely to be acted upon.

This change is simple enough that you could even make the change yourself by editing the file in the browser.

But first I’m curious to know what tests you ran and what results you got. For example, if you have a single Item that is NULL in an AVG Group, does the Group’s state end up NULL too? Do you see errors in the logs? Did you try it with all Item types or at least the most common Item types (Number, Switch, Contact)?

Before we make a blanket statement in the docs we need to know the full extent of the behavior.

You can’t add the Group’s state to persistence like that. You can only persist the value of the Group by listing it individually in your .persist file without the *.

Also

Group:Number:AVG Group_Temperature_LivingRoom(Group_Chart)	"Avg. Indoor Temperature [%.1f °C]" 	<temperature>

should be

Group:Number:AVG Group_Temperature_LivingRoom	"Avg. Indoor Temperature [%.1f °C]" 	<temperature> (Group_Chart)

The order matters when defining Items. The Group goes after the label and the icon.

You almost certainly had an error in the logs saying it couldn’t parse your .items file, unless you are on a version before 2.2 SNAPSHOT. By placing the (Group_Chart) in the wrong place you rendered the file unparsable to OH from that point onwards. Older OH versions would keep everything in the file up to that point. The newer version will reject the whole file.

I just tested with the number, can you use average on switch and contact?

Yes, I had a flower sensor who got out of battery and on a reboot the heating went down, due to not initialized item… I added the sensor to my startup rule, and all is good now. But if you can verify the same on OH2.2 it would be great. I am running a very old version of openhabian(the one you cant update…) so unfortunately I can not verify this has been dealt with…

Filed pull request for the docs for this issue! Waiting on your response before updating the group documentation

Not AVG but you can use SUM. If the behavior is consistent then if you have a NULL Switch and SUM as the aggregation function it should behave the same as using AVG with Number Items and one of those is NULL.

I’m running a very old version of 2.2 so I’m not sure my test would tell us much. I’m on the pre-log4j2 migration primarily because there isn’t a good way (yet) to do upgrades with Docker without wiping out the whole userdata folder. I’d rather spend the time, when I have it, working on making that upgrade process better than rebuilding my userdata every single time I upgrade.

I’m not finding it. Can you post the link? Maybe it has already been accepted?