Mixed Items Group status Aggregation improvement

Setup, Configuration and Use Items & Sitemaps
1

OH Items can be groupped together.
As I understand it, there are 2 main situations.

The first one is the way OH represents Things. For example, a power outlet will be represented by a Switch type Group Item with an On/Off switch, a voltage measure Item, current measure Item, power measure Item.
That kind of Groups is what OH creates when using ‘Add Items from Thing’.

The other kind of Groups is to globally manage similar Items, for example, regroupping several switch Items to switch on or off all the corridor’s lights.

OH enforces a status to the Group Items.
This seems logicall and obvious for Groups of similar Items.

But as a beginner, the first Groups I have been dealing with are Things Item Groups.
And from the beginning, I have been disturbed by the global status of the Groups. I spent ages fiddling the Aggregation values without ever resulting in a logical and reliable status.
I was naively thinking that only the Items of same type as the group were taken in account.

Today, I think that a global status for a mixed types Group has no sense the way it exists.
For a switch Group the Aggregation function has possible values ‘None’, 'All On (or Off) → Status ’ and 'One On (or Off) → Status '.
What doesit mean for a power outlet Group with an On/Off swith Item that goes ON and OFF and a Voltage Item that always show 223 V.
This is like adding apples and rabbits expecting to get a bycicle.

OH itself is not logical: when going to the Equipment tab from the Main UI and then to the Poweroutlets, one can see the status of all the Poweroutlets, and it is a pity that the status is generally wrong (Can be OFF when the PO in ON, can be UNDEF…).

Sometimes, not being able to have a reliable status of the group, I had to create additionnal Groups for the Items I needed.
But then, another problem arises: The OH semantic model doesn’t allow an Item to be defined in more than ONE Group.

There are several people who reported the same difficulties and misunderstanding as what I describe.
All is related to the Group status, and thus the Aggregation function.

So, is there a possibility to improve the Aggration function ?

  • Add the option to only consider the children Items of the same type as the Group.
    For example, for switch Items Groups only consider switch children.
  • At least add the option to have NO (not None, NO) Aggregation function so that the Group status can be controlled by rules.
    This is not possible today, because for Groups OH systematically enforces the Group status from the children status.

Thank you for you comments.

Regards.

2

A few things that may help clarify this:

  • There is no obligation to define a group aggregation function for a group. Only do that when it makes sense. If you use create equipment from thing, it will not have an aggregation function for the created group. I would say that in most cases aggregation functions for semantic groups make little sense.
  • An item can belong to multiple groups, but only to one semantic group (there is a small exception for points that can both belong to an equipment and a location the equipment is not part of). These other non-semantic groups are probably where you want aggregation functions, as that allows you to control all members together. E.g. switch off the group and all lights in the group will switch off.
  • The aggregations in the default location, equipment and point pages don’t rely on these group aggregations at all.
3

Sorry, but I don’t see how it would be possible not to define an aggregation for a Group.

Group Items can have ‘None’ member type and ‘None’ aggregation. This implies they won’t change status by themselves.

But programmatically setting their status to ON or OFF (Open/Close, aso…) is rejected.

They will have no valuable status.

For member TYPED Items Groups, switches, contacts, lights, roller shutters, ASO, Aggregation IS mandatory.

It can be set or defaulted to ‘None’, but ‘None’ is by no means NO aggregation: OH will still decide the Group status based on the children Items.

It doesn’t seem illegitimate to me (and probably to many) to have a Group Item reflect the status of its physical Thing controlled by the ‘main’ child Item, and show a correct status wherever needed including Rules and OH Equipment lists.

So, I’m back to my previous question, is there a possibility to improve the Aggration function ?

  • Add the option to only consider the children Items of the same type as the Group.

For example, for switch Items Groups only consider switch children Items.

  • At least add the option to have NO (not None, NO) Aggregation function so that the Group status can be controlled by rules.

This is not possible today, because for Groups OH systematically enforces them Group status from the children status even if Aggregation is set to None.

Thank you for you comments.

4

This sounds like an X-Y problem. Can you tell us why you are trying to set a Group state? Trying to “set the Group state” is what’s causing the problem here.

Even if a group has an aggregation function (and no it is NOT required) you cannot set the state of the Group directly. If you send a command to a group item, then all the child Items of that group get that command and may (or may not) change as a result. If changes to those child Items result in a change of the aggregation value then the calculated Group state will change.

5

Groups aren’t only about a grouped state
Groups can be used

  • as logical grouping, for example all Items that belong to a dedicated thing (i.e. equipment)
    or all items that belong to a room (i.e. location).
  • as aggregation, sum, avg, min, max, or, and… which is useful for measurements
  • for displaying the members (e.g. chart Widget in BasicUI)
  • for control of persistence
  • for rules iterating through items

Each of these functions are optional, so a Group can be used by one or more of these options.
So, you can use a group item state, but you don’t hace to. However, if you want an item to have a dedicated state, you have to use the correct Itemtype. aggregation is always optional, if the item is of type number, switch or something similar.

6

These groups (without member type and aggregation) are the typical groups you find in the semantic model, or to help you in rules when you want to iterate over members in a group.

That is as expected. No member type means they will not have a status. Again, the purpose of these groups is not carrying a status, but as a grouping in a hierarchy for use in rules or the semantic model. It can also be used in constructing a UI.

None will use EQUALITY. So maybe we should rename it in the UI. The EQUALITY aggregation function will set the group state to the state of the members if all have the same state, or leave it to UNDEF otherwise.

If you want to have an item that represents something from the group and you want to update this through a rule, you don’t need a group item. A simple item will do.

Nothing is impossible. However, this functionality has been there since the beginning of OH. Touching this may have unexpected consequences in many user’s installations. So it will be looked at very carefully before accepting such a change.

That may not be straigthforward. E.g. the AND aggregation function will work with Group members for any binary type. Imagine you define the group as Switch type with aggregation type AND, you can add Dimmer items to the group. The AND function will consider the individual dimmer item to be ON if the state is different from 0. Should I now not count this anymore? This has high risk if we start changing it.

Also, you can send a command to that group item and it will command the member items with that command. It is very useful to e.g. switch off all lights, even if some of them are just on/off, others are dimmers and yet others are color lights. What would happen to these command in that scenario?

That is something in my view that must be possible. But I still don’t see the benefit compared to using a group item with no item member type at all.

You cannot set the state of a group item, you can only command it. Its state always gets set through the aggregation function. So if you command it, the logic is to send the command to the members, and the members update the state through the aggregation function.

What you want to achieve I believe (have a state for a group item without it being calculated automatically through an aggregation function) cannot be achieved by not having an aggregation function at all. If you want an item with a state that is not controlled through an automatic aggregation, you should use a normal item, not a group item. That normal item can be updated, doesn’t have to be commanded.

7

When you add a power outlet Thing, then you (at least I) will go to the channels and ‘Add Equipment to Model’.
Then OH (not me, OH) will create the channel Items and group them in a Group Item.
And I’m very happy having all the characteristics of the Thing grouped in a Group Item.
I just would like the Group status to be correct.

The initial default Aggregation will be ‘None’.
If the selected channels include an On/Off switch and measurements (voltage for example), the status of that group OH created will be inaccurate including in standard OH pages such as the Equipment tab.

I still think that it is not logical not coherent (why does OH create Groups with inaccurate status) and not what can be expected.
Let me be clear, I only talk about Items Groups related to Things.

Anyway to be honest I felt that changing the Aggregation process could be complicated.

So I’m not surprised if it is not possible but a bit disappointed I must say.

Thank you all again for your help.

8

Create Equipment from Thing, to my knowledge, will create a group without member type, so the aggregation function is not relevant and will do nothing.

9

Yes you’re right.
I forgot it, but in fact I change the type, as well as the icon.
There are many details to change when ‘Adding to model’.
OH doesn’t create Groups with inaccurate status.
Sorry for the confusion.

But it just creates groups with no status and I still feel it should be improved.

Anyway I have understood there are little chances of improvement and I will have to continue to cope with the way it works today.

This thread should be closed.

Thank you all again.

10

This is where you are deviating from the expected pattern. It does not make sense (99% of the time) for an equipment Group Item to have a state. I have several multisensors around my house: should the state of that equipment Group be the temperature, or the light level, or the motion alarm status? Without you showing us an example, I can only guess, but I suspect this means that you are not really building your semantic Groups with the membership that is intended for the semantic model. The model only ever expects and is 100% built around the idea that an equipment Group will contain all the items related to one specific, (usually physical), real-world object.

If you have a collection of Items from different objects and it makes sense to combine the states of those Items into one state, then definitely put those items in to another group, just not a semantic equipment Group.

On the other hand, if you have an equipment group and there is one particular item that you think does represent the actual status of that physical entity better than the others, then there is a way for you to configure you semantic model pages to reflect this: When you are on your Overview page, click the pencil icon in the upper-right corner. Then select the equipment set of options:

image
image802×139 5.91 KB

Down near the bottom of the page, there is a series of options for the display of equipment in the model page. One of those:
image

allows you to arrange it so that one particular point of the equipment is displayed at the equipment itself.

Alternatively, you can build a custom widget that collects whatever information from the child items or beyond and combines those in any way you see fit and then use Default List Item Widget metadata for the equipment Group to make that what is displayed in the model instead of the standard accordion list item.

image
image465×737 46.7 KB

11

Thanks Justin.

You have pinpointed one main difficulty: Wich is the Item that should drive the Group status.

Most people may be interested in the On/Off status, and some other in the voltage.

Seeing Things Groups with no or wrong status has been itching me for a time.
This is why I started this thread.

For clarity I will remove aggregation everywhere it should not be set.

12

:+1:

I just want to point out the opposite is also possible. You can exclude the individual Items and just put the Group Item with the aggregation function into the semantic model as a Point. I would use this approach, for example, to represent a single lamp with more than one smart bulb which I always want to work in unison.

That’s cool! I never knew one could do that. I knew you could identify an Item for the badge on the Locations tab but didn’t know about this. I’ll have to experiment some when I have some time.

This is veering a little bit off topic but I think it’s close enough to mention it here.

Given what you said here, I suspect you might also attempt to put all your items into the semantic model. It’s a natural thing to want to do. If the semantic model is good for some of the Items, why not all?

My caution here is that’s not the purpose of the semantic model. Think of the semantic model as the user facing (i.e. the users of your home automaition) structure of your home automation. It models the physical layout of your home automation because that’s how your user’s approach and understand the home. But given this, only those Items that your users need to directly interact with belong in the model. In my experience only 60%-80% of all the Items belong in the semantic model.

For example, do your users really care about that voltage Item, especially if it never changes? If not, maybe it makes sense to exclude it from the model entirely, or even remove the Item entirely if it’s not used for anything at all.

13

Agreed, useless Items are a nuisance, for Zigbee network, for displays, and for logs.

14

I had a look at the Demo server.
It has a flat organization with standalone items.
There are Groups, but functional groups of similar Items.

When I started with OH, I had no real idea of how to organize all the system.
I added Things with channels and OH proposes to parallel all this, with a Group Item associated to the Thing (I keep the same name) and children Items associated to the channels.
So I have a somehow hierarchical Thing-Oriented organization.

When ‘Adding Equipment to Model’, some information is pre-filled, some not.
So having Group Items with no type and aggregation didn’t really suprise me.
I just ‘corrected’ to switch type for Poweroutlets and aggregation whatever.
And as in the beginning I was only interested in controlling the power outlets, there was only one switch child and aggregation worked perfectly.

But one day or the other, I wondered what power the coffee machine uses, added measurements Items to the Group and…
… This messed up completely aggregation and my understanding.
As a beginner, it seemed obvious to me that switch group aggregation only applied to switch children types and ignored the rest.
But no.

Since, knowing the Group Items status was possibly wrong, I never relied on it.
But I didn’t change anything, hoping there would be an evolution one day.

Today, as I said, I finally removed aggregation for many groups.
No status anymore… but also no wrong status.
Let’s consider the subject is closed.

As Justin mentioned above, I have created quite a time ago widgets that only care about the relevant individual items for Power outlets, Wall switches, aso, to give me a global view.
He recently helped me creating new ones. Thanks again.
But I still happen to use the Equipment tab or other pages from time to time.

That was my experience as an OH beginner.