Had the same problem. Everything seemed to work, but only updated if I restarted the binding thing. Fixed it by removing everything related to my homegear setup, and re-adding them to Openhab from scratch. Now instant status updates. Thanks for the hard work!
Hi there, I’m faceing the same problem and have been getting along with the “Reload All From Gateway” channel from the GATEWAY-EXTRAS. I switch this one to ON by rule every 5 minutes and it reloads all states from the ccu. But this can’t be the solution. Might work for temperatures which don’t change that often, but in terms of doorcontacts this is way to long.
After a long search I’ve found this thread and deleted all Things and the Gateway, restarted openHAB and recreated them through the inbox. But still faceing the problem of not updating states.
Can anyone help? Do I have to remove the Binding to?
Setup is openHAB 3.3 in docker on Synology Diskstation and original CCU3. Config in general is working because state updates from CCU3 to openHab are working with the written workaround and sendCommand from openHAB to CCU3 works as expected.
Thanks in advance
1 Like
For me it was a specific device that wasn’t receiving updates, and it was that device that was improperly configured. I am also using file based configuration, I think you’re less likely to get configuration errors with inbox based configuration.
Do you have any pattern to which states are working and which are not? Do you have any other configuration at all that references/uses the CCU that could be causing the issue? Are you able to cut your configuration down to a single device from the inbox, a single gateway, and not much else? That may give you some hints.
When you turn on debug logging, do you get any messages at all that may be relevant?
I’m useing only Homematic IP Devices on this CCU. Manly eTRV and eTRV2 for radiator control, some WTH and some doorsensors (SWDM and SWDO). When I recreated the Things, I watched the behavior but it startet with the first one while every rule or configuration regarding the things was disabled. Every other Binding/Gateway is working as expected, it’s just the Homematic one that’s giveing me headache.
In the openhab.log file there are two warnings about the two windowsensors SWDM saying:
2022-12-06 08:00:34.806 [WARN ] [ommunicator.parser.GetParamsetParser] - Can’t set value for datapoint ‘00155F29xxxxx:0#UPDATE_PENDING’
So I again deleated these two things and all links to Items, but it didn’t change anything for the other items.
How can I get debug logging? Sorry, I’m just maybe an advanced user but no developer
There’s a few ways to turn on debug logging.
There are instructions in the binding info on turning on logging: Homematic - Bindings | openHAB
Log on to the Karaf console - for me this is:
ssh -p 8101 openhab@localhost
Password is usually habopen (or HabOpen, can’t recall).
Then turn on DEBUG logging or TRACE logging.
log:set DEBUG org.openhab.binding.homematic
You can see logs with
log:tail
Or just look in your log files as normal. I tend to find the log:tail gives me more info for some reason, never bothered to look into it in detail. I sometimes need to restart my openhab to make the log changes take effect - no idea why on that either. Most probably some sort of user error.
It produces a lot of logging, particularly at trace level. Working out what’s relevant can be hard. I’d probably start off with toggling updates on some device and see what’s coming into the log, and whether anything looks suspicious. Then if need be do the full startup trace as suggested in the binding doco - but that does give a lot of info that takes a while to sort through.
If you post here some subsets of info and explanations of what’s happening people will help. And you may be able to compare to my similar logs above, to see if you’re getting something different going on.
I suddenly have the same issue: OH 3.3 does not get change events anymore from my CCU3.
This was working now fine for years and stopped working after I restarted OH today (because of other reasons). Now I do not get change events anymore (besides those for the Bridgte Duty cycle).
Between today’s restart and the one before that, I added an HmIP-PSM-2 to the CCU3 and added some devices/channels to rooms and “Gewerke” that were unassigned before.
Trying to fix this I already rebooted the CCU3 and restarted OH several times (also with cleaning tmp and cache).
The CCU3 spits out errors when OH starts, I don’t remember seeing those before:
Dec 31 16:48:10 ccu cuxd[655]: process_rpc_request(192.168.0.7) - illegal XMLRPC(init) request
Dec 31 16:48:10 ccu rfd: XmlRpc transport error calling system.listMethods({"bb707ce1-8b96-47c1-9e91-458c51a57834"}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:10 ccu rfd: XmlRpc transport error calling listDevices({"bb707ce1-8b96-47c1-9e91-458c51a57834"}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:10 ccu cuxd[655]: INIT 'binary://172.17.0.1:9126' 'f645c189-f8f3-4134-aad1-6611e9aa1471'
Dec 31 16:48:19 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","BOOT",false}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:19 ccu rfd: XmlRpc transport error
Dec 31 16:48:20 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","ENERGY_COUNTER",228673.900000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","POWER",4.230000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","CURRENT",76.000000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","VOLTAGE",239.900000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:2","FREQUENCY",49.970000}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:20 ccu rfd: XmlRpc transport error
Dec 31 16:48:28 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:1","STATE",true}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:28 ccu rfd: XmlRpc transport error
Dec 31 16:48:28 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:1","WORKING",false}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:28 ccu rfd: XmlRpc transport error
Dec 31 16:48:28 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","BOOT",true}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","ENERGY_COUNTER",140786.900000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","POWER",0.120000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","CURRENT",19.000000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","VOLTAGE",239.700000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1977779:2","FREQUENCY",49.970000}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:28 ccu rfd: XmlRpc transport error
Dec 31 16:48:31 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:1","STATE",true}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:1","WORKING",false}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:31 ccu rfd: XmlRpc transport error
Dec 31 16:48:31 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","BOOT",true}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","ENERGY_COUNTER",9904.200000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","POWER",4.290000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","CURRENT",72.000000}],[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","VOLTAGE",239.900000}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:31 ccu rfd: XmlRpc transport error
Dec 31 16:48:31 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1973823:2","FREQUENCY",49.970000}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:31 ccu rfd: XmlRpc transport error
Dec 31 16:48:32 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:1","STATE",true}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:32 ccu rfd: XmlRpc transport error
Dec 31 16:48:32 ccu rfd: XmlRpcClient error calling event({[methodName:"event",params:{"bb707ce1-8b96-47c1-9e91-458c51a57834","OEQ1975027:1","WORKING",false}]}) on http://172.17.0.1:9125/RPC2:
Dec 31 16:48:32 ccu rfd: XmlRpc transport error
Dec 31 16:48:33 ccu cuxd[655]: use CUX2801001:1.CMD_QUERY_RET=1 to activate CUX2801001:1.CMD_RETS command!
Dec 31 16:48:33 ccu cuxd[655]: use CUX2801001:1.CMD_QUERY_RET=1 to activate CUX2801001:1.CMD_RETS command!
Dec 31 16:48:33 ccu cuxd[655]: use CUX2801001:1.CMD_QUERY_RET=1 to activate CUX2801001:1.CMD_RETS command!
Dec 31 16:48:33 ccu cuxd[655]: use CUX2801001:1.CMD_QUERY_RET=1 to activate CUX2801001:1.CMD_RETS command!
I am at a total loss. I can still control Homematic from OH, but don’t receive changes anymore.
I have created an issue: [homematic] Binding does not get change events anymore from CCU3 · Issue #14126 · openhab/openhab-addons · GitHub
I think I solved it. I saw in the CCU3 log that it wants to connect to 172.17.0.1:9125, but OH runs on 192.168.0.7.
Since the last OH restart, I started the docker daemon and that adds the 172.17.x.x network to the server.
Looks like the homematic binding decided to use this network! Now that I configured the right IP address in the bridge settings, I seem to get events again!