Just an idea (did not test it yet, so I am not absolutely sure whether it works): You define an item of type Number that is connected to the state channel of the Enocean thing (without maping). In addition you define a “virtual” item of type “Contact” that is not connected to a real channel.
In a rule you can catch state chaned of the Number item and set the state of the virtual Contact item accordingly.
1 Like
It’s the proxy item design pattern! Rich’s based on Bob’s one:
1 Like
That’s what I just did and as you can see in my previous reply, the item will simply be ignored. The item definition is as follows:
Number ug_buero_sFenster "Büro" {channel='homematic:HG-F6-10-00:6e230a45:EOD01A93E7E:1#STATE'}
As a result, if it is being ignored, I assume I cannot pass the state to a virtual contact.
As I write these lines, I start to wonder why the states that I see in the logs are not integer values as the trace suggest?? In fact, there must be some kind of transformation from integers to strings, I guess.
Actually there is! Try adding “.toString” to your integer value in a rule!
This seems to be a working solution. Here’s what I did:
Item definition:
String ug_buero_sFenster "Büro [MAP(EnOceanWindowHandle_label.map):%s]" <contact> (gUG_fenster) {channel='homematic:HG-F6-10-00:6e230a45:EOD01A93E7E:1#STATE'}
Contact ug_buero_vFenster "Büro [%s]" <contact>
To explain: sFenster means sensorFenster while vFenster means virtualFenster
Rule definition:
rule "ug_buero_sFenster transformation"
when
Item ug_buero_sFenster received update
then
if (ug_buero_sFenster.state == "Undefined") {
ug_buero_vFenster.postUpdate(CLOSED)
}
else {
ug_buero_vFenster.postUpdate(OPEN)
}
end
I can now put ug_buero_vFenster on my sitemap as a contact and the state alternates bewtween OPEN and CLOSED and even the icon is working properly. 
Here’s the log output when turning the window handle full circle. Pay special attention to the second and the very last line.
2017-09-27 22:25:33.753 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Undefined to Closed
2017-09-27 22:25:33.776 [ItemStateChangedEvent ] - ug_buero_vFenster changed from CLOSED to OPEN
2017-09-27 22:25:35.455 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Closed to Open
2017-09-27 22:25:37.062 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Open to Closed
2017-09-27 22:25:38.216 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Closed to Undefined
2017-09-27 22:25:38.247 [ItemStateChangedEvent ] - ug_buero_vFenster changed from OPEN to CLOSED
The only drawback is that I “only” have two states. Rather than distinguishing between Closed, Open, and Tilted, I only distinguish between Open and Closed. But hey, that should work! The main reason of the smart window handle is to get notified when the window is either open or closed, no matter how far open it is. 
Well, am I able to influence this transformation at the very beginning?
What exactly do you mean with that. I don’t understand. Can you show me an example, please?
Following your discussion I understood that you have 3 states that you wanted to acknowledge (2 in an open state, 1 in a close state), so your contact item should do just fine! Furthermore, if you would like to be more invasive with your virtual item, you can have many workarounds, such as: define a string or a number (I never used the homematic binding, so I do not know the format delivered by the binding) item with your homematic binding and map the values in a sitemap with a switch item that will show you the state corresponding to your binding received values! Such as:
Item file
String myItemWithBinding
Sitemap file
Switch item=myItemWithBinding mappings=["0/Undefined"="Closed", "1"="Opened, "2"="Ajar"]
I am not sure if the left part of the identities in mappings should be with quotes or without in the case of a string item which I previously assumed being used! I can not try it right now!
One more thing: the switch item in sitemap is not read only, so that means that if you will touch the commands, openHAB will try to send a command to the binding! If the binding provides a read only state for the data point, and also provides a feedback, then there should be no worries with the setup described above.
yourItem.state.toString //this is the case of any item
or if a variable is defined:
var int yourIntegerVariable
//for example you would use this variable to concatanate some string
var String yourText="Bla, bla"+yourIntegerVariable.toString
@george.erhan
I didn’t exactly followed your idea regarding a switch, but you pushed me in the right direction. I now defined the real and the virtual device as string. I then mapped the “incorrect” raw states of the real device via rule to the “correct” ones, i.e.
Undefined --> CLOSED
Closed --> OPEN
Open --> AJAR
Using string items (rather than contact items) has the advantage that the contact icon on my sitemap will signal all three states correctly. In addition, for the text on my sitemap to be translated into German, I created a map transformation file.
Item file
// Real devices
String ug_buero_sFenster {channel='homematic:HG-F6-10-00:6e230a45:EOD01A93E7E:1#STATE'}
// Virtual devices
String ug_buero_vFenster "Büro [MAP(EnOceanWindowHandle_label.map):%s]" <contact> (gUG_fenster)
Rule file
rule "ug_buero_sFenster transformation"
when
Item ug_buero_sFenster received update
then
switch(ug_buero_sFenster.state) {
case "Undefined": ug_buero_vFenster.postUpdate("CLOSED")
case "Closed": ug_buero_vFenster.postUpdate("OPEN")
case "Open": ug_buero_vFenster.postUpdate("AJAR")
}
end
Transformation file
-=N/A
NULL=N/A
CLOSED=geschlossen
OPEN=offen
AJAR=gekippt
With that I assume the problem of “raw state transformation” to be solved. The proxy item design pattern described by @rlkoshak did the trick.
Thanks to all of you for your great effort. I like this forum! :-)
1 Like