| PaperUI rendering of channels? [message #1704139] |
Fri, 07 August 2015 11:25  |
Eclipse User |
|
|
|
I note that the PaperUI makes assumptions about a device when rendering some channels. For example, why does PaperUI render a color channel with a color slider, a dimmer slider, and a switch?
Shouldn't the device/thing expose the channels, and the UI just render them, so if I have a colour channel, shouldn't it just provide color setting slider? It means I get unsupported commands sent to the color channel in the thingHandler as it sends dimmer (%) commands which aren't supported by the channel - same for the switch... Of course I could look at hacking something together to add this support, but it seems wrong to me that the UI is ignoring the channels and rendering how it wants as this may not suit all devices or implementations.
Shouldn't the UI render the channels that the thing exposes and not make assumptions that a color channel also supports on/off and dimmer as this may not be the case for all devices.
Chris
|
|
|
|
|
|
|
|
| Re: PaperUI rendering of channels? [message #1704161 is a reply to message #1704148] |
Fri, 07 August 2015 14:43  |
| Eclipse User |
|
|
|
Quote:
I think in sitemaps the user has the change to define what how the UI should look like.
Ok - that makes sense - I keep forgetting that sitemaps are still around 
Quote:
For hue it does, because the hue binding supports the OnOffType also for the color temperature channe
That's maybe not what I meant - while it's possible to make anything change when you click a button, that doesn't necessarily mean that some data types are things that are logically linked. In my mind (maybe wrong) an on/off switch isn't necessarily something I would think of if someone mentioned colour temperature, even if the Hue binding has chosen to implement it in this way...
Quote:
I think if the device is just a color bulb it should have just two channels like hue and LIFX.
This becomes a big problem for me  In zwave, each of these 'channels' (brightness, colour, on/off) are all handled separately in different command classes. Currently, each command class is linked to a channel, and the channel configuration, and this link, is made in the channel properties. With this requirement that a channel should handle multiple different streams of data (on/off, brightness and colour for example), it means that I need to change the concept of how channels are defined since I can now no longer split them functionally. I need to somehow consolidate the multiple command classes into a single channel and work out how to send it to the different devices, depending on the device configuration.
I think I need to rethink how the zwave binding works if this how things are meant to work - I will effectively need to increase the amount of configuration so that I can deal with all the different types of data that might turn up in a channel
Chris
[Updated on: Fri, 07 August 2015 15:02] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.31866 seconds
Home