[SOLVED] Raw state transformation

KraxelHuber · September 21, 2017, 9:21pm

I incorporated some EnOcean window handles via Homegear/HomeMatic binding into openHAB 2. Up to a certain point, this worked flawlessly, as you can read here. However, I am struggling a bit with the items definition. The issue is that the raw states for the window handles, which are coming from Homegear, are a bit confusing. A window handle can have three different states:

closed
open
ajar (tilted)

The raw states that I see in my OH2 log file are the following ones:

Undefined (which equals ‘closed’ in reality)
Closed (which equals ‘open’ in reality)
Open (which equals ‘ajar’ in reality)

If I turn my window handle all the way from closed to open to ajar (tilted) and back, my log file produces the following lines:

2017-09-21 22:54:37.269 [ItemStateChangedEvent     ] - ug_buero_sFenster changed from Undefined to Closed
2017-09-21 22:54:39.519 [ItemStateChangedEvent     ] - ug_buero_sFenster changed from Closed to Open
2017-09-21 22:54:41.603 [ItemStateChangedEvent     ] - ug_buero_sFenster changed from Open to Closed
2017-09-21 22:54:43.021 [ItemStateChangedEvent     ] - ug_buero_sFenster changed from Closed to Undefined

Now, I am wondering if it is possible to transform these incorrect raw states into the correct ones? And I am not talking about a simple label transformation as described in the docs.

It’s simply a bit weird and annoying when you have to work with incorrect raw states and your rules look like this:

rule "Test"
when
    Item ug_buero_sFenster changed from Undefined to Closed
then
    ...
end

Which in reality means:

rule "Test"
when
    Item ug_buero_sFenster changed from Closed to Open
then
    ...
end

What’s more? The incorrect raw states are causing problems with dynamic icons on my sitemap. I already performed a label state transformation. However, in my case that didn’t help to solve the icon issue. Also, as can be read in the docs, a dynamic icon depends on an item’s state rather on an item’s label. At least that’s my take, even though it seems as if opinions are split on that issue as you can read in many posts regarding the ‘dynamic icon issues’ in this forum.

My current item definition:

Item file
String ug_buero_sFenster “Büro [MAP(EnOceanWindowHandle_label.map):%s]” (gUG_fenster) {channel=‘homematic:HG-F6-10-00:6e230a45:EOD01A93E7E:1#STATE’}

I am looking for a syntax (if possible at all) to change the raw state within the item definition. When using MQTT, this is possible. You can even use a transformation file. A comparable item definition might look as follows:

Item file
String ug_buero_sFenster “Büro [MAP(EnOceanWindowHandle_label.map):%s]” (gUG_fenster) {mqtt=“<[mosquitto:ug/buero/sensor/fenster:state:MAP(EnOceanWindowHandle_configBinding.map)]”}

EnOceanWindowHandle_configBinding.map
Undefined=closed
Closed=open
Open=ajar

Does anybody has an idea to solve that issue?

5iver · September 21, 2017, 9:40pm

How are your items defined? It sounds like you may be using Contact instead of String. There is an example for window contact in the Homematic binding doc:

http://docs.openhab.org/addons/bindings/homematic1/readme.html#datapoint-examples

KraxelHuber · September 22, 2017, 5:53am

Hmm, the example you are referring to also uses STRING. Not sure if I already tried to use contact instead. Will try tonight and let you know.

5iver · September 22, 2017, 6:01am

Are your items currently Strings?

KraxelHuber · September 22, 2017, 6:26am

Yes, see item definition above.

5iver · September 22, 2017, 6:31am

Sorry… I completely missed them when I first read your post. Thought you may be using Contacts and thought that could be causing the trouble.

KraxelHuber · September 23, 2017, 9:40am

Contact is not working at all.

rlkoshak · September 23, 2017, 8:15pm

No, because a Contact only has two states, OPEN and CLOSED. There is no AJAR state for a Contact Item. Undefined doesn’t count as a state. An Item will be initialized to Undefined when OH first starts or the .items file is first loaded and it is not intended to be used like a “real” state. It is intended to be a flag to your rules to indicate that you have no information about the state of that Item.

I’m not sure how to interpret the logs you provide. Either something very odd and buggy is going on or the EnOcean binding is operating in a non-standard fashion. It should not be setting the Item to Undefined. It looks as if it is treating Undefined to mean CLOSED and CLOSED to mean AJAR which, IMHO is just wrong. They should be using some other Item type rather than misusing Contact in this way.

Yet another reason why this is just completely wrong for the binding to be treating Undefined as a meaningful state.

Only if the Homematic binding supports transformations.If it does you would define the transformation on the Thing definition, not the Item. You do it on the Item in MQTT because it is a 1.x version binding which doesn’t have Things.

I’m starting to wonder though if there is something else misconfigured because as mentioned, it is populating the Item as if it were a Contact but you are assigning it to a String Item so there is clearly something going wrong.

Finally, assuming everything is working as a String, your Rule triggers won’t work. They currently do not support Strings (or Numbers I think) in the trigger clause. So if ug_buero_sFenster is a String Item, changed from Closed to Open will never trigger. That would only work if the Item were a Contact and you used changed from CLOSED to OPEN.

You will have to use changed and then use if statements and previousState in your rule to figure out what it is changing from and to.

KraxelHuber · September 23, 2017, 8:51pm

Well, a window handle is something different compared to a contact. I agree that a regular contact has two states: OPEN and CLOSED. However, a window handle has in fact three states: CLOSED, OPEN, and AJAR (TILTED). Maybe this kind of item is simply not supported in OH2, I don’t know. But I know, that I do receive these three item states when I turn the window handle full circle, i.e. from CLOSED to OPEN to AJAR to OPEN to CLOSED.

Looking at the Homegear log file confirms it. The reported states correspond to the following physical states of my window handle:
0x00 = CLOSED
0x01 = OPEN
0x02 = AJAR (TILTED)

What you see in these logs is the full circle turn mentioned above.

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.

The raw states that I see in my OH2 log file can be translated as follows:

Undefined = CLOSED
Closed = OPEN
Open = AJAR

Maybe you’re right, I just wanted to highlight the issue that creating rules with some weird states is confusing
Right now, the following rule is working with the state “Undefined”:

rule "Close rollershutter"
when
    Item nightTime changed from OFF to ON
then
    if (eg_wz_sFenster3.state == "Undefined") {
        gEG_rollershutter_switch.sendCommand(DOWN)
    }
end

Correct, but what can be the next steps in order to come to a satisfying solution?

rlkoshak · September 23, 2017, 8:58pm

As far as I can tell the problem will lie in the Homatic binding. I don’t use this binding so have nothing to suggest.

By the time it gets to the core oats of OH the states are already wrong so there is little you can do short of correcting it in the binding itself.

KraxelHuber · September 23, 2017, 9:04pm

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!

KraxelHuber · September 23, 2017, 9:07pm

@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!

MHerbst · September 24, 2017, 10:52am

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

KraxelHuber · September 24, 2017, 1:25pm

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?

MHerbst · September 24, 2017, 3:52pm

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

KraxelHuber · September 24, 2017, 6:36pm

@MHerbst
I think I can’t follow you completely. Here’s what I did and I think I missed something.

Log into Karaf via sudo ssh -p 8101 openhab@localhost
log:set TRACE org.openhab.homematic.binding
logout from Karaf and restarted OH2 via sudo service openhab2 restart
logged into Karaf, again
I then turned one of my window handles full circle and in /var/log/openhab2/openhab.log the following lines showed up:

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!

MHerbst · September 25, 2017, 5:18pm

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

KraxelHuber · September 25, 2017, 7:37pm

@MHerbst

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:

The integer value 0 corresponds to the OH2 state “Undefined” which is in reality “CLOSED”.
The integer value 1 corresponds to the OH2 state “Closed” which is in reality “OPEN”.
The integer value 2 corresponds to the OH2 state “Open” which is in reality “AJAR”.

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?

MHerbst · September 27, 2017, 4:06pm

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.

KraxelHuber · September 27, 2017, 7:39pm

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”.