OpenHAB & Homematic CCU2 - Sync state of switches to OpenHAB

NOTE: My apologies for splitting this question in the next four posts. The forum software doesn’t let a new user post more than one picture per post. So the next four posts contain one question :wink:

I am trying to receive the current state of a remote switch using OpenHAB. Currently, I can trigger the switch from OpenHAB (and the state is correctly set within OpenHAB). But if I use a Homematic Remote to trigger the switch the state of OpenHAB does not change.

This is my current setup:

  1. The switch receives the trigger using a homematic direct connection:
  1. The switch has the following item in OpenHAB:
    Switch ledsteckdose "LEDs Stahlträger" (gLighting) { homematic="address=LEQ1068281, channel=1, parameter=STATE" }
  2. The web frontend shows the state of the switch:
    Group item=gLighting label="Beleuchtung" icon="firstfloor"

If I reload the datapoints manually, I receive the correct state from the CCU2. This is the item I use:
Switch reload_datapoints "Reload Datapoints" (Admin) {homematic="action=RELOAD_DATAPOINTS"}

I therefore assume that my basic configuration is correct. Digging into the documentation I read about the “Variable/Datapoint sync”.

I define two virtual remote within the CCU2:

The virtual remotes are triggered when the switch changes its state:

Back within OpenHAB the following two items should trigger a state sync:
Switch VK_Reload_Variable (gHomeMatic) {homematic="address=BidCoS-RF, channel=1, parameter=PRESS_SHORT, action=RELOAD_VARIABLES"} Switch VK_Reload_Datapoint (gHomeMatic) {homematic="address=BidCoS-RF, channel=2, parameter=PRESS_SHORT, action=RELOAD_DATAPOINTS"}

BUT: I do not receive anything on the OpenHAB side of things. The events.log shows messages like
2015-09-10 10:48:01 - ledsteckdose received command OFF but nothing with respect to VK_Reload_Variable or VK_Reload_Datapoint.

Any thoughts/hints?

-Mathias

For me it sounds like the connection between your openHAB binding and the CCU is just partially working. The binding is normally subscribing to the XMLRPC event interface of the CCU. Because of this you should automatically see every change of a Homematic device that has correct binding information.
In your case it seems to work just in one direction and you have to “pull” the changes via RELOAD_DATAPOINTS. But this is normally not the way it should be.

Hi Lars,

thanks for your analysis. I looked at my log files but did not find an entry related to XMLRPC. Is the “Homematic Communicator” or the “BinRpcClient” the right communication interface? O also found some lines from the “AbstractTypeConverter” that translate all my devices (including the virtual remote ones) correctly. The full startup log looks like this:

2015-09-11 08:57:19.475 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.6.2). 2015-09-11 08:57:26.352 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started 2015-09-11 08:57:26.571 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed (bound to address: 192.168.1.111). 2015-09-11 08:57:34.319 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'default.sitemap' 2015-09-11 08:57:35.969 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'homematic.items' 2015-09-11 08:57:36.152 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'wetter.items' 2015-09-11 08:57:39.932 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest 2015-09-11 08:57:45.692 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /openhab.app 2015-09-11 08:57:50.699 [DEBUG] [o.b.h.i.bus.HomematicActivator] - Homematic binding has been started. 2015-09-11 08:57:50.892 [DEBUG] [omematicGenericBindingProvider] - Adding item ledsteckdose with DatapointConfig[address=LEQ1068281,channel=1,parameter=STATE] 2015-09-11 08:57:50.898 [DEBUG] [omematicGenericBindingProvider] - Adding item flurschalter with DatapointConfig[address=LEQ0625581,channel=1,parameter=STATE] 2015-09-11 08:57:50.902 [DEBUG] [omematicGenericBindingProvider] - Adding item deckenfluter with DatapointConfig[address=LEQ0625581,channel=2,parameter=STATE] 2015-09-11 08:57:50.911 [DEBUG] [omematicGenericBindingProvider] - Adding item reload_variables with DatapointConfig[address=BidCoS-RF,channel=1,parameter=PRESS_SHORT,action=RELOAD_VARIABLES] 2015-09-11 08:57:50.916 [DEBUG] [omematicGenericBindingProvider] - Adding item reload_datapoints with DatapointConfig[address=BidCoS-RF,channel=2,parameter=PRESS_SHORT,action=RELOAD_DATAPOINTS] 2015-09-11 08:57:51.001 [INFO ] [o.o.b.h.i.bus.HomematicBinding] - HomematicConfig[host=192.168.1.110,callbackHost=192.168.1.110,callbackPort=9123,aliveInterval=300] 2015-09-11 08:57:51.003 [INFO ] [.b.h.i.c.HomematicCommunicator] - Starting Homematic communicator 2015-09-11 08:57:51.020 [DEBUG] [.h.i.communicator.ItemDisabler] - Starting ItemDisabler 2015-09-11 08:57:51.079 [INFO ] [.b.h.i.c.HomematicCommunicator] - Homematic ServerId[name=CCU,version=2.15.2,address=LEQ0420056] 2015-09-11 08:57:51.108 [INFO ] [o.o.b.h.i.c.client.CcuClient ] - Starting CcuClient 2015-09-11 08:57:51.111 [DEBUG] [.o.b.h.i.c.client.BinRpcClient] - Starting BinRpcClient 2015-09-11 08:57:51.152 [INFO ] [.service.AbstractActiveService] - HTTP Refresh Service has been started 2015-09-11 08:57:51.272 [INFO ] [b.h.i.communicator.StateHolder] - Loading Homematic datapoints 2015-09-11 08:57:52.532 [DEBUG] [.b.h.i.c.c.BaseHomematicClient] - Adding battery type to device HM-PB-2-WM55-2: 2x AAA/Micro/LR03 2015-09-11 08:57:52.593 [INFO ] [b.h.i.communicator.StateHolder] - Finished loading 245 Homematic datapoints 2015-09-11 08:57:52.596 [INFO ] [b.h.i.communicator.StateHolder] - Loading Homematic Server variables 2015-09-11 08:57:52.713 [INFO ] [b.h.i.communicator.StateHolder] - Finished loading 2 Homematic server variables 2015-09-11 08:57:52.717 [INFO ] [b.h.i.c.s.BinRpcCallbackServer] - Starting BinRpcCallbackServer at port 9123 2015-09-11 08:57:52.740 [INFO ] [.o.b.h.i.c.client.BinRpcClient] - Interface BidCos-Wired not available, disabling support. 2015-09-11 08:57:52.745 [INFO ] [.o.b.h.i.c.client.BinRpcClient] - Interface CUxD not available, disabling support. 2015-09-11 08:57:52.747 [INFO ] [.b.h.i.c.HomematicCommunicator] - Scheduling one datapoint reload job in 60 seconds 2015-09-11 08:57:52.752 [INFO ] [.service.AbstractActiveService] - Homematic server keep alive thread has been started 2015-09-11 08:57:55.798 [DEBUG] [.h.i.c.s.AbstractTypeConverter] - Converting (Boolean) value 'false' with OnOffTypeConverter for HmDatapoint[address=BidCoS-RF,channel=1,parameter=PRESS_SHORT] 2015-09-11 08:57:55.804 [DEBUG] [.h.i.c.s.AbstractTypeConverter] - Converting (Boolean) value 'false' with OnOffTypeConverter for HmDatapoint[address=BidCoS-RF,channel=2,parameter=PRESS_SHORT] 2015-09-11 08:57:55.807 [DEBUG] [.h.i.c.s.AbstractTypeConverter] - Converting (Boolean) value 'false' with OnOffTypeConverter for HmDatapoint[address=LEQ0625581,channel=1,parameter=STATE] 2015-09-11 08:57:55.826 [DEBUG] [.h.i.c.s.AbstractTypeConverter] - Converting (Boolean) value 'false' with OnOffTypeConverter for HmDatapoint[address=LEQ0625581,channel=2,parameter=STATE] 2015-09-11 08:57:55.829 [DEBUG] [.h.i.c.s.AbstractTypeConverter] - Converting (Boolean) value 'false' with OnOffTypeConverter for HmDatapoint[address=LEQ1068281,channel=1,parameter=STATE] 2015-09-11 08:58:52.750 [DEBUG] [.b.h.i.c.HomematicCommunicator] - Initial Homematic datapoints reload 2015-09-11 08:58:52.759 [DEBUG] [b.h.i.communicator.StateHolder] - Reloading Homematic server datapoints 2015-09-11 08:58:53.452 [DEBUG] [.b.h.i.c.c.BaseHomematicClient] - Adding battery type to device HM-PB-2-WM55-2: 2x AAA/Micro/LR03 2015-09-11 08:58:53.477 [DEBUG] [b.h.i.communicator.StateHolder] - Finished reloading 245 Homematic server datapoints

-Mathias

To track that issue down I would propose to disable / deactivate the virtual remote things in CCU2 and the triggered datapoint reloading in openHAB. As the docs say it is only needed if openHAB events shall be triggered by the change of an ccu2 system variable.

The first check would be to see if the state of “ledsteckdose” changes in openHAB when the HM-LC-Sw1-Pl-2 actor is triggered on the device itself. If this is not working there is a general communication problem between CCU2 and openHAB.

In my setup I have not the same actor like you but a similar device (wall mount light switch HM-LC-Sw1PBU-FM) and the behaviour is consistent even if the actor is triggered from the bound openHAB switch or from the device itself.

By the way - did you check your CCU firewall settings ? As far as I remember the access to the XMLRPC is partly restricted by default so be shure your openHAB node is within the allowed networks.

Cheers - Robert

Right, The documentation says:

The CCU firewall must be configured to 'full access' for the Remote Homematic-Script API

Also interesting might be your openhab.cfg (the homematic relevant part at least).
I know that I have just the “homematic:host” set to the right IP Address and all other options are still default (by keeping the # in front of).

Problem solved!

This set me on the right track: My CCU2 listens on 192.168.1.110, my RPi running OpenHAB on 192.168.1.111. I misconfigured the callback setting:

# Hostname / IP address for the callback server (optional, default is auto-discovery)
# This is normally the IP / hostname of the local host (but not "localhost" or "127.0.0.1").
homematic:callback.host=192.168.1.110

Instead of .110 it should read .111 - now everything works as expected.

@rbausdorf: Thanks for your advice regarding using the device’s trigger to switch it - I didn’t think of it, but I will remember this for future debugging sessions.

Thanks a lot,
-Mathias

1 Like