Yes, it does!
Btw, what is so awful that now the Switch is no longer displayed?
The rendering has been made coherent with Basic UI, meaning it does now consider channel options in a similar way as static mappings. It was a feature missing in Android App.
Please try with Basic UI, normally it should be the same.
2 Likes
Thanks 
I never used Basic UI, sorry. Thatâs why it did not recognized the new behavior before.
That is the recommended UI for OH 2.
The old behavior of the app wasnât the âcorrectâ one. Please see Switch widget with dynamic options · Issue #1281 · openhab/openhab-android · GitHub for the bug report.
I try to keep the release notes in the Play Store as short and understandable as possible. If you want a more detailed changelog, you can read the changelogs of the beta builds between two stable releases: Releases · openhab/openhab-android · GitHub
2 Likes
OK. Thank you for the explanation. But the buggy version had made things much easier for me, so far. Now, you have to configure each item with mappings in .sitemap file. Is there a way, to set the behavior as a parameter in a next version?
I understand that itâs frustrating for you now, since the âcorrectâ way seems buggy to you. But adding a preference for this isnât the way to âfixâ this. Android guidelines say that less preferences are more
1 Like
The real good question is why options are defined by a binding for a switch channel? Options are more intended for String channels I think.
1 Like
I would be curious to check how many bindings are doing that (switch channel with options) but after a first quick search in OH2 repo, I find 203 XML files with the tag âoptionsâ. That would take too much time time to check them all manually.
1 Like
Because people expect âthe systemâ to display intelligence. The binding in this case knows the binary channel represents e.g a battery alarm condition. Itâs smarter to automatically offer an interpretation of itâs state as Alarm/OK than on/off. Itâs a natural evolution of discovery techniques.
1 Like
Seriously, what looks better?
new:
old:
new:
old:
Why itâs written twice?
In case of Alarm you would see:
Alarm OK Alarm
If itâs OK:
OK OK Alarm
There also is a problem with the width, now.
I finally take the time to control all bindings in OH2 repo that define static options for channels. I found only 4 bindings that do that for a switch channel: toon, bigassfan, minecraft and nuki.
For the toon binding, that is fully weird, whatr is the interest to do that ?
<channel-type id="heating" advanced="true">
<item-type>Switch</item-type>
<label>Heating</label>
<description>Indicates if the boiler is burning</description>
<category>fire</category>
<state readOnly="true">
<options>
<option value="ON">On</option>
<option value="OFF">Off</option>
</options>
</state>
</channel-type>
All other bindings generally define options for string or number channels.
1 Like
As already mentioned, you can probably (I have not tested) disable this behavior by setting a null mappings on the switch widget in your sitemap.
But yes, for groups, this is not possible as it is using the default switch widget.
This would require a change of this default switch widget. Maybe very easy to change.
I just took a quick look to the code of Basic UI and the workaround with ``Switch item=myItem mappings=[]``` will not work. If some state options exist and are less or equal to 4, they will be displayed as buttons.
Thatâs what you get by default; a display of state in text, and here presumably thatâs auto-mapped, and a display of widget, which here is âlight upâ buttons with text labels.
Iâll bet if you set "some label []" it will suppress the state display, or "some label [%s]" to display the naked ON/OFF state.
Thatâs really disappointing, can anyone verify in a real UI? I think all the sitemap UIs need to be checked here.
I cannot think of another way to suppress default mappings.
Yes, it is.
I think an extension of the sitemap syntax would be required to let the user decide if he wants to ignore state options or to render them as buttons. And we could then decide what should be the default. Of course, this will require a little change in any UI that are already considering the state options to render switch widgets (probably only Basic UI, Classic UI and Android app).
1 Like
I opened an enhancement.
1 Like
Did you try using Text widgets? Switches seem to be the wrong element here, except a human appears in your floor, when you switch âBewegungâ (Movement) on.