I have just added two Ikea RGB bulbs to my Hue hub, they both appeared in the PaperUI inbox and I added items to the colour channel on both, added the items to a sitemap and can change the colour of the bulbs perfectly. I’d like to be able to add the colourpicker items to a group so that I can change the colour of both bulbs at the same time to the same colour. I’m using OH 2.5.9.
I’ve also added the group gLivingRoomColourLights to both items linked the colour channels of the two bulbs. I then added a colour picker to the sitemap:
It might be the UI widget is behaving a bit odd; this Group will have no state for the widget to display, which might limit what you can do with the widget from a void starting point.
I’m not sure what a sensible aggregation function would be for a Group of Color types; AVG or MAX perhaps?
I might be exposing my ignorance here but why would a colour group need an aggregation function? Would it be required when the colours of the individual component bulbs in the group are changed? I can see how one red colour and one blue colour combined into a group would be difficult to represent (purple?:)). Is there any benefit to having an aggregation in this context? If the group is them item doing the controlling from the UI then the aggregation should always be the same as the components.
It’s the only way for a Group to get a state, derived from its member Items.
You don’t have to have one, and very well may not want one.
But this sitemap widget -
is going to try to display to the current state of the Item you give it e.g. current colour, brightness slider position etc.
I’m suggesting the widget, or rather the widget of the particular sitemap based UI that you’re looking at, might have difficulties with NULL state.
Where shall we put the brightness slider? You can imagine for example it is difficult to increase brightness when the starting point is … well, void.
I see your point now. I was considering using a group to pass commands down to the members. However, if you want to use a group in rules and need to check the state beyond anything more complex than ON/OFF an aggregate function becomes less intuitive.
For the time being my son is happy to play with the colour picker manually so I don’t need to consider the aggregate function… yet.
I spent some time tinkering with the some of the Hue lights that I’d added to a group and the behaviour did indeed seem to be slightly unpredictable without an aggregate function added to the group. After some time turning individual bulbs on and off or dimming them and then doing the same to the group I found that some bulbs wouldn’t respond. They either wouldn’t dim, or they wouldn’t change colour or wouldn’t turn on, or off, etc. After adding the MAX aggregate function and turning the group on and off a few times the behaviour became far more consistent.
Occasionally a bulb doesn’t respond to the first command from the UI and I have to tap the switch on the UI again but that could possibly be due to their distance from the Hue hub
Well, what I was worried about with the (absence of) Group state was whether the UI widget would issue sensible commands.
You can verify that by inspecting your events.log, where every UI command to the group will be displayed.
The next problem you may run into, even when the Group is commanded correctly and forwards the commands to member Items, is that it all comes in a rapid-fire flurry. There is no delay between multiple commands to different devices.
Some technologies don’t deal well with that, and drop messages.
In that case, you see the command to the target Item in events.log but no response at device.
