openhab-core
openhab-core copied to clipboard
[Sitemap] Widget for color temperature
Is your feature request related to a problem? Please describe.
For some time I created two sliders for lightbulbs that can change their color temperature. One for brightness, one for color temperature. Recently I acquired a Nanoleaf Elements light (LEDs with brightness and color temperature settings). The binding allows to use a color picker to control both brightness and color temperature settings. All colors expect in the range cold white to warm white are ignored by the binding, but I can control both with just one widget.
Describe the solution you'd like
Add a new option to the Color widget (e.g. temperatureOnly) that limits the color selection from cold white to warm white.
Example from the Ikea Tradfri app:
Describe alternatives you've considered
Additional context
Coordination between maintainers
Notify maintainers of other UIs: @openhab/webui-maintainers @openhab/android-maintainers @openhab/ios-maintainers
Checklist for implementation:
- [ ] Core
- [ ] Basic UI
- [ ] Main UI
- [ ] Android app
- [ ] iOS app
- [ ] Docs
For a color item, we have already the colorpicker widget to select the color, the slider widget to select its brightness and the switch widget to turn it on or off.
For color temperature, we could imagine either a new widget or an option to the existing colorpicker widget. In both cases, we need to implement a new UI in all apps. It could be a simple slider ? As a min and max values are probably required, a new widget similar to slider widget would be better I believe. We could name it colortemperature.
To be thought how an UI can then build the command to be sent to the server.
For a color item, we have already the colorpicker widget to select the color
The colorpicker can also control the brightness, which is very nice.
When making the color temperature a new option for the colorpicker, we solve two issues:
- The state is transmitted as HSB and the binding then has to parse brightness and color temperature from that single state.
- Clients without updates show the current color picker which is still useful. It also shows unsupported colors, but better than nothing.
The state is transmitted as HSB and the binding then has to parse brightness and color temperature from that single state.
Color temperature channels are either Dimmers or Numbers though, not Colors, so I don't think that idea will fly.
For controlling color temperature channels, the client would need to differentiate between dimmer (relative) or absolute channels (by item type):
- Dimmer items have a slider range of 0..100; we'd need to show some generic gradient for those. Commands sent are ordinary percentages.
- Number items should have min and max in their state description, so we could calculate the precise colors for the gradient. Commands sent equal those of normal number sliders
Ok, so then it's required to add two items to one widget, like ColorTemperature brightnessItem=foo temperatureItem=bar. This is probably the first widget with more than one item. Is this an argument against it?
You could consider to do it like the Philips Hue App -- see screenshots below..