Color Channel or Multiple Channels?

Development
1

Just a little advice wanted here…

So from the color channel we can use this for dimming and also on/off.

Is it best practice to include a switch channel and a dimmer channel aswell? Or just the color fine?

2

I know the zwave binding just uses a dimmer channel that also responds to on/off commands.

3

I don’t know whether there is a best practice but since I use two different bindings for lights I have at least an opinion: The Espmilighthub binding does not have a switch channel but the miio binding does.

I personally like the color/dimmer channel only behaviour better because it is simpler when it comes to consistency: The miio binding for example does not set the brightness channel to 0 when the lights are switched off. While I would not consider this wrong semantically this requires some extra handling on the item level to keep it consistent to other bindings. In my opinion this should be consistent already on the Thing level and I guess most bindings simply use one channel and set the brightness to 0 when lights are off.

If you decide to have separate channels and keep the brightness consistently tied to the on/off state I don’t really see the point for a separate channel since the information and controls are already there.

4

Turn it round a bit … why would a user want those, what extra value will they provide that a Color doesn’t?
Everything you can “do” to a Switch or Dimmer (commands), you can do to a Color. (It’s up to your binding to support that,of course. You might opt not to support INCREASE/DECREASE and ignore.)
All the UIs (should) supporting representing a Color using Switch-like or Dimmer-like widgets.
Rules can extract states “as onOffType” etc. when needed.

About the only obscure thing I can think of is that you could chart a Dimmer more easily than a Color. But you can make a proxy Dimmer from a Color and it’s no harder than using a dedicated extra chanel …

1 Like
5

So before these posts I’ve opted for separate dimmer and switch channels and have disabled dimmer and switch operations on the color channel.

There were a few reasons for this…

  • Color and White channels on the api are separate, the mode has to change for controls to work for each type (ie. mode = white, colourTemp available, mode = color, rgb available
  • each color and white channels have their own brightness channel within the json
  • The api has (what I class) strange behaviour. If the switch isnt on, the api will not accept changes to other channels
  • mode cannot be sent to the api, it changes automatically if the color is changed or the colortemp is changed

I’ve implemented this, and also restore last brightness on switch on.
I’ve also had to implement turning the switch on if the brightness is changed as the api still reports the switch as off even though the bulb comes on :frowning:

I don’t know if there’s also a bug in OH2.5.x… command instanceof HSBType doesn’t pick up a change on the color channel, it always comes in as a PercentType for some reason so I have to do command.toString().contains(",") instead

6

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.