(in English: “251 - the value must be smaller or equal to 127”)
When I change to value from 251 to e.g. 1 and press “Save”, then the Web UI does not complain, but the openhab logfile shows:
2021-01-02 12:43:35.685 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 63: Configuration update received
2021-01-02 12:43:35.713 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body writer has been found for class java.util.Collections$UnmodifiableMap, ContentType: */*
Remarks:
251 is the negative value -5.
I was able to change parameter 201 in a 2.x version of openHAB
Taken from the documentation of the device:
This parameter is an offset in two byte representation: the high byte is the value of the desired offset and in the low byte the unit is coded with “1” for Celsius and “2” for Fahrenheit. So there are two defaults really, “1” for european and australian devices and “2” for american devices.
The range for the parameter is -128 to 127 for the offset itself, the unit needs to be considered seperately as far as I see it and needs to be either “1” or “2”, other values are not valid.
Just did a check (have that device myself): the two halves of the parameter are seperated in the database, meaning one can set them independently in the GUI. I did two tests, one with a valid unit and another with an invalid unit and in both cases I get the same message (in events.log, not in openhab.log):
And the GUI checks the value for the offset correctly. If one changes it with the up/down arrows, the value cannot be changed into the invalid areas, that can only be done by entering the value manually but will result in an error message as described by Gert.
For the unit valuas other than 1 or 2 are possible using the up/down arrows.
Not in this case. If you want to have an offset of -0,5 degrees you need to adjust the value actually to -5. It works in my setup, regardless of the message in events.log
First of all - thank you very much for your quick responses!!
Just to be sure that I get the right understanding, please let me try to come back on the 251 value: when I click on the device in the Web UI, then the following is shown in the “Thing” tab:
When after this I replace the 251 for “Temperature Calibration Value” with 0 (or other values) the error appears and no further action is accomplished:
2021-01-02 15:33:40.085 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 63: Configuration update received
2021-01-02 15:33:40.119 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body writer has been found for class java.util.Collections$UnmodifiableMap, ContentType: */*
That was a device database issue I just now corrected. In the future it will be limited to options.
Will this device database update also correct the problem with the “Temperature Calibration Value”?
It should work, but I’m not really sure what is happening. The debug log ought to print more than this - or alternatively there could be an exception printed somewhere in the logs?
Gert, is your screenshot of the parameter 201 in any form cut or is is complete? If it is complete I see a difference to my setup: Both fields show up and down arrows to adjust the values. These seem to be missing in your case. So we have a difference:
I spent quite some time trying to reproduce the problem. The problem can be reproduced, however the behaviour seems occasionally to be deviating; not sure what causes the deviations.
Here the easiest way to reproduce:
Step 1: set “Temperature Calibration Value” to 0. Then press “Save” and wait till the “Pending” disappears (for me sometimes I have to click to another thing and back to get the “Pending” updated).
Step 2: set “Temperature Calibration Value” to a negative value, e.g. -5. Then press “Save” wait till the “Pending” disappears (again for me sometimes I have to click to another thing and back to get the “Pending” updated):
Step 3: Press “Save” again, without updating any field
-> there is a short message “Thing updated” in a black box in the left bottom corner -> the -1279 and the 251 appear
This is part of your problem: your device is a battery device and is only able to accept config changes during wakeup. That is the reason for the pending mark.
After you saved the changes you need to wake your battery device (or wait for automatic wakeup), then the pending mark will disappear.
As sihui already mentioned, changes only take effect when battery driven devices wake up and “talk” to the controller.
My ZW100 are powered with the USB option instead of batteries. But there is a difference between your screenshots and mine: yours show three fields for parameter 201 where mine only show two (which I think should be the correct way so noone is confused with the combined field). I’ve tested it with PaleMoon brwoser and with Firefox, the screenshot shows the Firefox view:
This is part of your problem: your device is a battery device and is only able to accept config changes during wakeup. That is the reason for the pending mark.
After you saved the changes you need to wake your battery device (or wait for automatic wakeup), then the pending mark will disappear.
Sure, only after a device wakeup the config parameters will be set.
The issue with the display of “Pending” is: when I press “Save”, finally the device does wake up and the new configuration value is set in the device (and ‘get’ from the device again), then the “Pending” sometimes does not disappear. In that case only when I click to some other information in the Web UI and then back, then the “Pending” has disappeared.
Besides, I wait for the next automatical device wakeup which takes several minutes; during that time I change browser tabs and do some other work; maybe the browser (I use Chrome) decides to ‘put at rest’ the openHAB Tab? Just a guess.
Well, I belive that “Pending update” issue is just another issue, which I think is unrelated to the problem of negative values for the “Temperature Calibration Value”. I would need to open another thread for the “Pending update” issue.
I followed your step by step test in my setup to reproduce the outcome but WITHOUT the “advanced option” being active as I wanted to eliminate a possible influence from the third field. And as you wrote, in step 3 the value “251” is shown instead of “-5”. Which leads me to suspect that somewhere in the chain negative values are calculated/represented in a diffent way than expected in the GUI.