It’s not possible to change/update thing configuration for a Fibaro FGRGBW-442 device (RGBW CONTROLLER 2). The device is not updated and there’s only sparse information in the openHAB log:
2021-04-24 16:30:28.360 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Configuration update received
2021-04-24 16:30:28.364 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body writer has been found for class java.util.Collections$UnmodifiableMap, ContentType: /
I’m on openHAB 3.0.2 - Release Build on RaPi 4B4GB.
The device itself and the thing work, channels can be assigned to items and operated - it’s only that the configuration parameters for the thing cannot be changed from the thing screen in openHAB. As all other device types in my system work fine this is probably not an issue with the Z-wave binding, but rather a mismatch in the device declaration for the FGRGBW-442. So I checked the respective XML file on Github (fgrgbw442_0_0.xml), compared it with the operating manual from the manufacturer (FGRGBW-442-T-EN-1.1.pdf, new version btw.), link here, and found some inconsistencies, which could be reason for the trouble:
Four-byte parameters are included only with the LSB in the thing configuration: Parameters 30-34 should be four-byte parameter sets, but they are included in the XML only with the LSB (e. g. “config_31_4_000000FF: 0”) . Probably the first 3 bytes should be included in the parameter declaration as well, as it is done for other device types (e. g. zwave:fibaro_fgr223_00_000), where, for the same parameters, all four bytes are considered. Omitting part of four-byte parameters on send or receive could cause trouble.
Parameter with discrete option and value range: Parameter 35 is described in the manual as a two-byte parameter with allowed values of 0 (for infinite signalization) or 1-32400 (for duration in seconds) and a default of 600. The Thing configuration screen of openHAB reports „infinite signalization“ while the code window shows „config_35_2_0000FFFF: 600“, which is a contradiction and not in line with the manufacturers documentation. Could be a cosmetic issue though.
Four-byte parameters seem to be treated as signed integers instead of unsigned ones: Parameters 154-156 should be four-byte parameter sets with byte values from 0x00 to 0x63 (99d) or 0xff (255d) each. The Thing configuration screen of openHAB reports the MSB of parameter 154 with a value of 127d instead of 255d (config_154_4_7F000000: 127) - a value of 127d is invalid according to the manufacturers documentation, sending it to the device would probably fail. Looks like a seven-bit-mask is applied here, but could be a cosmetic issue though.
Can somebody please check this and hopefully update the device typ definition in fgrgbw442_0_0.xml? I’m willing to test, would like to get this work. Just need some advice on how to do that.
I’ve tested the changes with openHAB 3.1.0-SNAPSHOT - Build #2361 (Version of ZWave Binding 3.1.0.202105030336). The changes are ok: parameters 30-34 are now included with all four bytes in the configuration screen and also parameter 35 is ok.
However, this did not solve the initial problem, that configuration changes cannot be saved. After some more analysis I found the root cause: the reason is that the bit masks required to map out single-byte values out of a four-byte word are not correct, e. g. for parameter 154:
Byte 1 (config_154_4_000000FF): mask is 0x000000FF (LSB) - this is ok
Byte 2 (config_154_4_0000FF00): mask is 0x0000FF00 - ok as well
Byte 3 (config_154_4_00FF0000): mask is 0x00FF0000 - ok as well
Byte 4 (config_154_4_7F000000): mask is 0x7F000000 (MSB) - this is wrong, it rather should be 0xFF000000
It is not possible to maintain the required mask of 0xFF000000 for the MSB in the zwavedatabase (the „highest“ possible mask is 0x7FFFFFFF). As a consequence, parameter values for the MSB are limited to (decimal) 0-127 while values 128-255 (decimal) are not feasible.
This has no effect if such values are not used. But for parameter 154 it matters, because the initial value for all four bytes is 255. The ZWave Binding and/or the GUI cannot process this correctly and fails upon updating the configuration.
I applied the following workaround in my system to be able to update the thing configuration:
config_154_4_000000FF: value is 255 (no change)
config_154_4_0000FF00: value is 255 (no change)
config_154_4_00FF0000: value is 255 (no change)
config_154_4_7F000000: change value to 99 (0x63 in hex)
config_154_4 change value to 1677721599 (0x63FFFFFF in hex)
This is not the intended value for this parameter, but feasible.
remark: parameter config_154_4 is an advanced parameter, so „Show advanced“ needs to be checked in the maintenance screen before it can be changed.
another remark: according to Fibaro documentation the allowed byte values for the 154 parameter group are 0-99 and 255. 127, which appears in the GUI as a truncated value for 255, is not feasible for the device.
Unfortunately there are more issues with the operation of the FGRGBW-442, with conversion of HSB values and interference between dimmer and color control channels… I will describe this in a separate post.
Hi, I was also hit by this, but I cannot update to the latest OH3 snapshot (I tried and I had various issues).
Currently on 3.0 M5.
A (Sort of) workaround for this is to use the PUT command of REST API directly. The issue like you described affects only some parameters (like config_154_4) but if you need to update for example the local control time (config_151_2) you can send just this parameters and it’ll work.
So for me instead of sending the entire configuration, I ended up making a PUT to /things/{thingUID}/config with:
Hi Julien, thanks for the advise and good to learn how to set selected parameters separately, I’ll keep that in mind for future problems. However, for the bitmask issue with config_154_4 my workaround is fine, as I’m not using associations for this device.
Regarding config_151_2: I don’t really understand why the manufacturer has defined this as a 2-byte parameter as the allowed values are from 0-254, which would need only one byte. In the zwave database on opensmarthouse.org, this parameter has no bitmask defined, so I think it should work anyway with the binding? At least for me it does.
Update with OH 3.1.0: the workaround from post #3 is not needed any more, it works fine now with the default values:
config_154_4_000000FF: value is 255 (no change)
config_154_4_0000FF00: value is 255 (no change)
config_154_4_00FF0000: value is 255 (no change)
config_154_4_7F000000: value is 255 (no change)
Remark: the mask from the MSB (config_154_4_7F000000) is misleading, but not causing trouble. And the corresponding 4-byte parameter (config_154_4, accessible as an advanced parameter) is inconsistent, but not causing trouble either.
