Hi Urs,
good to hear that the problems are solved :-).
I will have a closer look at this UPDATE_PENDING warning. Maybe it is CCU2-specific, because I have never seen it in my environment (CCU3 resp. Raspberrymatic).
Cheers
Martin
Hi Martin
However, the address is clearly from my HmIP SWDM - Shutter-Contact.
This runs on my RaspberryPi4 as CCU3 under Raspberrymatic (V 3.59.6.20210703).
The RPi4 has a antenna HmIP-RFUSB.
I (as a layperson) don’t see any connection with my CCU2.
Thanks and regards, Urs
Hello,
I have the same problem in my log. Did you find out how to fix this?
The device is a HmIP-SWDM
[WARN ] [ommunicator.parser.GetParamsetParser] - Can't set value for datapoint 'XXXXXXXXXXXXXXXXX:0#UPDATE_PENDING'
AFAIK there is no solution available. It probably is caused by wrong metadata received from the CCU. Maybe a solution can be to suppress the warning.
Hi everyone,
First off, thanks for the great discussion and the work on the homematic binding.
I had similar issues as described above and some more, but found a workaround, so here goes.
First the problem itself:
I’ve experienced similar problems with the binding after updating to OH 3.1 (and meanwhile to 3.2), i.e. I got the "device-id “xyz” is not found on gateway-id “abc" error described above by @jochenfroehlich . But in addition some of my homematic things stopped updating their states, at random time intervals and, at least for me, in an unpredictable manner. Especially for door/window contacts, that’s quite problematic and it disrupts graphing and persistence based rules. This made my homematic devices close to useless in openhab, of course.
I’m very new to Openhab and also only have very rudimentary knowledge of Linux based systems, let alone programming in Java or Python.For the same reason I’m a little careful with manually installing addons etc.
I found a workaround in periodically disabling and reenabling the CCU thing via rule. I had been doing the same for weeks via the UI button, whenever I noticed the issue coming up again. This way, it’s much easier and I don’t have to monitor my system several times a day, at least.
I’m aware that manually installing the newer version of the binding is a better solution, but for newbies like me, this rule based workaround may also be a viable option, for a limited time at least. The rule itself is posted here:
Also, enabling and disabling things via rule may in itself be quite useful and I found it pretty hard to find a working solution for this in Openhab 3, since there seem to have been some changes. The REST requests for disabling/enabling things that worked in OH2 don’t work in OH 3 anymore (see above link).
Anyway, I hope this post still fits the topic here. It certainly was a revelation to get the rule running and have this automatic workaround until there is an official new version of the homematic binding available.
Keep up the great work!
RaspberryMatic (3.61.7.20220226) in binding HomeMatic (openHAB 3.3.0.M2) “homematic.things” no longer works.
With the previously used “homematic.things” file, the binding with RaspberryMatic no longer works.
Only the parts “Bridge” and “GATEWAY-EXTRAS” still work correctly.
Error message: Incorrect or missing configuration.
Remedy: Delete all HM components of the CCU3(RaspberryMatic) in the “homematic.things” file and add all components manually (in the inbox) after a first restart of the system.
After another restart everything works again…
I left the bridge and gateway extras portion; so I didn’t have to rename my “HW_HomeMatic.items” file.
PS: All HM components in the CCU2 (original) continue to work without problems.
Despite my little glitch, a big thank you to the development team (Martin) for the constant further development of the system and the HomeMatic connection.
Thanks and regards, Urs
1 Like
dear community,
I am afraid I have a similar problem with raspberrymatic and the current versions Openhab 3.3 and the corresponding Homematic Binding. Part of my things working without problems - other things will not initialize - “Error Handler”
Completely Error Message at the bottom of this text.
I tried the Workaround of Urs to delete the things in the things-file an add it manually using the inbox.
Unfortunately the same result 
I am currently using an older version of openhab without problems - but that can’t solve the problem for the future …
Does anyone have an idea what I could do to solve the problem ?
Does anyone know if there will be in near future a stable homematic binding again or should I look for alternatives to openhab for my homematic-home?
I would be grateful for any hint.
Reagrds Thomas
" HANDLER_CONFIGURATION_PENDING
{HMP_1_PIR_OPERATION_MODE=Der Wert 0 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value=“PIR_OPERATION_MODE_NORMAL”, label=“PIR_OPERATION_MODE_NORMAL”], ParameterOption [value=“PIR_OPERATION_MODE_ECO”, label=“PIR_OPERATION_MODE_ECO”], ParameterOption [value=“PIR_OPERATION_MODE_OFF”, label=“PIR_OPERATION_MODE_OFF”]], HMP_1_ATC_ADAPTION_INTERVAL=Der Wert 2 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value=“15Min”, label=“15Min”], ParameterOption [value=“30Min”, label=“30Min”], ParameterOption [value=“60Min”, label=“60Min”], ParameterOption [value=“120Min”, label=“120Min”]], HMP_2_BLOCKING_PERIOD_UNIT=Der Wert 1 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value=“100MS”, label=“100MS”], ParameterOption [value=“1S”, label=“1S”], ParameterOption [value=“5S”, label=“5S”], ParameterOption [value=“10S”, label=“10S”], ParameterOption [value=“1M”, label=“1M”], ParameterOption [value=“5M”, label=“5M”], ParameterOption [value=“10M”, label=“10M”], ParameterOption [value=“H”, label=“H”]], HMP_1_ATC_MODE=Der Wert 0 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value=“ATC_OFF”, label=“Off”], ParameterOption [value=“ATC_ON”, label=“On”]]}"
As far as I know this problem is caused by a change in OH 3.3 core. It is now checked whether the configuration settings contain allowed options or not.
What kind of device is causing this problem?
It seems to be the same problem as documented here: [homematic] HM-CC-TC Thermostat HANDLER_CONFIGURATION_PENDING due to invalid default parameters · Issue #13097 · openhab/openhab-addons · GitHub
All HMIP devices and most of the non-hmip-homematic devices will not work.
all energy measurement e.g. HM-ES-PMSw1-DR, contacts e.g. HM-Sec-SCo, diplays e.g. HM-Dis_EP-WM55 all wired components
still in operation: HM-LC-Sw1-Pl, HM-LC-Sw2-FM, and Wallswitches such as HM-PB-6-WM55
regards Thomas
Hmm, that’s strange. My components are working without any problems and I have also a HM-Sec-SCo and HM-Dis_EP.
Are you using text files to configure things and items or Main UI?
I think it would helpful if you could post your openhab.log with all the errors.
Usually I use text files (things,items,rules) for openhab. A few days ago I did a test using the main UI - exactly same result.
But that your devices are working seems to be a good news - that means I have a problem with my special configuration - may be due to all the updates in the last two years. Tomorrow I will set up a fresh system on another sd-card and make a test with the devices. I would install the openhab 3.3 an the corresponding homematic binding - or would you recommend a manual installation of the binding ?
If it doesn’t work I would come back to your offer with the log file.
regards
Thomas
Before OH 3 I also used text files for items. Then I set up everything new and configured everything in Main UI. Maybe this is the reason why I don’t have the same problems with similar devices.
Martin
It ist time now to share my personal experience with the actual version of openhab and the homematic binding. After several problems with the update to openhab 3.3 I installed a new raspberrymatic system on a clean sd-card. First the openhab image and then the homematic binding using the main ui.
In my case it is possible to use the existing configuration text-files (things, items, rules) without any problem. As far as I have tested the system it works without errors for the last 24 hours.
One exception: the hmip wall-switches (HMIP-BSM, HmIP-WRC6) are configured as switch and working online with all channels but in the main ui it is not a switch but a status ON/OFF - actually no idea why …
@MHerbst Thanks a lot - without your advices I would not have tried a new installation !
regards
Thomas
Good to hear that its working now :-).
Can you tell me the datapoints resp. channel ids that are wrong. Then I can look into the documentation and maybe I find the reason. The definition is taken from metadata received from the CCU. Especially for HmIP devices these information are sometimes faulty.
But I thin, it should be possible to define them in Main UI as switches.
Let’s speak about the HmIP-WR6:
when the channel for a button of the wallswitch is configured using the items-file
(Switch WT_1_kurz “WT_1_kurz” (gWT) [“Switch”] {channel=“homematic:HmIP-WRC6:CCU3:000B5D78A51DD3:1#PRESS_SHORT”}
it will be shown as online but not operable ist is read-only ON/OFF
when I do the configuration using the main ui - same result
when I press the hardware button - nothing happens …
during all the testing I had a short view on an error-message - but unfortunately I’m not able to reconstruct the related system configuration- may be there is something in a cache due to the text-file tests. but I copied the error: “2022-07-19 19:02:09.148 [WARN ] [ommunicator.AbstractHomematicGateway] - Datapoint is readOnly, it is not published to the gateway with id ‘CCU3’: ‘000B5D78A51DD3:1#PRESS_SHORT’”
regards
Thomas
It seems that it is not possible for the binding to create a Swich that is read-only.
I have an older HM device also with a PRESS_SHORT data point. This is correctly defined as Switch because it is not “read-only”.
I think if the item is defined as String it will work and you can use it as rule trigger. In my opinion it would be better if the binding would create a read-only switch. But I would have to look into the code to see what’s necessary to implement it.
I think I’ve found the solution outside the openhab universe. The problem was that openhab not recognize the keystroke of the wallswitch. Now I generated a normal CCU program using the WebUI of the RasperryMatic. It only ask for the keytrokes (long and short) of the wallswitch without any action. Now te CCU ist listening for the wallswitch. Result is an status change in openhab - this I can use in the rule.
IT IS WORKING NOW 
regards
Thomas
1 Like