Configuration parameters not getting set in Z-Wave device (GE Fan Control ZW4002)

caparomula · March 27, 2019, 4:08pm

Platform information:
- Hardware: x64/8GB/SSD
- OS: Debian 9
- Java Runtime Environment: OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
- openHAB version: 2.4
Issue of the topic: Setting “LED always off” for parameterName=config_3_1 does nothing
Please post configurations (if applicable): Using Aeotec Z-Stick Gen5
If logs where generated please post these here using code fences:

Using Paper UI, I selected “LED always off” under “Configuration Parameters -> 3. Night light”. This resulted in the following log message:

20:30:15.234 [INFO ] [smarthome.event.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=config_3_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]

The setting sticks in Paper UI until I restart openhab, and then it reverts back to the default state. In any event, the configuration change is not being reflected in the actual hardware because the LED light stays on regardless.

Any suggestions on how to further debug this issue? Or does anyone have a solution?

Thanks!

5iver · March 27, 2019, 5:34pm

In general, it is much better to use Habmin for anything zwave related. Specifically, configuration parameters are handled MUCH better in Habmin, as it updates just the parameter you are configuring, where Paper UI will send all configuration parameters. There may be encountering another issue, but check if Habmin behaves better for you.

caparomula · March 27, 2019, 9:07pm

Thanks for the suggestion. I tried setting the configuration via HABmin, but the result is the same. The UI displays “pending…” after I click save, and that never goes away. It seems like openhab is not receiving an acknowledgment from the device, which makes sense because it seems the device is not seeing the configuration request?

5iver · March 27, 2019, 9:20pm

You’ll need to set the logging for the binding to debug and set the parameter to know for sure. There were also updates in December, I do not know what they were, which would not be in the version you are using. And the device db entry is reporting issues. I don’t think this will be a problem, but I could be wrong. Either way, it should get cleaned up.

caparomula · March 28, 2019, 12:33am

I did

log:set debug org.openhab.binding.zwave

and then issued the configuration request from HABmin. I grepped the logs for “NODE 24”, which is the device in question. The output follows. Does it make any sense to you? It looks to me like the configuration request was acknowledged, and then the configuration was retrieved and it was still at the default?

2019-03-27 20:19:11.604 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Configuration update received

2019-03-27 20:19:11.618 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Configuration update set config_3_1 to 2 (BigDecimal)

2019-03-27 20:19:11.622 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 24: Creating new message for application command CONFIGURATION_SET

2019-03-27 20:19:11.624 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: SECURITY not supported

2019-03-27 20:19:11.625 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured

2019-03-27 20:19:11.626 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Adding to device queue

2019-03-27 20:19:11.628 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Added 191 to queue - size 1

2019-03-27 20:19:11.634 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 24: Sending REQUEST Message = 01 0C 00 13 18 05 70 04 03 01 02 25 80 2C 

2019-03-27 20:19:11.644 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 24: Creating new message for application command CONFIGURATIONCMD_GET

2019-03-27 20:19:11.645 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: SECURITY not supported

2019-03-27 20:19:11.646 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured

2019-03-27 20:19:11.647 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Adding to device queue

2019-03-27 20:19:11.649 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Added 192 to queue - size 1

2019-03-27 20:19:11.659 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 24: sentData successfully placed on stack.

2019-03-27 20:19:11.660 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: TID 191: Transaction not completed

2019-03-27 20:19:12.055 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 24: SendData Request. CallBack ID = 128, Status = Transmission complete and ACK received(0)

2019-03-27 20:19:12.056 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: resetResendCount initComplete=true isDead=false

2019-03-27 20:19:12.057 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Response processed after 419ms

2019-03-27 20:19:12.059 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: TID 191: Transaction completed

2019-03-27 20:19:12.059 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: notifyTransactionResponse TID:191 DONE

2019-03-27 20:19:12.061 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

2019-03-27 20:19:12.065 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 24: Sending REQUEST Message = 01 0A 00 13 18 03 70 05 03 25 81 2F 

2019-03-27 20:19:12.208 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 24: sentData successfully placed on stack.

2019-03-27 20:19:12.210 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: TID 192: Transaction not completed

2019-03-27 20:19:12.255 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 24: SendData Request. CallBack ID = 129, Status = Transmission complete and ACK received(0)

2019-03-27 20:19:12.256 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: resetResendCount initComplete=true isDead=false

2019-03-27 20:19:12.257 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: TID 192: Transaction not completed

2019-03-27 20:19:12.330 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Application Command Request (ALIVE:DONE)

2019-03-27 20:19:12.333 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: resetResendCount initComplete=true isDead=false

2019-03-27 20:19:12.334 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint 0

2019-03-27 20:19:12.335 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 24: SECURITY not supported

2019-03-27 20:19:12.335 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 24: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT

2019-03-27 20:19:12.336 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 24: Node configuration report, parameter = 3, value = 0, size = 1

2019-03-27 20:19:12.337 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent

2019-03-27 20:19:12.337 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CONFIGURATION, value = org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@8d10820

2019-03-27 20:19:12.338 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Update CONFIGURATION 3/1 to 0

2019-03-27 20:19:12.339 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Commands processed 1.

2019-03-27 20:19:12.340 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3ea04e9b.

2019-03-27 20:19:12.341 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3ea04e9b.

2019-03-27 20:19:12.341 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 24: notifyTransactionResponse TID:192 DONE

2019-03-27 20:19:12.342 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

elcheekytico · March 29, 2019, 6:05pm

I am having the same issue with my fan switches, same model. This works with all of my dimmers. Here I grepped the log of everything ZWave while attempting to set the LED to off. I just upgraded to 2.4, but this was occurring with 2.3 as well. I just never got around to posting here about it. Maybe @chris can shed some light.

2019-03-29 13:52:52.575 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Configuration update received
2019-03-29 13:52:52.607 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Configuration update set config_3_1 to 2 (BigDecimal)
2019-03-29 13:52:52.610 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 7: Creating new message for application command CONFIGURATION_SET
2019-03-29 13:52:52.613 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
2019-03-29 13:52:52.615 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2019-03-29 13:52:52.622 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Adding to device queue
2019-03-29 13:52:52.625 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Added 3490 to queue - size 1
2019-03-29 13:52:52.628 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-03-29 13:52:52.642 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 7: Sending REQUEST Message = 01 0C 00 13 07 05 70 04 03 01 02 25 56 E5
2019-03-29 13:52:53.424 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-03-29 13:52:53.427 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-03-29 13:52:53.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 3490: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.430 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-03-29 13:52:53.432 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-03-29 13:52:53.435 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3490: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.434 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 7: Creating new message for application command CONFIGURATIONCMD_GET
2019-03-29 13:52:53.436 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2019-03-29 13:52:53.437 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2019-03-29 13:52:53.439 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-03-29 13:52:53.438 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
2019-03-29 13:52:53.441 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.441 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-03-29 13:52:53.441 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2019-03-29 13:52:53.444 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.445 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Adding to device queue
2019-03-29 13:52:53.447 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3490: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.449 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Added 3491 to queue - size 1
2019-03-29 13:52:53.452 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 56 00 00 02 BF
2019-03-29 13:52:53.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-03-29 13:52:53.458 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=86, payload=56 00 00 02
2019-03-29 13:52:53.458 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-03-29 13:52:53.460 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3490: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.463 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.469 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 3490: Advanced to WAIT_REQUEST
2019-03-29 13:52:53.471 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: TID 3490: Transaction not completed
2019-03-29 13:52:53.474 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=86, payload=56 00 00 02
2019-03-29 13:52:53.476 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3490: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.487 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-03-29 13:52:53.489 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3490: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 86
2019-03-29 13:52:53.492 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 3490: (Callback 86)
2019-03-29 13:52:53.494 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2019-03-29 13:52:53.497 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 3490: callback 86
2019-03-29 13:52:53.499 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=86, payload=56 00 00 02
2019-03-29 13:52:53.513 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: resetResendCount initComplete=true isDead=false
2019-03-29 13:52:53.516 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 3490: Transaction COMPLETED
2019-03-29 13:52:53.517 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Response processed after 89ms
2019-03-29 13:52:53.519 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: TID 3490: Transaction completed
2019-03-29 13:52:53.521 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: notifyTransactionResponse TID:3490 DONE
2019-03-29 13:52:53.524 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-03-29 13:52:53.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-03-29 13:52:53.528 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-03-29 13:52:53.535 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 7: Sending REQUEST Message = 01 0A 00 13 07 03 70 05 03 25 57 E6
2019-03-29 13:52:53.537 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-03-29 13:52:53.539 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 3491: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.539 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-03-29 13:52:53.541 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-03-29 13:52:53.546 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2019-03-29 13:52:53.544 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-03-29 13:52:53.550 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3491: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.551 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2019-03-29 13:52:53.553 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-03-29 13:52:53.554 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.556 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-03-29 13:52:53.558 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.561 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3491: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.563 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-03-29 13:52:53.563 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 57 00 00 02 BE
2019-03-29 13:52:53.565 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3491: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.568 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-03-29 13:52:53.569 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=87, payload=57 00 00 02
2019-03-29 13:52:53.572 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 3491: Advanced to WAIT_REQUEST
2019-03-29 13:52:53.575 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: TID 3491: Transaction not completed
2019-03-29 13:52:53.576 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 07 05 70 06 03 01 00 86
2019-03-29 13:52:53.578 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=87, payload=57 00 00 02
2019-03-29 13:52:53.580 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 3491: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.582 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-03-29 13:52:53.583 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 05 70 06 03 01 00
2019-03-29 13:52:53.584 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 3491: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 87
2019-03-29 13:52:53.586 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 3491: (Callback 87)
2019-03-29 13:52:53.589 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2019-03-29 13:52:53.591 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 3491: callback 87
2019-03-29 13:52:53.594 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=87, payload=57 00 00 02
2019-03-29 13:52:53.599 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: resetResendCount initComplete=true isDead=false
2019-03-29 13:52:53.600 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 3491: Advanced to WAIT_DATA
2019-03-29 13:52:53.603 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: TID 3491: Transaction not completed
2019-03-29 13:52:53.606 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=7, callback=0, payload=00 07 05 70 06 03 01 00
2019-03-29 13:52:53.608 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-03-29 13:52:53.610 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Application Command Request (ALIVE:DONE)
2019-03-29 13:52:53.613 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: resetResendCount initComplete=true isDead=false
2019-03-29 13:52:53.615 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint 0
2019-03-29 13:52:53.617 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 7: SECURITY not supported
2019-03-29 13:52:53.620 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 7: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT
2019-03-29 13:52:53.622 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 7: Node configuration report, parameter = 3, value = 0, size = 1
2019-03-29 13:52:53.625 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
2019-03-29 13:52:53.627 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CONFIGURATION, value = org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@2ba835
2019-03-29 13:52:53.629 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Update CONFIGURATION 3/1 to 0
2019-03-29 13:52:53.632 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Commands processed 1.
2019-03-29 13:52:53.634 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@f3faa5.
2019-03-29 13:52:53.636 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@f3faa5.
2019-03-29 13:52:53.638 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 7: notifyTransactionResponse TID:3491 DONE
2019-03-29 13:52:53.641 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-03-29 13:52:53.643 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2019-03-29 13:52:53.645 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-03-29 13:52:53.647 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-03-29 13:52:53.649 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

chris · March 29, 2019, 6:21pm

From this log, the issue seems to be that the device is not accepting the configuration command -:

This shows the binding is sending the data ok (value 2), but when the value is read back, it’s got a value of 0.

This might be because the length is wrong? It is sending 1 byte - maybe this is incorrect. Alternatively, maybe the parameter number is incorrect?

There’s nothing wrong in the binding as such, but I would check that the database is correctly configured for this parameter.

elcheekytico · March 29, 2019, 6:47pm

Is there something I need to do I my end?

chris · March 29, 2019, 6:49pm

Yes - if you can check the manufacturers manual, or whatever information is available to try to answer the above questions -:

5iver · March 29, 2019, 6:50pm

Zwave Alliance shows 4 versions of this device, and not all of them have CONFIGURATION. Also, this doc from Jasco, which seems to line up with the product version inthe device db, shows that this parameter only has two options, 0 and 1.

It looks to me that that there are several versions of this device, and only one in the device db. @caparomula and @elcheekytico, what is the SKU of your device and what is the firmware version?

elcheekytico · March 29, 2019, 7:38pm

I’m not at home right now and would have to pull them out of the wall anyways. I looked at my purchase history and they all seem to be 14287 which is the one in the doc you linked from Jasco. Seems as though this only supports inverting the switch

Looks like 14314/ZW4002 supports disabling the LED

elcheekytico · March 29, 2019, 7:44pm

@caparomula @chris @5iver Just found a forum post for SThings that they weren’t able to do it either with this model. Seems you can do it via button presses.

I’ll try this when I get home tonight.

caparomula · March 29, 2019, 9:18pm

Mine are 14287/ZW4002. Firmware, reported by HABadmin is 5.22. I tried the On-On-On-Off key press sequence and it worked! It took a few tries --you have to get the timing just right. So I’m happy they are off, but am still willing to help debug the configuration set parameter any way I can.

Thanks for all the help!

5iver · March 29, 2019, 9:32pm

Worked in what way? I thought you were trying to set the parameter to 2, which would completely disable the LED. My understanding is that the LED on these devices (at least 14287/ZW4002) cannot be completely turned off, but the device db includes that option in parameter 3. Or did the manual config turn them off completely?

I’m thinking that the device db needs to be cleaned up by separating these devices based on firmware.

caparomula · March 29, 2019, 9:48pm

Sorry, I should have been more specific. By using the button press sequence I was able to get the blue led light to turn off manually, independent of z-wave.

According to HABadmin, the configuration parameter “3. Night Light” still reads “LED on when switch is OFF”, even after restarting openhab to clear any cached state, so there’s definitely a disconnect between what openhab sees and the hardware behavior. I don’t have the technical expertise to know where the issue is. Is there some sort of zwave device dump I can run that would enumerate the actual parameters the device exposes?

I’m guessing by your previous posts that an assumption is made based upon some model identification that the unit has attributes described in an offline device database?

elcheekytico · March 29, 2019, 10:18pm

I just tried it on mine. It changed the LED to on when he switch is on. I tried other combinations, but nothing else worked. That being said I agree we should clean up the DB. My only concern is that this option may not be configurable, based on the information we’ve see so far.

caparomula · March 29, 2019, 10:23pm

Yeah, mine is the same: LED is off when switch is off, but LED is on when switch is on. Not the setting I want, but better than always on.

5iver · March 29, 2019, 10:28pm

Yes… the configuration parameters are part of the device database that I linked to in my second post. It seems to me that the entry for this device needs an update, but there may be some models where this is configurable as in the current entry. We just need to start getting feedback on the SKU and firmware that people have and how their devices are reacting with the binding.

Maybe one of you could look up the manuals for all of the various models to list the differences? At the least, we should make a note in the db entry about the current findings to help in troubleshooting this when others run into it. Maybe just in the options for parameter 3.

caparomula · March 30, 2019, 12:19am

I was going to add a comment to the database but the security code capcha at the bottom of the entry form isn’t rendering.

chris · March 30, 2019, 9:54pm

It should if you are logged in.