Displaying states and commands of a Selection item on a sitemap

Hi,

I want to show a an item in a sitemap with a Selection item and see its real-time states but only the commands available.

For example, for a garage gate, states are OPEN, CLOSED, OPENING, CLOSING but the relevant states to show in the Selection item of the sitemap are OPEN and CLOSED only.

To see the OPENING and CLOSING states for the Selection, I must add them to the mapping (which makes no sense because you don’t command a door to CLOSING). If you don’t put them in the mapping, the transitional states are not shown.

Is there a way to display the current state in the label (I could could by having different icons for each state but it is quite constraining) without having them in the mapping?

For the moment, my workaround is to have 2 items and handle this with visibility setting

Selection item=itemDoor label="My door [MAP(fr.map):%s]" mappings=[ 0="CLOSED", 100="OPEN" ] visibility=[itemDoor==0, itemDoor==100]
Text item=itemDoor label="My door [MAP(fr_amr.map):%s]" visibility=[itemDoor==10, itemDoor==90]

with .map

0=CLOSED
10=OPENING
90=CLOSING
100=CLOSED

But the problem is that you cannot send a command to the door until it is in a non-transitional state (as the Selection is hidden and only the Text visible).

Any suggestion?

like so?

Switch item=itemDoor label="My door [MAP(fr.map):%s]" mappings=[ 0="CLOSE", 100="OPEN" ]

That’s it but with a Selection item: I use your proposal for simple commands.

When you have critical commands (like launching a nuclear bomb :rofl:), better is to have them in a Selection so the user has to click twice (1 to open the dropdown, 1 to select the value) to execute the command and avoid triggering it by mistake

Had a play … I see your problem.
I did not realize the Selection widget actively suppressed the usual state display (e.g. the [%s] in a label) and substitutes the mappings=., so if it isn’t in the list, no display.

Demo
using a real Item of mine, switchable by “pushbutton”

Switch item=test_Alarmmode mappings=[0="Fault",1="Disarm",2="Part",3="Arm",4="Ring"]
Selection item=test_Alarmmode label="mode [MAP(alarms.map):intruder%s]" mappings=[0="Fault",2="Part",4="Ring"]

with values switched to 0, 2, 4, the Selection widget displays state before clicking for a drop down. With values 1 and 3 it does not.
It’s consistent across BasicUI and ClassicUI, so seems to be by design. I cannot see why that would be wanted though.

As it happens, the Item is a Number type with a MAP in the Item label to text message.
Interestingly that doesn’t work in a Selection widget either, which really does seem to be a bug. e.g. my MAP should show “Ringing!” not “Ring”.

I’ll have more of a look at this, with a view to lodging a Github issue.

That doesn’t help you though. I cannot think of any other alternatives.

Thank you for taking the time to test. If it can be fixed in the future, that’s fine.
In the meanwhile, it will push me to work harder to switch to HABPanel (I am still working on the spectifications and features expected for my HABPanels…)

Set up a test / demo, switch to demo various states

Item

Number testDemo "Demo Alarm [MAP(demo.map):%s]"

demo.map

0=fault
1=disarmed
2=reset
3=armed
4=Ringing

sitemap

Switch item=testDemo label="Simulation []" mappings=[0="Fault",1="Disarm",2="Reset",3="Arm",4="Ring"]
Text item=testDemo label="raw state [%s]"
Text item=testDemo label="MAPped state"
Selection item=testDemo mappings=[1="Disarm",2="Reset",3="Arm"]
Selection item=testDemo label="force raw state [%s]" mappings=[1="Disarm",2="Reset",3="Arm"]
Selection item=testDemo label="suppress state []" mappings=[1="Disarm",2="Reset",3="Arm"]

Results; only matches from mappings are displayed for Item state.
MAP is ignored, only text from mappings is used.
No match, no display.
Empty format in “label []” normally suppresses state display, does not work in BasicUI (this part does work in ClassicUI)
I do not know the behaviour, good or bad, in the “app” UIs

classicdemo1 classicdemo2

Opened a Githib issue

This has apparently been fixed for BasicUI and ClassicUI. It may have made it into release 2.5.5, or might be in 2.5.6 if it comes.

No-one appears to have tried this out for Android or iOS apps, situation unknown.
@mueller-ma just for info