How to create groups that can control multiple items


environment: OH3 on PI4

I guess I have another typical beginner question:

I have items - e.g. lights (Hue) or roller shutters (Fibaro RS3) - in my system that all work nicely. For all of them, I have points and channels created to control them and get their status (samples below). This all works fine as well.

To be able to control items that belong together - e.g. all lights in one room, or all blinds on one side - with one action or widget, I have created groups and channels between these groups and the things again. This also generally works well, with some exceptions here and there:

  1. controlling the blinds in a group works from the OH3 UI and other WEB-UIs. However, it does not work from the iOS app - this only results in strange up and down movements.
  2. controlling lamps typically works, but every so often doesn’t - strange behaviour that is not really repeatable.
  3. getting back the status information of e.g. blinds tilt or open value or lamps brightness often works, but sometimes doesn’t. Also not really repeatable.

Before now continuing that path, I wanted to check with the experts here whether my approach is correct. Or is this all rubbish, and there is a much better way of achieving my goal?

Thanks much!


  1. Definitely file an issue on the iOS App’s repo. It should work the same no matter what UI is being used. The fact that you are sending a command to a Group Item should in fact be invisible to the iOS App in fact. It just needs the name and the command to send.

  2. Some technologies cannot processes commands that come in too fast. Hue is one of them. You’ll probably need a rule and use a forEach loop on the members of the Group and insert a short sleep between each command to keep from overloading the devices causing them to drop some commands. Often the binding will do this for you but occasionally they cannot. If you have a lot of similar such rules you might look into using Design Pattern: Gate Keeper.

  3. We’ll need logs (openhab.log and events.log) to see what the events were sent and received when it doesn’t work to even make a guess. It might be the same thing as 2.

Normally your approach is correct but sometimes limitations of the technologies involved make it not work.

Short version - don’t do that.
openHAB Groups have the magical property of distributing all commands sent to them to all members, which then do whatever they do over their own links (if any).
No link to any binding is required on a Group, and I am surprised the UI let you do it at all.

I am aware of that group functionality. But what am I supposed to do with things that receive identical commands for different channels?

Example: my Fibaro RS3 things receive a value between 0 and 100 on both the blinds and the lamella channel. I can e.g. send 100 to the blinds channel, that fully closes the blinds. Or, I send 100 to the lamella channel, that fully tilts the lamellas.

Now if I would send 100 to the group, that command would be automatically sent to both channels, right?

I had actually tried this approach in the very beginning of my project, but gave up on it exactly for this problem.

Maybe I’m missing something: why not create two groups for this example? One for the blinds, and one for the lamellas?

wouldn’t every group still send commands to both channels?

What do you mean both Channels? Are your Items connected to multiple Channels?

A Group is just a collection of Items. So you stick all your Items which are connected to the blinds Channels into one Group, and that Group will only control the blinds Channels.

Ye-es, but you have control of what “every” group includes.
Items may belong to more than one group.

Item blindX_up/down - member of group blindX
Item blindX_lamella- member of group blindX
Item blindY_up/down - member of group blindY
Item blindY_lamella- member of group blindY
groups blindX and blindY members of group backroomblinds

that sort of thing might be useful for display arranging, but as you say no good for commands being distributed to everybody.

That’s okay, groups are free and we can make more.

Item blindX_up/down - member of group blindX AND backroomup/down
Item blindX_lamella- member of group blindX
Item blindY_up/down - member of group blindY AND backroomup/down
Item blindY_lamella- member of group blindY
groups blindX and blindY members of group backroomblinds
group backroomup/down could be member of wholehouseup/down

backroomup/down and wholehouseup/down give us common controls

sorry for the late reply. Do I get that right: you mean I should not put devices into groups the way I did it, but rather put device (thing) channels, items, that belong together into groups. Understand. I’ll give that a try and report back if that solves my issues.

so I tried this out. Results are pretty similar to what I had before. controlling my blinds from the WEB UI works as before, my problems with the iOS app are also still the same - basically, controlling the blinds works with sometimes unpredictable results. For example, fully tilting the lamella up or down works most time, but setting something in between (I use a slider for that) doesn’t.

I also realized I was a bit inaccurate in the earlier description of my setup. I don’t have links to bindings on a group - that is in fact not possible in the UI. What I do have is items in groups that link to multiple channels. see the two screenshots attached - there is one RS3 that two channels, one for blinds and one for lamella. each channel is connected to two items, where one item belongs to a group that represents the specific RS3, the other item belongs to a group for all RS-devices in that room. As said earlier, this pretty much works, with some occassional exceptions here and there (similar to what I have with the new setup).

So I guess my question again is: is this the recommended way of doing things, or is there another best practice?

There isn’t a one-best-way to do this.
See Rich’s “point 2” earlier.

Maybe understand that to determine your path forward.
Your events.log will tell you if openHAB is doing its part as you expect.

ok. I was playing around with all this a bit more. It seems some devices simply have some sort of “latency” problem (as already suggested by Rich), and I suspect this is caused by their channels being connected to multiple items. The events.log (for sure I consult that to understand what is going on :slight_smile:) is showing all commands sent and received the way I would expect it, just the things do different things sometimes :slight_smile:. My really big issue with that is that the UX sometimes doesn’t show the thing status correct, e.g. a blind might really be closed, by the UX shows it as open.

For that, and in an attempt to reduce complexity of my setup, I was trying to get rid of these multiple items per channel and make use of the “group propagation” functionality described above, essentially following the great guidance received in this thread.

In order to achive that, I am removing the additional items per channel, and assigning the one item to multiple groups.

Now it seems I have a defect in the OH3 UI: while I can assign one item to multiple groups, the semantic model view does not display that correctly (see screenshots). In that example, I have an item " GalerieRS3_BlindsControl" as member of two groups “GalerieRS3” and “GalerieJalousienBlinds”. However, the semantic model view only shows the item as member of one of these two groups - always the last one the item was added to.

Any suggestions? Am I doing something wrong again, or is this really a defect?


is that feedback meant with regards to my problem with the semantic model view? If so, sorry, I don’t get the point?

No, it’s not you doing something wrong.

all right, so this is simply a defect in the UI, and I can go on changing my configuraiton like that, right?

Actually it kind of is.

No, it’s how the model works.

The model has the following rules.

  • A Location is a Group that has a Location tag, no other semantic tags can be used at the same time
  • An Equipment is usually a Group that has an Equipment tag, no other semantic tags can be used at the same time
  • A Point is usually an Item that has a Point tag and an optional Property tag, no other semantic tags can be used at the same time
  • No semantically tagged Item can be a direct member of more than one Group Tagged with an Equipment or Location tag.

Typically, to meet the above rules, one will not put their functional Groups (e.g. AllLights) into the model. Or, if you do put it into the model, you’ll tag AllLights with a Point/Property pair of tags and put it somewhere high up in the model’s hierarchy.

The model is intended to represent the physical layout and hierarchy of your home automation system. You wouldn’t have a Point that is part of two completely different Equipment. You wouldn’t have a Point or an Equipment in two physically different locations at once (there is an edge case I’m ignoring for the moment where one has a switch in one room that controls a light in another room). That’s physically impossible. So the UI doesn’t support it. I think HABot also has problems when you do that too.

But, as I said, you can still have your functional groups. Just don’t put them into the model.

now you managed to completely confuse me. I thought I was following the recommendation of rossko57 above, and simply put my items into different groups - one for visualization, one for automatization. The fact that the UX accepts all this and let’s me do all these things, and the fact that this pretty much works aside the small hickups mentioned, only adds to my confusion now.

An Item can be a member of any number of Groups. However, the model only allows an Item to be a direct member of one semantically tagged Group.

Groups that provide or represent some function, like AllLights that lets you turn on/off all the lights in the house with one command, are perfectly fine and encouraged. Just don’t give them a Location or Equipment semantic tag.

The model isn’t everything. It’s one way, an optional way, or organize and represent your Items. It is not the only way. Not all Items need to be a part of the model. Rossko suggested you create the Groups. He didn’t mention anything about the model.

Right now the model does three things:

  • presents some of your Items in a hierarchy that is supposed to mirror the physical layout of your home
  • is used to automatically generate the cards you see on the Locations, Equipment, and Properties tab of the Overview Page; if you don’t want to see it there don’t put the Item in the model
  • is sued by HABot to provide a rudimentary natural language chatbot interface to your openHAB system

The the purpose of an Item or Group doesn’t fit into one of those three, it doesn’t belong in the model. A Group that lets you send a command to all the blinds in the house doesn’t fit into that so that Group does not belong in the model.

wow - I was entirely misguided on that. Thanks for the clear explanation. Not sure if this is a “handbook-not-read” error on my side …

I will rework my setup accordingly now, and will keep posting progress here