Recently did updates to my openhabian installation and now my 2 Zooz Zen31 RGBW dimmers are reporting
HANDLER_CONFIGURATION_PENDING
{config_62_2=The value 3600.0 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disable”]], config_66_2=The value 3600.0 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disable”]]}
It looks like a few of the items, namely power reporting, default to 3600 if undefined but defining them doesn’t clear this issue. The lights will not function in this current state. Anyone experiencing similar?
No - the XML files that come from the database get compiled into the binding.
You can mess around with the JAR to add the XML manually, but this is error prone and it’s much safer to use the nightly build (it’s the same as the last release, but with an updated database).
Okay, perhaps I did something wrong or maybe the updates haven’t been pushed out yet.
I used openhabian-config to switch to the “main” branch, did updates, and restarted the openhab service but I’m still getting the handler config error. Any ideas what may have happened?
That is really not how to do it. I’m not an expert on openhabian, but I think all you did was update the main branch of openhabian. There are several ways to get the updated z-wave binding. If you want to have the OH UI z-wave, you will need to change openhabian to the “unstable” to pick up the latest 3.4 snapshot. The problem (IMO) is that you could pick up something else “unstable” and you will get bugged to update OH daily unless you revert the flag to “Testing” or “stable”. The zwave snapshots are very stable (again IMO)
What I recommend is remove the zwave binding from the UI, get the latest snapshot from here and add to your addons folder (same folder that contains the openhab-addons-3.3.0.kar). Then go into the openhab-cli console and use feature:install openhab-transport-serial
Normally that feature is installed by the UI, but it needs to be added when doing it this way. Hopefully everything will be okay in about 30 seconds. If not try a restart (I have been doing this while OH is running and it generally works).
I think there is also a way to update the binding in the console, but I have less experience with that.
Thank you @apella12! That got the lights back up and running and I didn’t need to restart the service.
Should I expect this to update in the future when the stable openhabian channel includes the database? Do I need to remove this from my addons folder to use the “new” future version?
Sure or when you need the updated DB for a new device or feature. Zwave binding is very stable.
If you go back to the UI version (say with 3.4 in December) you would need to remove the addons version.
As a final note if you upgrade to one of the milestone versions along the way, they do a “clean-cache” as part of the process, so you will have to execute the feature:install openhab-transport-serial to keep using the addons zwave binding or just go back to the UI version then (and delete the addons version.
IMO Based on the 3.3 release forum traffic/discussions, I expect 3.4M1 to be quite stable (although labeled as testing) as all the 3.3 issues will be fixed and a limited amount of new features added
Strange, I’ve updated DB again just yesterday (again?), a lot of entries had predefined value of “only” 0 which was not allowing handler to initialize with default 3600 and not allowing to set any other values.
P.s. I actually hacked my device XML by specifying 0 instead of 3600 and restarting binding but DB still need to be fixed.
It’s still marked as “Modified”, I’ve submitted it for review yesterday.
I’m not sure why “0 - Disabled” added to time update Parameters (or any other parameters actually), providing only one pre-defined value will disable possibility to set parameter and if parameter in the device is different won’t let Thing to initialize. That goes for any DB entries, not only this one.
I have a working workaround for now, no urgency for me, others might need it.
Sure, ZEN31 - Parameter 66 (“Energy report frequency”) - Default for that parameter is 3600 meaning report every hour. 0 for this Parameter means “Report Disabled”. Somebody created an option for this parameter in DB specifying “0” - “Disabled” but no other options so the only valid value for this Parameter becomes 0 and default 3600 becomes invalid during device initialization and hence the error at the head of this thread.
Unfortunately OH doesn’t have an option to specify predefined value and free value at the same time, if predefined option specified it becomes the only option and no way to change this at all, the only way out is not to specify anything at all and just in the description tell “0 means Disabled”.
For this particular DB entry this was not the only parameter with specified predefined value, I removed them as well, but this one was where Default was different from specified.
I think long time ago in OH2 era I had the same issue and had to adjust DB as well, don’t remember now which device. That’s why I’m saying when specifying “Options” / “Predefined values” it cannot be the single one otherwise it doesn’t make sense. (And testing, testing:))
You can set predefined values, and also a min/max value. For example you can set a value of 0 = disabled, and then set a min/max value of 100 to 1000, and the system will allow values of 0, and 100 to 1000 to be chosen. You must however select the “limit to options” as false - otherwise you will only be able to select the options, which seems to be the problem.
It does make sense and this is quite common in exactly the case you have here. eg setting a predefined value of (eg) disabled = 0, and then allowing other values to be set. This is normal.
Another common situation is a parameter may allow values of 0 to 100, and then use 255 as disabled. This also requires a separate value of “disabled” to be set since the value of 255 is otherwise not usable as it is outside the range of 0 to 100. Without this, you would need to specify a range of 0 to 255, but this is also wrong since the values of 101 to 254 are invalid.
I hope that makes sense. These options are definitely needed and shouldn’t be removed.
If they work that would be great to mix predefined and free but what I see it is not only restrict UI to one defined option but fail if parameter in device does not correspond to defined option. If what you saying is true we have a big bug. (And again if my memory serves we had this issue before in OH2 time).
While you will only see one option, you should be able to type in any other integer value that is within the range. I can’t test this now, but it has always worked fine in the past so I would be very surprised if it is now broken. However maybe there is a bug in the UI, or with the recent changes to the verification (although that was now quite a long time ago).
I’m not sure quite what you refer to, but this feature was added a very very long time ago. It was something that I did for Eclipse Smarthome which was the precursor to OH2.
As you can see from my screen shots there’s no other options in the GUI and not possible to type anything. But the bigger issue is that binding refusing to initialize thing cause value set in the device is not allowed in DB. I’m not sure where’s the bug and how to fix it or even where to report it.
I believe there is a timing/version issue here. What you did not identify was the date of the zwave binding you are using. Your problem was “fixed” after the OH3.3 release. It appears to me you modified the “fixed” version eliminating the option “0”. Most likely this was because your zwave version did not include the “fix”. My guess it was from the OH3.3 release. Anyway, regardless the way parameter 64 needs to be set up is either “0” or 30 - 32400. Without the “0” there is going to be a problem since the default is “0”. That one option needs to be put back. With parameter 66 without the “0” the reporting cannot be disabled, since the minimum is 30 and the core validation routine will not allow 0.
Bob
EDIT: What I would suggest is to uninstall whatever zwave binding you have and get the latest snapshot from here. It does not contain any of your edits. Drop that in the addons. If not fixed immediately, delete (not exclude) the device and inbox-zwave-scan to pick it up with the changes. Then go back and fix the Zwave DB as appropriate.
Ok, but unfortunately it’s not possible for me to see that in the screenshot - I can’t tell from that what can be typed in, or what happens if you click on something. Maybe there’s a dropdown list that appears, but a static image like this doesn’t actually tell me that.
Possibly this is the case - I’m not sure, but I agree it would be useful to better understand the issue to know what versions of OH are being used, and what binding version is being used.
Just to note that we can’t approve this until the options are restored. Please can you add these back as otherwise this will cause problems.
I really only have today and part of tomorrow available - then I’m away with limited access for the next month.
