[SOLVED] e.g. Z-Wave: Switch items are now (v2.8.0) rendered as "Default items"

Tags: #<Tag:0x00007f745969eae0> #<Tag:0x00007f745969e838>

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 :slight_smile:

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 https://github.com/openhab/openhab-android/issues/1281 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: https://github.com/openhab/openhab-android/releases

2 Likes

@mueller-ma

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 :slight_smile:

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.