Time to revert state of an `autoupdate="false"` Switch item, if server does not update state, should be configurable

[dilyanpalauzov]

For a Switch item a without mappings=[] with autoupdate="false’ openHAB-Android 3.20.4-beta can toggle it temporarily, if openHAB-Android does not timely change the state of the item, then the state of the toggle in the sitemap on Android is reverted, and afterwards once openHAB-Android changes the state, openHAB-Android toggles once again. This results three visual togglings of the switch instead of one.

To avoid this, the time, which openHAB-Android waits before reverting the state of the toggle, if openHAB does not change the state of the item, should be configurable.

[maniac103]

What should this suggested option be named? 'Time until permanent lack of item change is assumed after sending a command' or something like that? (Because that's what it actually is)
I don't think adding an option for this is a good idea, because it would be a very confusing option (try explaining it to a layman user) that just fixes a small aesthetical issue in a very niche corner case.

[dilyanpalauzov]

What should this suggested option be named? 'Time until permanent lack of item change is assumed after sending a command'

Yes. Ideally it should be described somewhere how the application handles autoupdate="false" and on this place the option mentioned.

[dilyanpalauzov]

For Switch items with autoupdate="false", the functionality in openHAB-Android is implemented correctly, when the sitemap has mappings=[…]. That is, clicking the item triggers a command, and the state in the UI is updated only after (openHAB server sends command to the device, the device reports changed state to openHAB, and finally) openHAB updates the state.

It would be good, if the same can be achieved for Switch item without mappings=[…]. E.g. rendering the item, as if it has an implicit mappins=[ON=ON, OFF=OFF] (and some hacks for NULL and UNDEF), if the sitemap does not explicitly provide a mappings=[…]. In this case there will be no notion of “timeout” / “Time until permanent lack of item change is assumed after sending a command” and there will be no need for configuring the timeout.

The implication would be, that clicking a toggle does not visually enact the toggle immediately. But this is how it works anyway now for MainUI; (I guess) iOS; and in oh-Android Switch items with mappings=[…].

I do not understand Android programming. But in all decent APIs it should be possible when the user clicks on something, to intercept the click event and prevent the default action to happen. In this case intercepting the event would mean to trigger state update, send command, without changing the state of the UI. The UI changes, once the server reports a change (which now it does anyway.)

[dilyanpalauzov]

I found https://developer.android.com/reference/android/widget/Switch#onTouchEvent(android.view.MotionEvent), which might not be relevant, as I have no understanding of Android APIs:

If this method is used to detect click actions, it is recommended that the actions be performed by implementing and calling performClick(). This will ensure consistent system behavior, including:

So implementing autoupdate="false’ (and autoupdate="true") would be a matter of overriding onTouchEvent() and not calling performClick() from the overridden method.

[maniac103]

implementing autoupdate="false’ (and autoupdate="true") would be a matter of overriding onTouchEvent() and not calling performClick() from the overridden method

Which yields a compiler warning, because omitting performClick e.g. causes accessibility issues, as there's no way for a narrator to determine when the user successfully toggled the switch anymore.

Additionally you'd lose any UI feedback. If the binding needs 5 seconds to apply the change, you'd touch the switch, nothing happens for 5 seconds (and you'd start asking yourself whether you actually triggered the switch), then all of a sudden the switch would move. IMHO the UX of the current solution, including the multiple animations, is better than that.

[dilyanpalauzov]

If the device linked to the item in openHAB is unresponsive - has disconnected for some reason - my expectation is that a switch in the UI will also be unresponsive. Thus if clicking does not change the state of the device, for any reason, the click-toggle should not move.

For users with autoupdate="true"in fact nothing would change: they click on a switch, openHAB immediately reports that the state of the switch was altered - even when the device linked to the item is disconnected - and then the UI would nearly instantly also alter the toggle.

Users, who have set autoupdate="false’, have their reasons to do so, and they might also have different expectations, compared to autoupdate="true"items.

[maniac103]

If the device linked to the item in openHAB is unresponsive - has disconnected for some reason - my expectation is that a switch in the UI will also be unresponsive. Thus if clicking does not change the state of the device, for any reason, the click-toggle should not move.

Okay, let's take the mentioned implementation issues (like accessibility) aside for a moment. You've described how you'd envision this to work for a switch. What about a slider or color light?

[dilyanpalauzov]

To collect more opinions, I opened at https://community.openhab.org/t/how-should-ui-implement-autoupdate-false-for-switch/169847 a discussion how should toggles with autoupdate=false be implemented in the UIs of openHAB.

To the extend I tried it, in the case of OH-Android the Switch with mappings=[…] for autoupdate=false already does not update, if it is clicked and the device is offline; it already does not show instant feedback, if the device is slow; and insofar nobody has complained about this. So I do not understand why is the same not applied also for Switch without mappings=[…] - the UI does not indicate that change command is received, until the linked device updates its state.

I have no opinon about Slider or Color light. This thread is about Switch without mappings=[…], as for Switch with mappings=[…] there I see no problem.

[maniac103]

We (as in: the app maintainers) need to think of the bigger picture though, to not create solutions for particular problems that make the overall behavior more confusing...which is the case for 'Why do switches not update immediately, while sliders do?'. As for the switch-with-mappings case, that one should probably be updated to match the regular switch, I agree that the inconsistency does not make sense.

[dilyanpalauzov]

Additionally you'd lose any UI feedback. If the binding needs 5 seconds to apply the change, you'd touch the switch, nothing happens for 5 seconds (and you'd start asking yourself whether you actually triggered the switch), then all of a sudden the switch would move.

UI Feedback can be provided by different means:

In sitemaps under OH-Android currently, when a line with an item (e.g. as Text element) is touched, the colour of the line changes for short time. Likewise for lines with Switch containing exactly two mappings=[…], one of which is selected. Touching a line, containing a toggle, both changes the colour of the line and switches the toggle. Touching only the toggle on the same line, switches the toggle, without changing the colour of the line.

Instead of switching the toggle to provide feedback that the command was accepted, only the colour of the line can be changed, leaving the state of the toggle unchanged.

Feedback for received command can be provided also as vibration.

https://community.openhab.org/t/how-should-ui-implement-autoupdate-false-for-switch/169847/3 contains a different suggestion with drafted UI: show the last sent command and the current state at distinct places.

[maniac103]

Okay, but again:

What about a slider or color light?

Personally I value consistency in behavior mich (read: much) higher than perfectionism in a specific corner case. At least I am not going to work in changing behavior to something that doesn't have at least a solid plan for consistent behavior across all widgets.
I'm not opposed to changing behavior. I'm just opposed to change it solely for switches.

[dilyanpalauzov]

For autoupdate=false and Slider elements: When the last sent command for a Silder differs from the current state of the linked item (e.g. for more than a second), the slider can show two numbers: last sent command and current state.

I do not use sliders and colour light in sitemaps. Users of colour light with autoupdate=false can suggest how this should be handled, to get its behaviour consistent to the other elements with autoupdate:false. There might be no users, who use autoupdate=false for light colour in sitemaps on Android.

[dilyanpalauzov]

I would like to share my conclusion here for all types of elements:

When the last sent command differs from the state of the item, for longer that certain time like 1s, the UI should show both last sent command and current state of the item.

[rkoshak]

When the last sent command differs from the state of the item, for longer that certain time like 1s, the UI should show both last sent command and current state of the item.

Commands and states to not always match. Consider a Dimmer Item. You can send INCREASE and DECREASE as a command. The command will never match the state of the Item. If you send an INCREASE command to a Dimmer that is already 100, nothing changes even if the Item is responsive. Same goes for DECREASE and 0. Dimmer can also be commanded with ON and OFF. The state will never match these commands. Color Items can also recieve these commands plus a PercentType command.