I have a strange issue with my openhab2 - homematic installation. As always, yesterday everything was fine but now the shutters will only go up and no longer down. Openhab is sending the right command:
2019-08-21 07:51:23.125 [ome.event.ItemCommandEvent] - Item ‘iHMShutterLivingTerrace’ received command UP
But instead of going up the shutter goes down. Before everything was fine, so I’m a little bit confused why the shutter is now not working as expected. The only change I can remember was an update of the CCU3 firmware to 3.47.15.
Even after updateing the openhab 2.4 installation with the update tool the issue is still there.
Hello again,
meanwhile I’m a little bit wiser and want to share this here. But to say it upfront, even if I’m wiser, the problem is not yet solved
Some of my shutters are still going down by rules, but only these that have a dedicated percentage set - e.g. openShutter.sendCommand(55). So I changed the sendCommand in my rules to “1” instead of “UP” and it works. At least a workaroung for the rules, this reduces the complains from the family a little bit
But when I try to control the shutters with the Openhab App the issue remains. I assumed, that this is becasue of the widget is using “UP” or “0”. To verify this I increased the log level to trace for the homeatic binding:
2019-08-27 20:46:25.252 [ome.event.ItemCommandEvent] - Item 'iHMShutterLivingTerraceRightProxy' received command UP
2019-08-27 20:46:25.305 [ome.event.ItemCommandEvent] - Item 'iHMShutterLivingTerraceRight' received command UP
2019-08-27 20:46:25.317 [nt.ItemStatePredictedEvent] - iHMShutterLivingTerraceRight predicted to become UP
2019-08-27 20:46:25.318 [DEBUG] [ematic.handler.HomematicThingHandler] - Received command 'UP' for channel 'homematic:HmIP-BROLL:ccu:0011170XXXXXXX:4#LEVEL'
2019-08-27 20:46:25.337 [TRACE] [converter.type.AbstractTypeConverter] - Converting type UpDownType with value 'UP' to FLOAT value with PercentTypeConverter for '0011170XXXXXXX:4#LEVEL'
2019-08-27 20:46:25.346 [TRACE] [converter.type.AbstractTypeConverter] - Converting type PercentType with value '0' to FLOAT value with PercentTypeConverter for '0011170XXXXXXX:4#LEVEL'
So the UpDownType will be converted to Float and PercentageType and finally to the value “0”. So far so good…
2019-08-27 20:46:25.347 [vent.ItemStateChangedEvent] - iHMShutterLivingTerraceRight changed from 29 to 0
2019-08-27 20:46:25.354 [DEBUG] [ommunicator.AbstractHomematicGateway] - Sending datapoint '0011170XXXXXXX:4#LEVEL' with value '1.01' to gateway with id 'ccu' using rxMode 'DEFAULT'
2019-08-27 20:46:25.360 [TRACE] [nal.communicator.client.XmlRpcClient] - Client XmlRpcRequest (port 2010):
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodCall><methodName>setValue</methodName>
<params><param><value>0011170XXXXXXX:4</value></param><param><value>LEVEL</value></param><param><value><double>1.01</double></value></param></params></methodCall>
2019-08-27 20:46:25.511 [TRACE] [nal.communicator.client.XmlRpcClient] - Client XmlRpcResponse (port 2010):
<?xml version="1.0" encoding="ISO-8859-1"?><methodResponse><params><param><value></value></param></params></methodResponse>
2019-08-27 20:46:25.595 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value '0.72' for '0011170XXXXXXX:4#LEVEL' from gateway with id 'ccu'
2019-08-27 20:46:25.601 [TRACE] [converter.type.AbstractTypeConverter] - Converting FLOAT value '0.72' with PercentTypeConverter for '0011170XXXXXXX:4#LEVEL'
2019-08-27 20:46:25.606 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '0' for '0011170XXXXXXX:4#LEVEL_STATUS' from gateway with id 'ccu'
2019-08-27 20:46:25.614 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Integer) value '3' for '0011170XXXXXXX:4#SECTION' from gateway with id 'ccu'
2019-08-27 20:46:25.622 [vent.ItemStateChangedEvent] - iHMShutterLivingTerraceRight changed from 0 to 29
…but why is the binding sending the double value “1.01”? And it seems so, that the shutter interprets this as 101, because he is going down instead of up.
All my shutters have the same behaviour, so I’m not sure if this is the defect or if this is normal and the defect is somewhere else.
Does someone has an idea or can confirm, that normally the value is “0” and not “1.01”?
