No I’ve never tried it, because I was completly satisfied with the 2.7 0 bug.
They are read-only Switches.
When motion or tamper were detected, the Switches automatically turned to ON and you could read left beside the text: Alarm
After 30 sec (it’s setable in Thing config) the Switch state automatically reverted to OFF and you could see left beside a text: OK
See picture.
Bear in mind that display of Alarm/OK textual state was already using the channel options 
I’ll stir up a terrible old hornets nest now and say that binary input-only channels like alarm/ok should really be linked to Contact type Items anyways, and not command-accepting Switch types 
If they have the toggle they are not read only. you can go in there and turn that first element OFF and Tamper2 ON manually. If you want a read only Switch, you must use a Text Item to display it on the sitemap.
At best it’s a “don’t touch that toggle” Switch.
There’s many ways to present these, the grizzle is about the default presentation.
They are read-only from the device’s view. YES, you can toggle them. But it changes only the state of the item but not the device itself. I used this for years. And now it’s wrong?
Btw the definition comes from the channels, see e.g. here like Chris told.
Noone complains about this for years.
IMHO, displaying a read only Item with an interactive UI element is indeed wrong. How long you’ve done this is irrelevant. It was wrong from the start and it continues to be wrong. If you shouldn’t interact with it or interacting with it doesn’t do anything than basic human factors engineering says there should not be an interactive UI element (i.e. the toggle).
Hence the reason why both rossko57 and I hate to see read only binary sensors represented as a Switch.
And I would argue that Chris, or more likely whom ever added the device to the Zwave database, were in error by using a Switch instead of a Contact in this case.
Many users have complained about this over the years
This was Chris’ own example. I could find you many examples in the database if you like…
The above motion sensor has the following channels:
And above smoke sensor has the following channels:
It was not my idea to declare them as Switch, and they were rendered correctly in my opinion.
I’m not blaming you.
But in my opinion, they never should have been Switches and they are rendered incorrectly. You should never have interactive elements on a UI that don’t do anything. That’s basic human factors engineering 101 level stuff.
If you want to display them incorrectly, that is your business. But by default, OH should display them correctly. You should have to go out of your way to do things wrong, not the other way around.
Since I have not been able to find any other serious bugs in version 2.7.0 except that it does what others think that it is wrong, I’ll choose to do it wrong. I’ll keep 2.7.0. 
That’s fine. You are still using the ‘discovered’, or in this case the device-specific, default options - to get the text and the icon.
There should be some feature that would enable you to display a slide-switch widget, and that is missing. There is an issue raised to fix that, not clear yet if that will require changes to core and/or any/all of the UI’s.
This won’t ever work together with choosing to use Group in sitemap - just like any other customization of sitemap.
The whole separate business of Switch v Contact has a long and horrible history and isn’t likely to be changed anytime soon, as a breaking change. The way that all works could be different in OH3.
Ok. Thanks a lot. And how do I do that? I only see 2.8.18-beta in Google Play Store. The newest version is 2.8.21-beta (on Github), but not as an .apk file.
EDIT: Now I found the APK there. 
