As you can see they are all set to aggregate to the AVG of the child elements and the pattern is set to %d (tried %.0f as well).
However the top group is showing a weird number although the child groups are 100%.
In addition the pattern seems not to work as the number is still something like 16.06250000 and not consistent over all views - compare the group member view and the detailed view (100.0000000 vs. 100).
Is there a known issue in oh 3.2 or do I have to set a different pattern here?
Hmm, I really don’t get this group settings function as it seems or there is a major bug here (which would be weird as I assume more people are using this function).
I have a virtual group item where I want to show the aggregated state as well. If all are ON it should be ON, else OFF.
Note that there is no event when an Item is added or removed from a Group. I don’t know if it will recalculate the Group’s state until one of the Items changes state after. So make sure to manipulate your child Items after making a change to the Group to force it to recalculate the Group’s state. That probably explains the Switch Group’s behavior, it could explain the other one too.
This is how Groups have always worked so it’s not something new in OH 3.
You are working with Groups of Groups it looks like. What is the aggregate function for the child Groups? I don’t actually know what is supposed to happen with Group child members and aggregation functions. There are lots of reason to think that they might be ignored. Group child members are ignored in lots of other circumstances too (e.g. persistence). But if it worked in OH 2 it should probably still work so :shrug.
I have a portion of my setup that has child groups with aggregation functions inside a group with an aggregation function and it works just fine, at least with the binary aggregation functions.
I’ve not tried it with the numerical functions in OH3. However, if I recall from some experiments I did in OH2 (and this is going a ways back so my recollection might not be 100% accurate), the numerical aggregator functions double counted the members of the child groups. The members got counted as descendants of the main group and then the aggregate state of the child group was also taken into account. I could see this being the issue here if, perhaps, the descendant items are not all identically formatted (e.g., some are 0 - 100% while others are 0 - 1 with formatting).
I can confirm that the one issue I had is gone as soon as a member changes. So thx for this tip.
And I think I found the cause for my other issue as well.
I got this issue in the log
2022-05-11 13:56:44.929 [WARN ] [org.openhab.core.items.GenericItem ] - failed notifying listener 'gruppeBeschattung (Type=GroupItem, BaseType=RollershutterItem, Members=3, State=100.00000000, Label=Gruppe Beschattung, Category=blinds)' about state update of item gruppeBeschattungEG: Value must be between 0 and 100
java.lang.IllegalArgumentException: Value must be between 0 and 100
at org.openhab.core.library.types.PercentType.validateValue(PercentType.java:93) ~[?:?]
at org.openhab.core.library.types.PercentType.<init>(PercentType.java:88) ~[?:?]
at org.openhab.core.library.types.DecimalType.as(DecimalType.java:188) ~[?:?]
at org.openhab.core.internal.items.ItemStateConverterImpl.convertToAcceptedState(ItemStateConverterImpl.java:64) ~[?:?]
at org.openhab.core.items.GroupItem.stateUpdated(GroupItem.java:378) ~[?:?]
at org.openhab.core.items.GenericItem.lambda$1(GenericItem.java:257) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
