Me either. But the log clearly shows 00 00 being sent in the SET, and reported back from the device in the REPORT.
Try using HABmin to set the parameter. Or, as @5iver suggests look in the browser dev tools to see what’s being sent in the REST API.
Here are the relevant lines from the log. The second line clearly shows parameter 6 being set to 0.
I don’t know what the At build null means…
2018-07-29 21:00:52.882 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set action_reinit to false
2018-07-29 21:00:52.900 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set config_6_2 to 0
2018-07-29 21:00:52.919 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 4: Creating new message for application command CONFIGURATION_SET
2018-07-29 21:00:52.938 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
Ignore it - it’s related to transaction management and not the data that is sent.
Is Habmin packaged with 2.4 snapshots compatible with the dev version of the binding from this topic ? If not, where can I donwload the compatible jar for Habmin ?
By the way, I will check with Firefox tools what REST API are called by Paper UI.
And thank you for the quick analysis.
Yes
I can see that all parameters are of this kind config_X_1 lexcept the 6th which is the one I am trying to set which is config_6_2. Is it normal ?
NODE 4: Configuration update set config_1_1 to 99
NODE 4: Configuration update set config_2_1 to 99
NODE 4: Configuration update set config_6_2 to 0
NODE 4: Configuration update set config_7_1 to 0
NODE 4: Configuration update set config_8_1 to 0
NODE 4: Configuration update set config_3_1 to 99
NODE 4: Configuration update set config_4_1 to 99
NODE 4: Configuration update set config_5_1 to 99
Yes, it’s normal. The 2 indicates it’s a 2-byte parameter. The other parameters are 1-byte.
Edit: You can see the word sizes in the db entry for this device.
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/31
I’ve had a few Fibaro Dimmers (FGD-212) working pretty fine. These had firmware 3.4.
I’ve added another, which happens to have firmware 3.5 (although not sure this is significant) and the Scene numbers don’t appear to be being received by Openhab (configuration parameter is set on device).
In the log for the good dimmers I see:
2018-08-15 11:05:51.185 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: Incoming command class COMMAND_CLASS_SCENE_ACTIVATION, endpoint 0
2018-08-15 11:05:51.187 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 3: Received COMMAND_CLASS_SCENE_ACTIVATION V0 SCENEACTIVATION_SET
For the not working I see:
2018-08-15 11:10:48.230 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: Incoming command class COMMAND_CLASS_SCENE_ACTIVATION, endpoint 0
2018-08-15 11:10:48.231 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 12: Command class COMMAND_CLASS_SCENE_ACTIVATION not found.
Any ideas?
Edit: just seen some similar issues earlier in the thread. Looks like I need to make sure I’m running the latest binding and re-include. The strange thing is, I think the only factor changing is the device firmware version. The software versions I’m using haven’t been changed since I set up with the existing dimmers…
Cheers.
There’s a separate database entry for devices with the 3.5 firmware, so that could be the cause for why the 3.5 device is being handled differently.
Up to version 3.4
Version 3.5 and later
Both database entries have an entry for SCENE_ACTIVATION in endpoint 0, so it’s not obvious to me why it’s not being handled for the 3.5 device.
Yes, it’s best to be on the latest version. Note that you do not need to reinclude the device. Just delete the Thing and then rediscover it.
It looks like SCENE_ACTIVATION was added in a commit on June 26. If your version is older than that, then you need to pick up the latest version of the binding.
Ah thanks for this. That at least gives a factor on the Openhab side for the differing behaviour…
Yep, chris added it because I had encountered & reported that issue, too.
I think my zwave stick my have died, \ trying to figure out how I can tell for sure 
I have been running 2.3.0.201805192224 for a few weeks now without issue. Sometime within the past few days, my zwave devices have stopped responding.
BasicUI shows the zwave controller as OFFLINE and I see multiple messages in the logs that look rather ominous:
8-15 08:07:03.642 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 31: Command received zwave:device:15bfa0704b9:node31:switch_binary → OFF
2018-08-15 08:07:03.642 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Controller handler not found. Cannot handle command without ZWave controller.
2018-08-15 08:11:05.037 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - ZWave product zwave:serial_zstick has no references!
2018-08-15 08:11:05.037 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - ZWave product zwave:device has no references!
2018-08-15 08:11:05.043 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - ZWave product zwave:serial_zstick has no references!
2018-08-15 08:11:05.043 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - ZWave product zwave:device has no references!
I did some basics checks to ensure ttyUSB0 is showing on the filesystem, restarted openhab, restarted the machine, but the behavior is consistent.
Here’s the full log
Thanks in advance
Hi Dave,
There’s nothing at all being received from the device as far as I can see, so either it’s dead, or there’s a serial port issue or something fundamental like that…
Chris
@mstormi, @digitaldan - are your systems still holding up? Have you had any more Queue Full issues? If not, I might merge the hold-off code as previously I think you weren’t going more than a day without this issue showing up?
Yes, mine’s running fine since I installed your Aug12th binding 2 days ago and yes, with holdoff-enabled versions before I got ‘queue full’ after 24hrs at most. What do you mean by ‘merge holdoff’ now - isn’t that already in there ?
At the moment it’s not merged into the development branch - it’s still part of this PR -:
Yes things look very good, no issues performance wise . As for the threads, I went ahead and installed the most recent version with thread naming , there definitely is a pattern with nodes above a certain number getting stuck during the heal phase , just hopped on a plane but as soon as I have a ssh connection I will post another thread dump and log file.
Updating the binding resolved the Scene Number issue with the firmware version 3.5 Fibaro dimmer.
The bit I don’t understand is that the new “thing” (with version 3.5 firmware) always had the “Scene Number” channel even before I installed the updated binding. My expectation would be if this was missing from the database for the version 3.5 firmware then it should be entirely missing as a channel?