Wait, if you are defining the Items in .items files then you need to define the State Description Item metadata in the .items files too. As has always been the case, when your .items file gets unloaded, the Item gets deleted including the Item metadata I think. So you’ve lost that State Description metadata.
You can confirm this by looking at the State Description metadata in the UI again to see if it’s gone. If it’s not gone then something else is going on.
Oh yes, of course, it’s no good editing Item properties in the UI if you have defined them from file.
Does MainUI need an enhancement to stop that?
I think you can view an Item’s internal JSON by looking at it in MainUI and clicking “code”? Get a view like you can in REST API. What is going in the state presentation section is the interest.
Well, my understanding of the behavior is from 2.5. I don’t know if that changed in 3.0 which is why I asked for the confirmation. It may be the case that the metadata sticks around even after the Item is deleted and then gets reassociated with the Item when it’s recreated during the .items file load.
Items are sadly the only place in MainUI that doesn’t have a code. And even if it did, it wouldn’t help with the metadata because the metadata is stored separately. To make it even worse, there is no way to query for all of the metadata on a given Item. You have to know the namespace for the metadata first. So even if there were a code view, it wouldn’t show the Links (which are also stored separately) nor the metadata and it’s the metadata that we are really interested in here.
The REST API could be used as you can pass in the namespace as part of the query for an Item, and it will return that one namespace’s metadata. But we can also just look in the State Description section of the Item’s page in MainUI which will be easier.
Why is it then working for some bindings with this items files but not for zwave?
I have the same problem with Items (defined in the UI) where the binding provides state options and I have a MAP-transformation with different values. When querying the Item through the API explorer I get this:
{
"link": "https://openhab.alfredsson.info/rest/items/SMHI_Hour0_Wsymb",
"state": "3",
"transformedState": "Växlande molnighet",
"stateDescription": {
"pattern": "MAP(smhi_wsymb2.map):%s",
"readOnly": true,
"options": [
{
"value": "1",
"label": "Clear sky"
},
{
"value": "2",
"label": "Nearly clear sky"
},
{
"value": "3",
"label": "Variable cloudiness"
},
{
"value": "4",
"label": "Halfclear sky"
},
{
"value": "5",
"label": "Cloudy sky"
},
{
"value": "6",
"label": "Overcast"
},
{
"value": "7",
"label": "Fog"
},
{
"value": "8",
"label": "Light rain showers"
},
{
"value": "9",
"label": "Moderate rain showers"
},
{
"value": "10",
"label": "Heavy rain showers"
},
{
"value": "11",
"label": "Thunderstorm"
},
{
"value": "12",
"label": "Light sleet showers"
},
{
"value": "13",
"label": "Moderate sleet showers"
},
{
"value": "14",
"label": "Heavy sleet showers"
},
{
"value": "15",
"label": "Light snow showers"
},
{
"value": "16",
"label": "Moderate snow showers"
},
{
"value": "17",
"label": "Heavy snow showers"
},
{
"value": "18",
"label": "Light rain"
},
{
"value": "19",
"label": "Moderate rain"
},
{
"value": "20",
"label": "Heavy rain"
},
{
"value": "21",
"label": "Thunder"
},
{
"value": "22",
"label": "Light sleet"
},
{
"value": "23",
"label": "Moderate sleet"
},
{
"value": "24",
"label": "Heavy sleet"
},
{
"value": "25",
"label": "Light snowfall"
},
{
"value": "26",
"label": "Moderate snowfall"
},
{
"value": "27",
"label": "Heavy snowfall"
}
]
},
"commandDescription": {
"commandOptions": [
{
"command": "1",
"label": "Clear sky"
},
{
"command": "2",
"label": "Nearly clear sky"
},
{
"command": "3",
"label": "Variable cloudiness"
},
{
"command": "4",
"label": "Halfclear sky"
},
{
"command": "5",
"label": "Cloudy sky"
},
{
"command": "6",
"label": "Overcast"
},
{
"command": "7",
"label": "Fog"
},
{
"command": "8",
"label": "Light rain showers"
},
{
"command": "9",
"label": "Moderate rain showers"
},
{
"command": "10",
"label": "Heavy rain showers"
},
{
"command": "11",
"label": "Thunderstorm"
},
{
"command": "12",
"label": "Light sleet showers"
},
{
"command": "13",
"label": "Moderate sleet showers"
},
{
"command": "14",
"label": "Heavy sleet showers"
},
{
"command": "15",
"label": "Light snow showers"
},
{
"command": "16",
"label": "Moderate snow showers"
},
{
"command": "17",
"label": "Heavy snow showers"
},
{
"command": "18",
"label": "Light rain"
},
{
"command": "19",
"label": "Moderate rain"
},
{
"command": "20",
"label": "Heavy rain"
},
{
"command": "21",
"label": "Thunder"
},
{
"command": "22",
"label": "Light sleet"
},
{
"command": "23",
"label": "Moderate sleet"
},
{
"command": "24",
"label": "Heavy sleet"
},
{
"command": "25",
"label": "Light snowfall"
},
{
"command": "26",
"label": "Moderate snowfall"
},
{
"command": "27",
"label": "Heavy snowfall"
}
]
},
"editable": true,
"type": "Number",
"name": "SMHI_Hour0_Wsymb",
"label": "Väder",
"category": "weather_day",
"tags": [],
"groupNames": [
"Smhi"
]
}
But main UI doesn’t seem to use the transformedState value, it uses the options instead (which come from the binding). When you edit the stateDescription metadata in the UI there is an Options field where you can input key-value pairs like in the .map-files, and this seems to override the binding provided values, but this needs to be set on each item individually which isn’t scalable if you have many Items that use the same transformation.
I have the same problem with Verisure Items,it shows the Option Value in UI not transformed State.
{
"link": "http://openhab:8080/rest/items/Verisure_AlarmStatus",
"state": "DISARMED",
"transformedState": "Olarmat",
"stateDescription": {
"pattern": "MAP(se.map):%s",
"readOnly": false,
"options": [
{
"value": "DISARMED",
"label": "DISARMED"
},
{
"value": "ARMED_HOME",
"label": "ARMED HOME"
},
{
"value": "ARMED_AWAY",
"label": "ARMED AWAY"
}
]
},
"commandDescription": {
"commandOptions": [
{
"command": "DISARMED",
"label": "DISARMED"
},
{
"command": "ARMED_HOME",
"label": "ARMED HOME"
},
{
"command": "ARMED_AWAY",
"label": "ARMED AWAY"
}
]
},
This is also the actual problem with zwave item.
{
"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"
]
}
So we could sum up by saying that BasicUI etc.use the stateDescription/pattern (if given) to override any stateDescription/options provided.
While MainUI does the reverse, gives priority to options.
Have you reloaded those .items files?
We have found the issue look above.
Hi All, it’s more obtuse than that! The Pattern Window of the State Description in the UI DOES accept SCALE transformations but does NOT accept MAP transformations! This doesn’t make any sense and is an OH3 issue.
The SCALE transformations I use for wind speed and wind direction ARE working!
So for example, SCALE(beaufort.scale):%s DOES work in the Pattern window of State Description and items display the correct conversion between wind degrees and Compass points.
MAP(rain.map):%s for my rain sensor to convert closed/open to rain/dry does NOT work in the Pattern window of State Description unless I type the raw map values manually into the OPTIONS window. I can’t get ANY MAP transformations to work unless they’re entered in the options window!
Everything worked perfectly in OH2. One consequence of this is that HabPanel, which derives any State representations from the ITEMS file DOES NOT see these Transformations that are typed into the OPTIONS window. It only sees transformations that are entered in the Pattern Window. So it’s spoiling my HabPanel design.
ps. The weather items are from OpenWeatherForecast service but the rain sensor is a z-wave device…in case this is a clue.
Is this just an item type issue?
Wind item - number type receives number state via the scale transform: OK
Rain item - switch or contact type receives rain/dry state via map transform: ERROR rain/dry not valid states for switch or contact type
Rain item - state description options LOOK like they work in the UI, but they are just changing the displayState of the item, not the actual state. So the UI shows displayState but the actual underlying open/closed state hasn’t been changed.
If you open up the developer sidebar (Shift+Alt+D) and go to the scratch pad and type in =items.name_of_your_rain_item_with_state_options.state I suspect that it will still show either Open or Closed. But, if you then get its displayState instead of state, it will show Rain or Dry.
If that’s the case then changing your rain item to a string should work for setting the actual state to Rain/Dry with the map transform, but, if this is just a cosmetic change and there is no reason the actual states of the item need to be modified, you can just continue with the stateDescription options because those will show properly in the UI (and can be used in custom widgets via the displayState property).
Hi Justin, I miss what’s obvious to everyone else when it comes to syntax… 
but what EXACT syntax do I type in? I tried ‘=items.ZWaveNode015FGK101RainSensor_DoorSensor_with_state_options.state’ without any apostrophes into the DSL.rule scratchpad and ran it but nothing happened??
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 
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… 