[SOLVED] Transformation issues (MAP)

[NCO (E. Gerland)]

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:

CLOSED=zu
Closed=zu
OPEN=offen
Open=offen
OFF=aus
off=aus
on=an
ON=an
day=Tag
night=Nacht

As far as I understood, I can configure the MAP in two ways:

1. Item definition: Metadata State description: MAP(contacts.map):%s
2. 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:

and:

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?

[rossko57]

@NCO

I can configure the MAP in two ways:

That does two different things.

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.

@NCO

The contact point within this equipment itself returns “Closed” in mainUI even though

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.

[NCO (E. Gerland)]

Thanks for your quick response and the explanation.

@rossko57

Where in MainUI?

It’s in the model definition:

And in the locations section of the mainUI as well as in a widget of this window.

[rlkoshak (Rich Koshak)]

@NCO

The problematic contact is a “real” contact channel of a window sensor (Fibaro).

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.

[rossko57]

@rlkoshak

I believe in this case the binding is providing State Description Options.

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.

[rlkoshak (Rich Koshak)]

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.

[rossko57]

@NCO

I have configured the Window equipment like this:

That’s a Group, not any “real” contact channel of a window sensor

@NCO

This “Mother”-Equipment reflects the mapped state “zu”

And it seems that works fine.

@NCO

The contact point within this equipment itself returns “Closed”

That’s a clue it is using the binding-supplied state options, not the user supplied MAP.
The raw state is CLOSED, so “Closed” must come from options.

[NCO (E. Gerland)]

@rlkoshak

If I understand correctly, you have entered your own State Description Pattern but it’s not overriding what the binding has provided. Correct?

Yes, that’s correct and is based on a regular MAP file I normally use.

@rlkoshak

I’ve found sometimes it takes a refresh

That’s my experience as well and I even tried it on other devices.

@rlkoshak

What happens if you move the contents of your .map file to the Options field of the State Description?

That DID the trick!
Thank you so much, Rich!
I just copied this into the Options of this contact:
CLOSED=zu
Closed=zu
OPEN=offen
Open=offen

[NCO (E. Gerland)]

@rossko57

You can confirm that by examining your Item with API Explorer

You and Rich are obviouly right (as so often :-D).
In the “Items” view the Contact shows CLOSED:

Thanks for your help.
The “hidden” Options are really confusing!

[rlkoshak (Rich Koshak)]

OK, I think that gives me the info I need to add to the AC thread I started to discuss this.

Glad you got it to work!

[rossko57]

@NCO

CLOSED=zu
Closed=zu
OPEN=offen
Open=offen

Note, that no Contact Item will ever get the raw states “Closed” or “Open”

[NCO (E. Gerland)]

Thanks, Rich for both - your help and addressing this for the future.
Much appreciated!

[NCO (E. Gerland)]

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