Eclipse Community Forums: Eclipse SmartHome » PaperUI rendering of channels?

Help

Home

Home » Archived » Eclipse SmartHome » PaperUI rendering of channels?

Show: Today's Messages :: Show Polls :: Message Navigator

PaperUI rendering of channels? [message #1704139]

Fri, 07 August 2015 15:25

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

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

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704143 is a reply to message #1704139]

Fri, 07 August 2015 15:55

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Quote:

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

The Paper UI renders what the ColorItem supports. Each item has a list of supported commands. A ColorItem supports sending the color. But it also inherits from a DimmerItem, which allows sending a percentage value. The DimmerItem again inherits from the SwitchItem, which supports the OnOff command. You can the list of accepted command types here: https://github.com/eclipse/smarthome/blob/6da2cdc2772a9c53ac8040ca5669624c1f375c32/bundles/core/org.eclipse.smarthome.core/src/main/java/org/eclipse/smarthome/core/library/items/ColorItem.java#L44.

The binding must be prepared to receive all valid commands for an item, which the channel declares as accepted item type. Of course it can ignore some commands.

Regards

Dennis

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704145 is a reply to message #1704143]

Fri, 07 August 2015 16:00

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Btw: When reimplementing the hue binding and also the LIFX binding (which both have ColorItems) I had long discussion with Kai about how to model the channels. If there should be a separate channel for switching it on and off besides the color channel. At the end he convinced me, that only one color Channel is needed.

Maybe Kai can comment what were the arguments for having ColorItems with OnOff and Percentage commands instead of having separate channels.

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704146 is a reply to message #1704143]

Fri, 07 August 2015 16:02

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

Ok - I can easily add support for this, but I'm not sure it makes sense in every case (but then it's probably just an issue with the UI itself rather than the system)... As another example, we have a colour temperature channel which is rendered as a dimmer (which mades sense). PaperUI then renders a switch, which makes no sense for a colour temperature channel (or does it?).

I just think the UI looks messy and it's not obvious what control does what - my device has 3 channels - color, dimmer, and temperature, and in the UI I get 7 controls - 3 sliders, 3 switches, and a color slider.

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704147 is a reply to message #1704146]

Fri, 07 August 2015 16:05

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

Quote:

When reimplementing the hue binding...

Interesting... To me, this removes some of the flexibility from the user. Now, even if I only want to put a switch in a GUI, I have to have a lot of controls. Personally I think it would be better, or more flexible at least, if the channels were supported separately?

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704148 is a reply to message #1704147]

Fri, 07 August 2015 16:15

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Quote:

Interesting... To me, this removes some of the flexibility from the user.

I think in sitemaps the user has the change to define what how the UI should look like. So the flexibility comes in with Sitemaps. But as long as the Sitemaps concept is dependent on Xtext the Paper UI will not support sitemaps and has to make guesses what are the best controls for an item.

Quote:

my device has 3 channels - color, dimmer, and temperature

I think if the device is just a color bulb it should have just two channels like hue and LIFX.

Quote:

and in the UI I get 7 controls - 3 sliders, 3 switches, and a color slider.

Yes of course as I said in some cases the rendered control isn´t optimal. But I each Item is rendered individually.

Quote:

PaperUI then renders a switch, which makes no sense for a colour temperature channel (or does it?)

For hue it does, because the hue binding supports the OnOffType also for the color temperature channel. It turns the lamp off an on. If you just want to use the color temperature channel and you disable the color channel, you still can switch the lamp on and off.

Report message to a moderator

Re: PaperUI rendering of channels? [message #1704161 is a reply to message #1704148]

Fri, 07 August 2015 18:43

Chris Jackson

Messages: 256
Registered: December 2013

Senior Member

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 Smile

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 Sad

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 Sad

Chris

[Updated on: Fri, 07 August 2015 19:02]

Report message to a moderator

Previous Topic:	Yoxos installer requests credentials because of non OpenSource profile
Next Topic:	Channel without an Item

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 07:31:45 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter