Yes that’s true BUT the item states won’t show correctly in HabPanel as I said above because of how it derives the correct representation of an item’s state.
Thanks for your help on this btw 
1 Like
Sorry, I was referring to the small widget scratchpad directly in the developer sidebar
I have no idea if you can access the displayState in DSL.
I missed this the first time. So, the displayState isn’t useful for you. Is the item a switch/contact or is it already a string item? I have noticed that there are areas where OH3 seems to be more strict about state types. So it is possible that some sort of loose typing that worked in OH2 might not work in OH3.
If your item is not a string type already then try setting the item’s type to string and see if that then allows it to accept the arbitrary values returned by the map transform.
no worries, all this syntax fiddling is maddening anyway… I keep thinking…it’s the 21st century and we’re fiddling with syntax instead of clicking some check boxes etc…
My rain sensor is a genuine CONTACT item and reports the states of OPEN/CLOSED.
I’ll try your suggestion so.
Hi, tried making the item string type but still no joy.
Reverted the item back to a contact type. Summary below;
Summary: The Basic Sitemap UI of OH3, as derived from the old OH2 sitemap, DOES see the State Description MAP file and displays dry/rain as appropriate.
The new OH3 UI card does NOT see the effect of the MAP transform
HabPanel does NOT see the effect either.
Both Basic UI sitemap and OH3 Card DO see the effect if it’s typed into the OPTIONS window.
HabPanel NEVER sees the transform no matter what is tried.
You have to choose in HABpanel widgets to use the raw Item state or the formatted/transformed state - I’m guessing as specified in old-fashioned OH2 [state presentation] way.
Hi Ross,
Choosing the ‘server’ supplied state in the widget:
Not choosing the ‘server’ state:
I should be getting DRY or RAIN. All this did work in OH2. This fiddling is very trying… 
What we identified above is that channels without Options works to MAP in UI
{
"link": "http://openhab:8080/rest/items/Kitchen_Door_State",
"state": "CLOSED",
"transformedState": "Stängd",
"stateDescription": {
"pattern": "MAP(se.map):%s",
"readOnly": true,
"options": []
},
"editable": false,
"type": "Contact",
"name": "Kitchen_Door_State",
"label": "Altandörr Kök",
"category": "door",
"tags": [
"OpenState"
],
"groupNames": [
"geKitchen_Door",
"gcDoors",
"gpCR"
]
}
and channels with Options we have problem with
{
"link": "http://openhab:8080/rest/items/Garage_Gate_Contact",
"state": "CLOSED",
"transformedState": "Stängd",
"stateDescription": {
"pattern": "MAP(se.map):%s",
"readOnly": true,
"options": [
{
"value": "OPEN",
"label": "Open"
},
{
"value": "CLOSED",
"label": "Closed"
}
]
},
"commandDescription": {
"commandOptions": [
{
"command": "OPEN",
"label": "Open"
},
{
"command": "CLOSED",
"label": "Closed"
}
]
},
"editable": false,
"type": "Contact",
"name": "Garage_Gate_Contact",
"label": "Garageport",
"category": "garagedoor",
"tags": [
"OpenState"
],
"groupNames": [
"geGarage_Gate",
"gcDoors",
"gpCR"
]
}
In Habpanel the mapping works as earlier i think
Do you write the pattern as in post 6 ?
Sure.
If BasicUI can show the transformed state, so can HABpanel, it’s just a case of fixing the widget somehow - but I don’t know HABpanel.
Hi all,
I seem to have found a workaround. I put the MAP(file.map):%s reference into the Pattern window AND I also type the raw transformation couplets into the Options window.
Now ALL the UI’s, including HabPanel can see the correct transformations 
1 Like
If you used the “Options”-field once, it stays in the JSON foreveer; even if you delete everything in this field. It is still interpreted as “nothing” and overwrites a MAP. So go to the JSON-View, delete the option-field manually and openhab will use your MAP-File 
Would be a nice bugfix, if the UI deletes the options-field if the content in the field is empty.
2 Likes
Open the code tab and delete the options entry that way.
I did that just wanted to share how to fix this.
Hi, I also got the same issue. Unfortunatelly it doesn’t work in my case. Meaning, only options have any effect on state label. But in my case it’s connected with Automower (lawn mower) binding, that provides already state as options: openhab-addons/thing-types.xml at main · openhab/openhab-addons · GitHub
Can you explain a bit more what you’re trying to do? Guessing you would like to use a MAP, say to translate, but UI ignores that and uses options that you can’t get rid of because the channel/binding supplies them?
I have to say there is something badly thought out here. I’ve often wondered what happens if you had an Item linked to two channels with conflicting options. Wouldn’t matter, if you could manually override.
That seems to be the root of the issue to me.
In sitemap UIs, user-defined state presentation had precedence over system supplied options.
MainUI takes the opposite stance - “openHAB knows best”?
Hi guys, @tnemrap, I also ran into this issue today. Just want to confirm whether you already reported this as a bug on github. Couldn’t find an entry there.
I opened an issue on github for this “inconvenience”:
All
I too am trying to convert ‘Closed’ to CLOSED, on a Zwave Contact item. I put under Transform, my door.map which has the correct transformations but this does not change the item state formatting.
Is this a bug? How can I achieve this because the documentation makes no reference to doing state transformations unless you use Items files which I do not
Thanks
It should be fixed in the milestones I think. You need to add a State Description metadata to the Item and put your mapping there. That should override the state description provided by the binding.
1 Like
Thanks Rich! Thats fixed it ! State Description metadata did the trick!