All right, so maybe I need to go the MQTT route. Homegear is supposed to publish all states of all its connected devices to MQTT. I could then subscribe to them and see what will be published. I might do it at a later point, definitely not tonight 
Thanks for sharing your thoughts. It’s definitely helpful!
@MHerbst
Do you mind looking at the discussion above and share your opinion whether the HomeMatic binding might be the cause of these incorrect raw states?
Thanks!
Hi Andreas,
I can try to help but I have no experience with Homegear. So I have to guess. As far as I understood Homegear supports Enocean devices and these devices will be handled in the same way as Homematic devices. The Homematic binding gets information about the connected devices (their types and capabilities) directly from a CCU or Homegear. If Homegear “emulates” a standard Homematic device for the Enocean window handle then the Homematic binding will handle it as a standard Homematic device, i.e. it will only support the states that the original device supports.
In order to find out what really happens, you can enable the trace for the Homematic binding and then restart openHAB. From the trace output, we can probably see what information Homegear sends to the binding.
Regards
Martin
I am not really familiar with the Karaf console and debugging. I am usually looking at the openHAB log file via frontail (which comes with openHABian).
So, would you mind to tell me what exactly I am supposed to do in order to enable the trace for the HomeMatic binding?
It is quite easy. You have to log on to karaf console (via ssh) oder you can use the Karaf client program: client. In the Karaf console you then enter the following command:
log:set TRACE org.openhab.homematic.binding
@MHerbst
I think I can’t follow you completely. Here’s what I did and I think I missed something.
20:09:59.030 [INFO ] [marthome.event.ItemStateChangedEvent] - eg_wz_sFenster3 changed from Undefined to Closed 20:10:00.872 [INFO ] [marthome.event.ItemStateChangedEvent] - eg_wz_sFenster3 changed from Closed to Open 20:10:02.913 [INFO ] [marthome.event.ItemStateChangedEvent] - eg_wz_sFenster3 changed from Open to Closed 20:10:03.873 [INFO ] [marthome.event.ItemStateChangedEvent] - eg_wz_sFenster3 changed from Closed to Undefined
That’s all. However, I am wondering what the TRACE level is supposed to show, and especially where I can find its output? I must be missing something!
Ouch, my fault. The correct statement is
log:set TRACE org.openhab.binding.homematic
You can disable the trace and restore the default logging with:
log:set INFO org.openhab.binding.homematic
OK, that seems to be working
Now, here’s the output from the log when I turned my window handle full circle.
2017-09-25 20:26:27.983 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-6e230a45
EOD01A93E7E:0
RSSI_DEVICE
-73
]
}
]
2017-09-25 20:26:27.987 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '-73' for 'EOD01A93E7E:0#RSSI_DEVICE' from gateway with id '6e230a45'
2017-09-25 20:26:27.998 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-6e230a45
EOD01A93E7E:1
STATE
1
]
}
]
2017-09-25 20:26:28.003 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '1' for 'EOD01A93E7E:1#STATE' from gateway with id '6e230a45'
2017-09-25 20:26:28.007 [TRACE] [converter.type.AbstractTypeConverter] - Converting ENUM value '1' with StringTypeConverter for 'EOD01A93E7E:1#STATE'
==> /var/log/openhab2/events.log <==
2017-09-25 20:26:28.027 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Undefined to Closed
==> /var/log/openhab2/openhab.log <==
2017-09-25 20:26:29.433 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-6e230a45
EOD01A93E7E:1
STATE
2
]
}
]
2017-09-25 20:26:29.435 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '2' for 'EOD01A93E7E:1#STATE' from gateway with id '6e230a45'
2017-09-25 20:26:29.445 [TRACE] [converter.type.AbstractTypeConverter] - Converting ENUM value '2' with StringTypeConverter for 'EOD01A93E7E:1#STATE'
==> /var/log/openhab2/events.log <==
2017-09-25 20:26:29.466 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Closed to Open
==> /var/log/openhab2/openhab.log <==
2017-09-25 20:26:30.706 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-6e230a45
EOD01A93E7E:1
STATE
1
]
}
]
2017-09-25 20:26:30.709 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '1' for 'EOD01A93E7E:1#STATE' from gateway with id '6e230a45'
2017-09-25 20:26:30.722 [TRACE] [converter.type.AbstractTypeConverter] - Converting ENUM value '1' with StringTypeConverter for 'EOD01A93E7E:1#STATE'
==> /var/log/openhab2/events.log <==
2017-09-25 20:26:30.743 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Open to Closed
==> /var/log/openhab2/openhab.log <==
2017-09-25 20:26:31.706 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-6e230a45
EOD01A93E7E:1
STATE
0
]
}
]
2017-09-25 20:26:31.713 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '0' for 'EOD01A93E7E:1#STATE' from gateway with id '6e230a45'
2017-09-25 20:26:31.716 [TRACE] [converter.type.AbstractTypeConverter] - Converting ENUM value '0' with StringTypeConverter for 'EOD01A93E7E:1#STATE'
==> /var/log/openhab2/events.log <==
2017-09-25 20:26:31.738 [ItemStateChangedEvent ] - ug_buero_sFenster changed from Closed to Undefined
==> /var/log/openhab2/openhab.log <==
2017-09-25 20:26:35.322 [TRACE] [nal.communicator.client.BinRpcClient] - Client BinRpcRequest:
listBidcosInterfaces()
2017-09-25 20:26:35.324 [TRACE] [al.communicator.client.SocketHandler] - Returning socket for port 2001
2017-09-25 20:26:35.329 [TRACE] [nal.communicator.client.BinRpcClient] - Client BinRpcResponse:
[
{
ADDRESS=VBC8078537
CONNECTED=true
DEFAULT=true
DESCRIPTION=Homegear default BidCoS interface
}
]
My take is the following:
These integer values completely reflect what I posted earlier from the Homegear log. See here again:
sudo tail -f /var/log/homegear/homegear.log
09/23/17 22:24:12.355 EnOcean packet received (EnOcean_Pi_Gateway, RSSI: -73 dBm): 55000707017AF6E001A93E7E2001FFFFFFFF490014 - Sender address: 0x01A93E7E
09/23/17 22:24:12.355 Module EnOcean: Info: STATE on channel 1 of peer 21 with serial number EOD01A93E7E was set to 0x01.
09/23/17 22:24:12.871 EnOcean packet received (EnOcean_Pi_Gateway, RSSI: -77 dBm): 55000707017AF6D001A93E7E2001FFFFFFFF4D00C1 - Sender address: 0x01A93E7E
09/23/17 22:24:12.871 Module EnOcean: Info: STATE on channel 1 of peer 21 with serial number EOD01A93E7E was set to 0x02.
09/23/17 22:24:13.846 EnOcean packet received (EnOcean_Pi_Gateway, RSSI: -74 dBm): 55000707017AF6C001A93E7E2001FFFFFFFF4A00D5 - Sender address: 0x01A93E7E
09/23/17 22:24:13.846 Module EnOcean: Info: STATE on channel 1 of peer 21 with serial number EOD01A93E7E was set to 0x01.
09/23/17 22:24:14.177 EnOcean packet received (EnOcean_Pi_Gateway, RSSI: -77 dBm): 55000707017AF6F001A93E7E2001FFFFFFFF4D003F - Sender address: 0x01A93E7E
09/23/17 22:24:14.177 Module EnOcean: Info: STATE on channel 1 of peer 21 with serial number EOD01A93E7E was set to 0x00.
Now, what’s your thinking?
The trace shows that the value received from Homegear for the STATE is of type “Integer” and it can have 3 different values (0, 1, 2). This does not work for item type CONTACT is an enum with two different values.
You can try to define the item as “Number” and try to map the numeric values.
Well, now I am back again at my original question: How can I perform a raw state transformation??? I don’t understand this.
Clearly, when using a “Number” item or a “Contact” item without raw state transformation, I do have a problem due to the raw states:
2017-09-27 21:27:08.660 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'windowContacts.items'
2017-09-27 21:27:08.705 [ERROR] [rthome.core.library.items.NumberItem] - Tried to set invalid state Undefined on item ug_buero_sFenster of type NumberItem, ignoring it
2017-09-27 21:28:36.126 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'windowContacts.items'
2017-09-27 21:28:36.178 [ERROR] [rthome.core.library.items.NumberItem] - Tried to set invalid state Closed on item ug_buero_sFenster of type NumberItem, ignoring it
2017-09-27 21:27:59.641 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'windowContacts.items'
2017-09-27 21:27:59.680 [ERROR] [thome.core.library.items.ContactItem] - Tried to set invalid state Undefined on item ug_buero_sFenster of type ContactItem, ignoring it
2017-09-27 21:29:01.029 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'windowContacts.items'
2017-09-27 21:29:01.064 [ERROR] [thome.core.library.items.ContactItem] - Tried to set invalid state Closed on item ug_buero_sFenster of type ContactItem, ignoring it
I would already be happy if I could transform 0 to CLOSED and both 1 and 2 to OPEN, as “Open” and “Ajar” are both signalling that the window is not “Closed”, i.e. it’s “Open” 
Maybe I could then use an item of type “Contact”.
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.
It’s the proxy item design pattern! Rich’s based on Bob’s one:
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! :-)