No, you can just use one Mapping and, in this case, when you press the button it will send the ON command to the Item. I use this for my garage door openers as the control mimics a momentary push button.
@andreas_furrer68, honestly, I’ve noticed this behavior for about as long as I’ve been using OH. I never gave it much attention as it never was a problem for me. But an Issue should probably be filed.
It used to work like you expected in the old version of the Ios App. You could use a switch item and show it as a single mapped button that would be shown as on if the switch had the mapped state. But one of the app developers told me that that actually was the bug.
Johannes
You are right… I just updated my iOS version and now it changed the behaviour…
I can‘t understand why…
Yep I also used the supposed ‘bug’ as a feature in my sitemap 
I also think it is more clearly for informing about an active state of some things…
It has nothing to do with autoupdate
I think the misunderstanding is that weren’t expecting the button to turn off when we pressed it again. So not like a momentary push button. Instead we were expecting the button the to behave just the same with one mapping as with 2 or 10 mappings. Meaning it is highlighted when the corresponding item is in the state that the button in the sitemap is mapped to. I don’t understand why it should behave differently when there is one mapping versus 2 or more. Which is how the Ios App used to behave. Now it’s kind of counter intuitive when a mapping gets highlighted to the corresponding item state but only for 2 or more mappings but the behavior with a single mapping is inconsistenct.
Johannes
Yes, this is also my oppinion.
The use a switch without mapping, simple as that.
We had the discussion before. There is several use cases were one has a switch item that only ever gets switched to one state in the ui by the user and there is no point in switching it off as it either switches itself off or gets switched when another item gets switched through a rule or nothing happens at all. So there is a point in having the possibility to have a button In a ui that is kind of one way and only gives the possibility to switch something to one state but not manually to another. But the user might want to know if it is still switched to the mapped state or if it changed state. So yes there is use cases where you don’t want to show a two way switch although the underlying item has multiple states. I would have thought that use cases like this ard what mappings are for. And I come back to my consistency argument as it just isn’t the expected highlight behavior if you use mappings otherwise.
Johannes
I understand your intention, but the underlying UI element does not work that way.
To achieve what you want, you will have to use the visibility attribute. Just make two switches with one mapping, switch visibility depending on item state and ignore interaction for one of them.
But this will still not show me a single button that is off/not highlighted when the item is not in the mapped state and than as long as the item is in the mapped state show me a button that is on/highlighted.
Independently of where the state change came from, eg rule or ui, and when you press it triggers a change to the mapped state. Because that’s exactly how it behaved before.
Can you please post an example Sitemap code for your two switch visibility solution that achieves this, because I don’t quite understand it?
If you look at the first post in this thread you see that android app too behaved in our expected way.
Anybody knows, how a number item with one mapping is behaving?
Set it up in your sitemap like this:
Switch item=SomeItem icon="light" mappings=[ON="Turn ON"] visibility=[SomeItem=="OFF"]
Switch item=SomeItem icon="light" mappings=[ON="Light is ON"] visibility=[SomeItem=="ON"]
Okay, I tried a version with visibility. Here is my new sitemap definition:
Switch item=EMD_07_05 label="SWITCH V1"
Switch item=EMD_07_05 label="SWITCH V2 []" mappings=[OFF="Off",ON="On"]
Switch item=EMD_07_05 label="SWITCH V3 []" mappings=[ON="On"]
Switch item=EMD_07_05 label="SWITCH V4 []" mappings=[ON="OFF"] visibility=[EMD_07_05=="OFF"]
Switch item=EMD_07_05 label="SWITCH V4 []" mappings=[ON="ON"] visibility=[EMD_07_05=="ON"]
And here is how it looks in the BasicUI:
If the switch is ON the representation is still wrong, because the color is wrong. So it changes nothing…
Now I made some tests with a numeric item:
Switch item=Chart_Period label="Chart period" mappings=[0="1 T"]
Switch item=Chart_Period label="Chart period" mappings=[ 1="3 T"]
Switch item=Chart_Period label="Chart period" mappings=[0="1 T", 1="3 T"]
Switch item=Chart_Period label="Chart period" mappings=[0="1 T", 1="3 T", 2="1 W"]
Switch item=Chart_Period label="Chart period" mappings=[ 1="3 T", 2="1 W"]
The result for values 0,1,2 are as follows:
This is also not working as it should…
I know what you want to do with your Sitemap code. You are mapping states to the actual mapping string using two items. But this is a rather ugly workaround which is neither in line how other mappings represent their state, eg colour highlighting, nor does it offer the quick glance comfort that a coloured highlight representation does. Explain to me how the new behaviour makes mappings more consistent within themselves? Why is it logical when mapping always works one way and than out of no where it changes it’s behaviour for one case. I can’t see how this is intuitive ui design.
Maybe the basic ui was the one with the bug not showing the mapping state correct and the android and iOS app where the ones doing it right for years?
Just a thought.
Edit:
I know you mentioned this issue in the context:
I actually see this user trying to use a switch as a pushbutton going against the idea of a switch item. Because a switch item is supposed to remain in its state as long as we don’t change again to its other state. That’s how openhab switch items work. Why not represent them as such even if the mapping hides one of the states, because that’s all we are trying to do. You even say it yourself in the github thread.
I’m sorry for being so stubborn on this issue 
And the example with the numer item shows, it is possible to suppress some states.
So I can’ t see, why I can supress a third, fourth… state, but not a second.
For my, this is a bug not a feature.
Can you please point me at the part of the code on github that deals with this/mapping in the ios app?
