Yeah - worked it out as per the pic. You can group multiple similar “things’s channels” as one “item” that then gives you one control for all (or even individual control). I don’t think you can’t group an entire “thing” (with multiple channels) to one Item.
FYI - When I group an entire “Thing” with multiple “Channels”, the resultant “Item” does not present you one set of controls for the entire group, just the option to individually select each “Thing” from which you can operate the channels.
Does anyone know how to make the group work as a color item that can be used to control the whole group with one color picker card?
Having played around with the various options in the Members Base Type, e.g. Switch, Contact, Number, Dimmer, Rollershutter and DateTime, I think that actually a Color option would need to be added to the Members Base Type in order for a color picker card to be able to recognize the group.
Any thoughts on this? Or any suggestions for a workaround - could obviously just be done with a rule but it would be much more convenient to be able to control color lights directly through a group.
As you noted, the Group:Color doesn’t exist (basically color is not a type for a group). As such the Group doesn’t know how to deal with all the different color values that may be set on individual items and hence may contain a ‘null’ value which was not handled by the colorpicker control.
My workaround was to create a ‘ColorChanger’ item which runs a rule to update the group on change. As I use a naming convention for Items this allowed me to have a single ColorChanger rule that is in essence only two lines long:
// remove the 'Changer' from the triggeringItemName
val groupName = triggeringItemName.toString.substring(0, triggeringItemName.toString.length - 7)
One thing to note is that the ColorChanger Item does need to be initialized with a value or the colorpicker control will not show.
1). Create a global ‘ColorChanger’ group
2). Create a new point on the ‘equipment’ you want to allow color changing - this is just a regular Item with a ‘Color’ type and add it to the group created in step 1.
3). Create a rule - the trigger should be when a member of the group created in step 1 is changed.
The rule needs to know how to identify the actual Color item for the equipment. As I said I use a naming convention, so all I have to do is strip the word ‘Changer’ from the end of the triggering item name.
As you will note all the items are groups except the ‘ColorChanger’ which with the rule in place is simply proxy to the ‘Color’ group. The Kitchen Accent is made up of a few different LED Strips and each of the strips items are members of the respective group.
As a caveat if you find the Color sliders are not being displayed, check that you are initializing the value of the ColorChanger (ie. it should not be NULL). Currently I use a startup rule to set all members of the Grp_ColorChangers to a predefined value.
I would add that if you change the color of the equipment by some other means the UI won’t update (ie. if I use the dedicated smartphone app to change the color of a member of the Kitchen Accent).
What do you want to happen? By default, the Group with no type will list its members, that’s its default widget.
You’ll want to change the widget in the Group Item metadata to get something else - not sure if you need to assign the Group a type, I think you only need that if you want a group state (which you might very well need for a colorpicker style widget).
This is a UI problem, they accidentally omitted the Color type for Group selection. I thought this was fixed some time ago, but maybe not.
There are workarounds, you could define the Group using the old xxx.items file text syntax, and paste that into “Add Items from Textual Definition” to create the Group:Color type.
On reflection though, I don’t think that’s going to help in the long run. To be much use, the colorpicker UI widget wants a starting point, a valid state from the Group.
That’s okay, Groups have “aggregation functions” like MAX or AVG which will give the Group a state based on members states.
I don’t think that’s properly implemented for Group:Color
We can do a common Group:Dimmer with a brightness slider (even if members are Color types), or similar with master Switch, but that’s not what you asked for.
I don’t know what kind of lights you are dealing with here, but an alternative and very kludgy approach to using a Group is to create a new fourth “ordinary” Color type Item, and link it to all three of your binding channels (as well as keeping their original independent Items). This is @joriskofman suggestion above.
The state of this Item will be a bit indeterminate, but it should be usable with a UI colorpicker to transmit common commands to the three channels.