Openhab-android: Support Slider "switchSupport"

[kvolden]

It's pretty common for home automation software to support having both a switch and a slider-like element combined into one for dimmable lights – Z-Way, ImperiHome, Fibaro Home Center, Vera etc. Slider elements in openHab already have the "switchSupport" parameter, but this is only used in Classic UI, and there only to modify the function of the already existing up and down buttons. In the Android UI one is left with having to create two elements for the same thing, one Switch and one Slider, with basically the same label and controlling the same thing, taking up twice the real estate and making the control slightly more awkward than it needs to be.

I would love to see switchSupport implemented in the Android app as well, but rendered as a single element with both a switch and a slider bar, much like this (although this image is from manipulating a Basic UI element, you should get the idea):

The usefulness of this is e.g. for Z-Wave items that have support for ON and OFF commands as well as for precise levels. Usually ON has a value of 255, and will often turn the device back on to its previous dimmer level (or a specific preset value, or something else entirely, all dependent on the physical device and its configuration). So this must not be confused with ON just being a shortcut for setting the slider to 100% – something on which the documentation is a bit unclear with regards to Classic UI functionality.

[kaikreuzer]

I agree that often one would want to switch or dim a certain item and yes, in some way the "switchSupport" flag in the sitemap is meant as a hint for that. (Note that the original requirement for it was to set switchSupport=false for stuff like volume control, where you do not want to accidentally switch it to 100%). The reason it is only used in the Classic UI is that it does not support sliders and thus does dimming by long-pressing buttons (while short press is switching).

I think it needs to be discussed how switching should be supported, if sliders ARE available (as in all other UIs but the Classic UI). The suggestion in the screenshot above is imho absolutely NO option - it merely adds two widgets in a single line, which destroys the visual overall structure as well as it consumes too much screen space (I'd much prefer wider sliders, if space is available).

We should instead have a SINGLE UI element that offers different interactions - but I am not sure that would best look like given the very limited space per widget; it would probably be best to work with modal widgets that pop-up and offer a proper dial or something similar.

[mueller-ma]

it would probably be best to work with modal widgets that pop-up and offer a proper dial or something similar

I would avoid having a popup here since it adds another click until the light is dimmed.
Maybe holding the element for toggling?

[kaikreuzer]

since it adds another click until the light is dimmed.

Yes, I agree that this isn't ideal.

Maybe holding the element for toggling?

Rather a surprising effect on a slider. As for me, I would simply claim that a slider in itself if good enough, if it is possible to easily hit 0% and 100% on it, so I don't really see much need for action here...

[kvolden]

it merely adds two widgets in a single line, which destroys the visual overall structure as well as it consumes too much screen space (I'd much prefer wider sliders, if space is available).

Well, it consumes far less screen space than having two separate elements, so at least it's an improvement from the current state of affairs in that regard. It is also optional, so if one would prefer to split it in two elements, or only have the slider, this is still perfectly possible.

As for me, I would simply claim that a slider in itself if good enough, if it is possible to easily hit 0% and 100% on it, so I don't really see much need for action here...

But as I said in the first post:

Usually ON has a value of 255, and will often turn the device back on to its previous dimmer level (or a specific preset value, or something else entirely, all dependent on the physical device and its configuration). So this must not be confused with ON just being a shortcut for setting the slider to 100% – something on which the documentation is a bit unclear with regards to Classic UI functionality.

[kvolden]

@kaikreuzer Also, it certainly doesn't take up more screen space than a multi-button switch easily will. Take a look at this example from the documentation:

So to recap:

• It takes up less UI space than the alternative of having a separate element for switching. A separate element for switching is also awkward UI-wise in that you need two separate elements controlling the same item with more or less the same label.
• The controls take up less space within the element than the controls of a multi-button switch is likely to do.
• One could also argue that the multi-button switch also contains more than one widget in a single line, depending on your definition (a distinct element for interaction, for instance, which for visual structure purposes is a good a definition as any, in my opinion, though admittedly they are all of the same type).
• The switch is optional. It is only there if you want it to be, and if one prefers to not have a switch or to have it as a separate element, for visual reasons or otherwise, simply don't use the switchSupport parameter.
• Again: The switch is not a shortcut to 0 and 100. It is an ON/OFF switch, and its function – though often turning the light back on to its previous dimming level – depends on the actual device and its configuration.

[mueller-ma]

@kaikreuzer @kvolden Can you live with the suggestion I made in https://github.com/openhab/openhab-android/issues/550#issuecomment-377672560?

[maniac103]

@mueller-ma Item 1 (make full roe touch target for switch) makes sense to me, but I'm not sure about item 2. If I understand it correctly you want to send on/off (select which of the two how exactly?) when clicking into the background of the slider row. Did I get this right? If yes, I'm against adding such a feature because it's unintuitive, undiscoverable and thus surprising to the user, at least IMHO.

[kvolden]

@mueller-ma Sure. But I still think adding the switch widget is a cleaner solution, and I still think the arguments I presented above hold. :)

@maniac103:

select which of the two how exactly?

If it's OFF (0) a click turns it ON. If it's not OFF (>0) a click turns it OFF.

when clicking into the background of the slider row

Anywhere in the row except for on the slider widget itself ("ball" or "track"), as long as "switchSupport" is set, I assume. Clicking on the slider itself would bring the current behavior.

Possibly a little bit unintuitive at first, but it certainly wouldn't be undiscoverable. Assuming this would be documented, it should only be surprising if you've enabled switchSupport, haven't read the documentation and touch the row outside of the widget – in which case it would be surprising only on the first click.

[kaikreuzer]

@mueller-ma I think this would be by far the best solution - as commented here, I believe we should in any case support the row as a touch target - so for a slider with switch support this would be the natural switch operation.

[dotorg]

Is this a dead suggestion at this point? It looked like it got implemented and then not pulled, or pulled back out? It doesn't seem to work.

Before I fork and re-implement it, I figured I'd ask what was going on with it. Its a bit of a struggle to get a usable UX out of the app for lighting because it seems like its trying really hard to stick to the default out-of-the-box Material widgets. For this interaction, in particular, either the slider needs to be massively bigger so you can hit the 0% and 100% targets with 100% reliability (and not end up at 4% or something), or it needs buttons. (Even using a binary switch and a slider doesn't really do the same thing because most Z-wave switches don't go to 100% with a binary switch, they go to the last level, so its really about going to the min or max on the slider item, not ON/OFF of a switch item.)

[mueller-ma]

Hey @dotorg,
the suggestion on the screenshot in the first post was implemented by me, but rejected.
However if you want to work on this, please have a look at https://github.com/openhab/openhab-android/issues/550#issuecomment-377672560 (3. is https://github.com/openhab/openhab-android/pull/1052).
The "full row click" action for sliders without switchSupport can be setting the slider to 0 or 100, depending on the current state.

[dotorg]

I don't think that plan makes any sense. While some items should absolutely support bigger tap-targets (like tap to toggle a Switch control), that's a bad UX for a slider, because a mid-position slider -- do you go up, or do you go down? If the behavior isn't obvious, its a bad user interface. It should be a max/min, or on/off discrete buttons.

I'd rather pull your patches and tweak it or re-implement them, even if the official stance is weird. Pretty much everything that comes off the sitemap architecture on OH is a bit of a UX train-wreck -- clearly something designed by developers to fit an existing architecture, not interaction experts --, but there's no reason to keep making it worse.

I need to do something to fix the Setpoint control, which is also incorrect in the Android app, anyway.

[kvolden]

I don't think that plan makes any sense. While some items should absolutely support bigger tap-targets (like tap to toggle a Switch control), that's a bad UX for a slider, because a mid-position slider -- do you go up, or do you go down? If the behavior isn't obvious, its a bad user interface. It should be a max/min, or on/off discrete buttons.

For the case where switchSupport is enabled, it makes perfect sense. As I've said before, if it's OFF (0), then turn it ON. If it's ON (>0), then turn it OFF. If it's not already clear, read my previous comments for the distinction between ON and 100%.

For the case where switchSupport is disabled, if "full row click" should still be active (I don't have strong opinions on whether it should), it would make the most sense to act similarly but with ON being 100%. In other words, if it's OFF (0), turn it ON (100%), and if it's ON (>0) turn it OFF.

[voipmonitor]

I have smart home freeathome and there is dimmer which supports ON and OFF alongside with setting 0-100% for the light. If you turn off the light and turn it on again it remembers the last dim position. Thus having only the slider is not an option if you want to set it to 50% and then just use ON / OFF for turning the light. Currently the only option for me is to have two items in sitemap - switch and dimm which consumes so much space and its also confusing. Having switch ON/OFF + Slider as one item will solve this issue - do I understand that the proposel in first comment here was denied?

[maniac103]

do I understand that the proposel in first comment here was denied?

No, it wasn't. The functionality was implemented in recent beta versions; if you click on the row (next to the slider) the toggle will be triggered.

[voipmonitor]

do I understand that the proposel in first comment here was denied?

No, it wasn't. The functionality was implemented in recent beta versions; if you click on the row (next to the slider) the toggle will be triggered.

when I click on it in android app it toggles to 0 or 100 but it does not switch the light - how I can debug this or report this? Or do I have to specifically configure it in items?

[maniac103]

Or do I have to specifically configure it in items?

Not in item, but in sitemap. You need to add the switchSupport keyword to your slider item.

[voipmonitor]

Or do I have to specifically configure it in items?

Not in item, but in sitemap. You need to add the switchSupport keyword to your slider item.

my items:

Dimmer Light_OB_barS "Bar" (OB_Kuchyn) ["Light", "Lighting"] {channel="freeathome:dimmer:ABB700C84689_ch0002:dimmer_value"}
Switch Light_OB_barD "Bar" (OB_Kuchyn) ["Light", "Lighting"] {channel="freeathome:dimmer:ABB700C84689_ch0002:dimmer_switch"}

my sitemap has this:
Slider item=Light_OB_barS label="Bar" switchSupport

The slider normally works but if I click on row the slider went to 0 or 100 but it does not change the light state. Maybe the channel does not support ON / OFF commands in the freeathome bindings? And if not is there any workaround?

[mueller-ma]

Can you look at the openHAB server event.log? It should say something like "Light_OB_barS received ON".

[voipmonitor]

Can you look at the openHAB server event.log? It should say something like "Light_OB_barS received ON".

I have changed the items to:

Dimmer Light_OB_barD "Bar" (OB_Kuchyn) ["Light", "Lighting"] {channel="freeathome:dimmer:ABB700C84689_ch0002:dimmer_value"}
Switch Light_OB_barS "Bar" (OB_Kuchyn) ["Light", "Lighting"] {channel="freeathome:dimmer:ABB700C84689_ch0002:dimmer_switch"}

When I press the slicer row - this happenes in the log:

2019-06-06 15:05:54.701 [ome.event.ItemCommandEvent] - Item 'Light_OB_barD' received command ON
2019-06-06 15:05:54.766 [nt.ItemStatePredictedEvent] - Light_OB_barD predicted to become ON
2019-06-06 15:05:54.918 [vent.ItemStateChangedEvent] - Light_OB_barD changed from 0 to 100

But the light itself is doing nothing - which means that the channel "freeathome:dimmer:ABB700C84689_ch0002:dimmer_value" does not support ON or OFF? Can this be remapped somehow in case the binding is not supporting ON/OFF on the dimmer_value channel?

[mueller-ma]

2019-06-06 15:05:54.766 [nt.ItemStatePredictedEvent] - Light_OB_barD predicted to become ON 2019-06-06 15:05:54.918 [vent.ItemStateChangedEvent] - Light_OB_barD changed from 0 to 100
This sounds to me that the Item Light_OB_barD cannot switched "ON". I guess it's better if you open an issue in the bindings repo.