I am currently building my items and rules from scratch and struggle with the MAP transformation.
Obviously it’s more complicated than expected:
What I am trying to achieve is to get the states in German (e.g. contacts OPEN=offen, CLOSED=zu).
This works for some strings representing contacts (ON / OFF) (and other string stuff) which are mapped correctly to offen/zu using my de.map:
As far as I understood, I can configure the MAP in two ways:
Item definition: Metadata State description: MAP(contacts.map):%s
Profile MAP using the de.MAP file I have
The problematic contact is a “real” contact channel of a window sensor (Fibaro).
This sensor is a equipment (window) and has a few points (OpenState, Battery, …)
I have configured the Window equipment like this:
This “Mother”-Equipment reflects the mapped state “zu”
The contact point within this equipment itself returns “Closed” in mainUI even though I have set the State description pattern the same way.
Furthermore the eventlog returns “CLOSED” if the windoe changes (uppercase).
Does anyone have an idea why this is not working as expected?
A profile is applied to a link between binding Item and channel; MAPping that will result in a modified state being pushed to the Item. Of course it might not “fit”, the state of a Switch type Item is ON or OFF regardless of language in use, and can never be “Aus”.
A pattern is about presentation, we can take a state like 3.1417 and format it to 3.1 for display. The Item state remains 3.1417, its just about UI appearance. Same applies to MAP in pattern, it transforms the real state for display purposes only but the actual state is never altered.
Where in MainUI? Parts of MainUI are “admin interface” and so we might expect it to show real states by default.
Presentation prettifying is for user-facing parts.
I might be able to kill two birds with one stone here.
I’m going to guess that this sensor is Zwave since it’s a Fibaro. The Zwave binding will supply its own State Description to the Item behind the scenes. This can cause problems that is not related to this thread so I won’t go into it. That’s where the “Open” is coming from.
I’ve been told that this “injected” state should be overridable by setting a State Description metadata of your own (except in the case of that problem).
If I understand correctly, you have entered your own State Description Pattern but it’s not overriding what the binding has provided. Correct?
I believe in this case the binding is providing State Description Options. What happens if you move the contents of your .map file to the Options field of the State Description?
NOTE: I’ve found sometimes it takes a refresh of the browser to pick up changes to the State Description metadata.
You can confirm that by examining your Item with API Explorer.
One of the things the binding-supplied options was intended for was to supply in language as per OH base setting. But that depends on someone setting up the binding end.
I’ve an issue open in front of the AC and I have Kai’s attention but I need to confirm whether or not the stuff supplied by the binding can be overridden when the Item type is correct (we already know it doesn’t work when a Profile was used to change the Item type). There is a proposed solution but it won’t work if we can’t override it in a case like this.
Thank you! That’s good to know as I always struggled with these different stuff.
This thread opened my eyes, that both methods above are not doing the same.
I will clean up my MAP files accordingly