I have been playing around with both groups combined with aggregating functions and with non-semantic tags and virtual items/javascripts. Is there a rule of thumb on when to use what? Let us say that I want to dim a set of lights together, should I then use a group and a aggregated function or is a better to use tags combined with a rule/script? Right now I am using scripts to switch lights on/off based on tags, but now I am looking into controlling the brightness too. Would it have been easier/better to add the items into a non-semantic group and use an aggregated function on this group?
As is, I have rules/scripts that switches off lights based on non-semantic tags. For instance I can controll the lights in the kitchen by referring to the tag “Kitchen” and “Light” in my script.
For me, it is really a question of complexity. A group (the aggregation function is irrelevant here), will distribute any command it receives to its member items. They will all, always get the same command. Rule/script will give you much more fine grained control and nuanced control over each item in the list.
For example if you always want to dim your lights so that they have the same setting then sending a command to a group is the more efficient way of doing this. On the other hand, if you want to dim all the lights but you want each light dimmed to a value that depends on the illumination detected by sensors in each room then you are going to need a rule.
As far as tags/groups go, there’s actually not a lot of difference. You can just as easily get the items that are members of a group in a rule as you can get a list of all items with tags. Tags do allow for searching in many of the settings pages in the MainUI, to see the members of a group you need to go to that group item’s detail page.
Given that similarity. It might be best for you to use groups because you can have the convenience of sending a single command in the simple situations, and using a rule when more complex situations require it.
Just for completeness, the aggregation function has nothing to do with passing information to the members of a group. You can send any command to any group and that command will be passed to all the member items. Whether the item can accept that type of command is then up to the item itself. The only thing that the aggregation function does is determine if the group itself has a state that is not Null. By default all groups simply have a null state, even if you have just sent the group a command (that command does not impact the group item it is simply distributed to the members). By giving the group an aggregation function you are telling OH how to use the states of the member items to generate a meaningful non-null state for the group. It’s a quick way to get summary information about the member items, but that all.
To be honest, I wasn’t aware that I could pass any command to a group. I thought it was dependent of the aggregate configuration set on the group. Good to know.
The only thing I want to add is it used to be the case (don’t know if it still is) that you had to give the Group a type (e.g. Group:Dimmer) before you could send a command to it. I think in the UI it’s called the “Members base type”. This may have changed though and it’s no longer required.
That is no longer the case. You can, for example, send a command to a semantic location item and have that command trickle down (for better or worse) to all the points in that location.
Yes, and in the UI you have to set the Member Base Type before you can set the aggregation function. The list of functions is dependent on the base type chosen (and I don’t think that’s changed with the new proposed item page updates).
