OH3 MAP transformation is behaving different for different Items

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"
	]
}
1 Like

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.

@rossko57 and @pacive how do we file this as an issue.

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… :weary: 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 :grinning:

1 Like

Sorry, I was referring to the small widget scratchpad directly in the developer sidebar
image

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.

:grinning: 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:
Screenshot 2021-01-27 at 22.11.04

Not choosing the ‘server’ state:
Screenshot 2021-01-27 at 22.11.27

I should be getting DRY or RAIN. All this did work in OH2. This fiddling is very trying… :scream:

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 :smile:

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 :slight_smile: Would be a nice bugfix, if the UI deletes the options-field if the content in the field is empty.

image

2 Likes

Open the code tab and delete the options entry that way.