Zoos Zen52 LR Double Relay Page Widget does not respond to relay switch change

[apella12 (Bob Eckhoff)]

That could be trouble. Two things

1. Since you are using Debug (Good idea - I was going to suggest it). Post the full unfiltered openhab log for the time period of one switch. I don’t need the event log. I want to see why that EP 1 event is not being reflected in the widget. The DB update should have fixed that. I was going to use the Zwave log viewer here(it color codes thing and only looks at zwave debug).

2. When you paste log, activate the </> and put log in them.

2025-12-19 11:42:15.172 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SWITCH_BINARY, value=02025-12-19 11:42:15.283 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_BINARY, value=02025-12-19 11:42:15.392 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=1.0

Edit: the scene trouble is that the same number is sent for both on and off;

Edit: Here is a random idea. Unlink the items from the switch channels and relink them to see if that picks up the endpoint

[Uberschmutzer (Neil Levine)]

Tried unlinking and linking- no change.

2025-12-19 14:37:53.078 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 01 01 25 03 FF FF 00 00 BC A0 
2025-12-19 14:37:53.079 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 01 01 25 03 FF FF 00 00 BC 
2025-12-19 14:37:53.080 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 01 01 25 03 FF FF 00 00 BC 
2025-12-19 14:37:53.080 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:53.080 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:53.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:53.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:53.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 1
2025-12-19 14:37:53.081 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:53.081 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2025-12-19 14:37:53.081 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 26: Switch Binary report, value = 255
2025-12-19 14:37:53.082 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:53.082 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SWITCH_BINARY, value=255
2025-12-19 14:37:53.082 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:switch_binary1 to ON [OnOffType]
2025-12-19 14:37:53.082 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:53.082 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1491261a.
2025-12-19 14:37:53.083 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.083 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.083 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:53.083 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2025-12-19 14:37:53.188 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 00 01 25 03 FF FF 00 00 BC A1 
2025-12-19 14:37:53.189 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 25 03 FF FF 00 00 BC 
2025-12-19 14:37:53.189 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 25 03 FF FF 00 00 BC 
2025-12-19 14:37:53.189 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:53.191 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:53.191 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:53.191 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:53.191 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 0
2025-12-19 14:37:53.191 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:53.192 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2025-12-19 14:37:53.192 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 26: Switch Binary report, value = 255
2025-12-19 14:37:53.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:53.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_BINARY, value=255
2025-12-19 14:37:53.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:switch_binary to ON [OnOffType]
2025-12-19 14:37:53.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:53.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@23d08442.
2025-12-19 14:37:53.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.194 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:53.194 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2025-12-19 14:37:53.286 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 00 01 5B 03 27 80 01 00 BB 7E 
2025-12-19 14:37:53.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 5B 03 27 80 01 00 BB 
2025-12-19 14:37:53.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 5B 03 27 80 01 00 BB 
2025-12-19 14:37:53.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:53.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:53.288 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:53.289 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:53.289 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0
2025-12-19 14:37:53.289 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:53.289 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_CENTRAL_SCENE V3 CENTRAL_SCENE_NOTIFICATION
2025-12-19 14:37:53.289 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 26: Received scene 1 at key 0 [Single Press]
2025-12-19 14:37:53.290 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:53.290 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=1.0
2025-12-19 14:37:53.290 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:scene_number to 1.0 [DecimalType]
2025-12-19 14:37:53.290 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:53.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@7aeef197.
2025-12-19 14:37:53.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:53.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:53.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2025-12-19 14:37:57.542 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 01 01 25 03 00 00 00 00 BC A0 
2025-12-19 14:37:57.544 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 01 01 25 03 00 00 00 00 BC 
2025-12-19 14:37:57.545 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 01 01 25 03 00 00 00 00 BC 
2025-12-19 14:37:57.545 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:57.547 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:57.547 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:57.547 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:57.547 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 1
2025-12-19 14:37:57.547 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:57.548 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2025-12-19 14:37:57.548 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 26: Switch Binary report, value = 0
2025-12-19 14:37:57.548 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:57.548 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SWITCH_BINARY, value=0
2025-12-19 14:37:57.548 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:switch_binary1 to OFF [OnOffType]
2025-12-19 14:37:57.548 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:57.548 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5129c329.
2025-12-19 14:37:57.548 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.549 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.549 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:57.549 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2025-12-19 14:37:57.653 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 00 01 25 03 00 00 00 00 BC A1 
2025-12-19 14:37:57.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 25 03 00 00 00 00 BC 
2025-12-19 14:37:57.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 25 03 00 00 00 00 BC 
2025-12-19 14:37:57.656 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:57.656 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:57.656 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:57.656 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:57.656 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_SWITCH_BINARY, endpoint 0
2025-12-19 14:37:57.656 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:57.656 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_SWITCH_BINARY V1 SWITCH_BINARY_REPORT
2025-12-19 14:37:57.656 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 26: Switch Binary report, value = 0
2025-12-19 14:37:57.657 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:57.657 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_BINARY, value=0
2025-12-19 14:37:57.657 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:switch_binary to OFF [OnOffType]
2025-12-19 14:37:57.657 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:57.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@4c159ee0.
2025-12-19 14:37:57.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:57.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2025-12-19 14:37:57.749 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 1A 09 60 0D 00 01 5B 03 28 80 01 00 BC 76 
2025-12-19 14:37:57.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 5B 03 28 80 01 00 BC 
2025-12-19 14:37:57.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=26, callback=0, payload=00 01 1A 09 60 0D 00 01 5B 03 28 80 01 00 BC 
2025-12-19 14:37:57.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2025-12-19 14:37:57.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2025-12-19 14:37:57.751 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2025-12-19 14:37:57.751 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2025-12-19 14:37:57.752 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0
2025-12-19 14:37:57.752 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2025-12-19 14:37:57.752 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_CENTRAL_SCENE V3 CENTRAL_SCENE_NOTIFICATION
2025-12-19 14:37:57.752 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 26: Received scene 1 at key 0 [Single Press]
2025-12-19 14:37:57.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2025-12-19 14:37:57.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CENTRAL_SCENE, value=1.0
2025-12-19 14:37:57.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:18364cd37a:node26:scene_number to 1.0 [DecimalType]
2025-12-19 14:37:57.753 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2025-12-19 14:37:57.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6b40e1b4.
2025-12-19 14:37:57.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2025-12-19 14:37:57.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2025-12-19 14:37:57.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

[apella12 (Bob Eckhoff)]

Very odd. The log clearly shows endpoint 1 state being changed (as well as the root). When you are on the ui page, you might need to refresh? I wasn’t expecting to see the state update line.

Edit this is what working looks like. Not sure what else to do. Maybe take the controller out of the association groups (except 1)

Edit: This may not work since it should be working now, but back on the scene idea; A rule: when Scene Item updated, run a poll to retrieve the device state. “MyItem.sendCommand (“REFRESH”)” that will ping the device and return the state of all linked channels to items

[Uberschmutzer (Neil Levine)]

I refreshed the ui page, no change. By the way I use the same widget in many places, all have working properly up to now.

Here’s the UID of switch 1: zwave:device:18364cd37a:node26:switch_binary1 which matches.

Taken from:

I copied the UID from the Relay on the thing page: zwave:device:18364cd37a:node26

I tried to write a rule, here’s the code (don’t really know what I’m doing):

configuration: {}
triggers:
  - id: "1"
    configuration:
      thingUID: zwave:device:18364cd37a:node26
    type: core.ThingStatusUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: ZW_N26_ZEN52LR_Backyard_Lights_and_Fountain_Dual_Relay_Switch_1
      command: REFRESH
    type: core.ItemCommandAction

Is this what you had in mind? If so, It did not seem to help anything.

Not sure what you mean by run a poll.

Thanks for all your ideas and the time you’ve spent. I’m willing to try all suggestions should you have more.

Pretty much at my wit’s end on this. I thought this would be straight forward.

[apella12 (Bob Eckhoff)]

From zwave everything looks good, so I don’t know what else to do for now. Do take the controller out of the Association groups 2 and 3 however for good order. I believe that is the source of the EP0 update. It could be causing a conflict and at best it is not helping anyway. TBH I thought this would be easy. The linking the command classes has solved all the problems like this I have supported (except yours )

Yes REFRESH is a special OH command to update via a poll all attached channels. I can’t comment on the code for my reasons mentioned earlier. However, you should see logs in the event folder that a REFRESH was sent. Also could follow the Refresh progress via zwave debug.

[Uberschmutzer (Neil Levine)]

I’ve been running without the controller in groups 2 and 3 all along but have tried putting it back in those groups at various times with no change in behavior. Just checked again and the controller is not in groups 2 and 3.

I have seen refresh in the logs but have disabled that rule for now since it didn’t seem to help.

Would updating to a more recent version of OpenHAB be useful? Wouldn’t want to update far from the 4.1.3 I’m running since updating can be a can of worms in itself.

Could you debug better if you had a ZEN52 device? I could possibly send you mine as a loaner. Don’t know if you could fire up the same version I’m running to eliminate different versions as a variable.

[apella12 (Bob Eckhoff)]

@Uberschmutzer

Could you debug better if you had a ZEN52 device? I could possibly send you mine as a loaner. Don’t know if you could fire up the same version I’m running to eliminate different versions as a variable.

Thanks for the offer, but I don’t see the problem doesn’t appear to be in the zwave binding ATM. Also it could be something with OH, but as you note, upgrading could be a problem. You could try to remove orphans in karaf.

openhab:links orphan <list|purge>	lists/purges all orphaned - one missing element (either item or channel) - link

As a last resort you could exclude the device (Unlink all channels first) factory reset (if there is that option) and reinclude as new node to see if starting from total scratch would change anything.

[Uberschmutzer (Neil Levine)]

I performed the exclusion and inclusion and discovered something that may help solve this.

I found the UI widget responds to each local switch properly when the channel point profiles are set to DEFAULT. Each relay operates independently when the local switches are toggled. However, when I use the UI widgets to turn on relay 1, relay 2 also turns on which is not want I want.

If I set the channel point profiles to FOLLOW, the local switches do not trigger a change in the UI widget (as I saw before because I did have it set to FOLLOW) but now the relay 1 and relay 2 UI widgets are not linked anymore and independently operate the relays.

Any ideas on how to deal with this new information and get the operation I require?

[Nadahar (Nadar)]

@Uberschmutzer

If I set the channel point profiles to FOLLOW, the local switches do not trigger a change in the UI widget (as I saw before because I did have it set to FOLLOW)

It sounds to me like FOLLOW behaves like it’s supposed to - it’s basically a one-way operation.

What the correct design is, I’m not sure of, I’m not even sure I fully understand how you want it to work, but I think that a rule (or two) is probably required.

[apella12 (Bob Eckhoff)]

I have never used FOLLOW, but it is part of your issue. In the docs it says, “In the direction from the ThingHandler towards the Item, this Profile ignores state updates.” This explains how Zwave can look correct (and is with state updates), but the OH widget state doesn’t get updated. I think the best approach is to use default and try to figure out how to operate independently. Worst case would be a rule as suggested above to override unwanted behavior.

A couple of questions:

1. Did you purge orphans?

2. If you use relay 2 does relay 1 go on, or is it just with relay 1 that relay 2 goes on?

A couple of things:

1. I have been bothered why there is a state update on the root when you did the manual test. If there is no channel link or item that should not happen. That is why I asked about orphans. They are known to cause problems. With the default profile, can you run the test with manual again?

2. Sometimes the root mirrors EP1, but from the zooz docs and your comments it seems to control both EP1 and EP2. That is why I asked about relay 2 actions with the widget (just to make sure)

3. The other problem with Zooz devices is they don’t technically follow the ZW spec. When a command is sent the device should not return a message. The command poll (at the bottom of UI page) is supposed to ask for the device state after 1.5 seconds. I’m going to need a Debug test with widget 1 (or two if it shows the same issue). I suspect the root is getting a secondary message and turning on the other light.

4. Test basics: No item linked to root, no controller in grp2 or 3, no orphans, debug EDIT: The Association grp will send to the controller root since there are no controller EPs and the controller may take that as a command somehow back to the device. Need to eliminate all the complexities

5. Goal as I understand it is to operate each relay independently

[Uberschmutzer (Neil Levine)]

Orphans were purged and none are listed with the links orphan list command.

With both relays off, and both widgets OFF, click widget 1, relay1 turns on, and both widgets turn ON. Then if I click widget 1 again, both widgets turn OFF, relay 1 turns off and relay 2 stays OFF.

If I click relay 2 widget, relay1 is not affected, and the relay 2 widget resets itself to OFF and relay 2 turns on. If I click on widget 2 (now OFF) widget 2 goes ON for about a second (found this delay is adjusted by Command Poll Period) but relay 2 stays on. If I click widget 2 again before widget resets to OFF, relay 2 will go off.
This is pretty bizarre and confusing…

Behavior became more what I expected as I increased Command Poll Period to max (defaults to 1500) which appears to be 15000, so I set it to 0, hoping that this essentially sets it to infinity or in other words disables this.

Once I did this, I get the operation I want, 2 independent relays with UI updates. Still don’t know if this is the long term solution. Very confusing and have no idea why the Command Poll Period has this effect.

Happy to hear comments and explanations, will be doing more testing tomorrow.

[apella12 (Bob Eckhoff)]

Command poll at 0 is disabled and should be fine (particularly since it works for you ).

As I mentioned above (3). Zooz devices typically send a confirming message without a command poll. You can check the debug log to make sure.

1. With relay 1 the mirroring of EP1 and EP0, together with EP0 controlling both relays is probably causing the problem. It might be possible to fix if you want to keep playing with it. You could try changing parameter 24 back to zero first. I would need debug logs to see exactly. Since it doesn’t happen without a command poll active I don’t quite get it. I also still don’t get why there is a state update on an unlinked channel. One thought is to remove the channel from the XML entirely, but changing that in the ZW DB might mess someone else up that is using that channel to turn on both devices.

2. With relay 2, if you are using the same item, just linked to the new channel, all that sounds like auto update particularities. Turn that back on or remove metadata (I think the default is on) and see if that will make a difference with the command poll on. The widget is not reflecting the relay state

Edit: also, may want to revert toggle switch type (parameter 20, 21) for testing. I don’t think they were an issue and it is unusual to have 2 toggle versions. I’m not sure how they are handled by the device.

[Uberschmutzer (Neil Levine)]

Now that the issue with the switch independence has been solved and I got the double relay installed and working in the metal switch box in the backyard (thought I’d need to modify the ZEN52 with an antenna external to the box, but it works without it!) I’ve just run into another issue.

Early on in this topic, I had modified the ZWave binding with a new .jar file as directed by apella12. I’m not sure if that was part of the solution or not, but that’s what’s being used currently in my 4.1.3 build.

Today I tried to add remote control of the relay via one of the ZEN37 4 button remote, l went to modified the ZEN37 parameters but the thing was empty of parameters. Then I remembered that this was an issue when I first used the ZEN37 about 1 1/2 years ago:

Zooz Zen37 Not recognized

Is anyone successfully using the zooz zen37 wall remote? I can bind it to the Zwave network but there are no switch functions available since the device is not recognized. Any suggestions?

I was directed to use a version SNAPSHOT for 4.3.0 and do a bundle update which fixed the issue. However, since I updated my current 4.3.0 with the modified .jar file, I lost the fix for the ZEN 37.

Is this .jar fix still available so I can run it or should I use a different one?

bundle:update 264 https://ci.openhab.org/job/openHAB-ZWave/lastSuccessfulBuild/artifact/target/org.openhab.binding.zwave-4.3.0-SNAPSHOT.jar

Or do I use a different file to update my 4.1.3 distribution now?

[apella12 (Bob Eckhoff)]

You might consider upgrading if you have a lot of newer devices…

When you do bundle:update the revised bundle is stored in a separate location. When you did bundle:update with the Zen52, it overwrote the fix from 2024. Even if the OH4.3 snapshot was available an update would overwrite the zen52 fix.

If I understand correctly, what you need to do is get the Zen52 modified jar and add Zen37 in addition, then bundle:update like before.

zen37800lr_0_0.xml (13.7 KB)

[Nadahar (Nadar)]

Let me add that this is what the add-on I made should shine at: providing device definitions separately from the JAR. It doesn’t work well if it has to “fight with the JAR” about the same definition, but when the definition isn’t in the JAR, it should be pretty much perfect. It’s available to install from the marketplace, but it’s still tagged with “beta” so I’m not sure if you must enable some option for it to be visible.

[Uberschmutzer (Neil Levine)]

@apella12

You might consider upgrading if you have a lot of newer devices…

I’m on 4.1.3. What is the highest new version I could update to that would cause the least amount of issues from my current version?

[apella12 (Bob Eckhoff)]

4.1.3. What is the highest new version I could update to that would cause the least amount of issues from my current version?

No idea, sorry. For now, just try adding the xml either with the beta tool or like you did with zen52.

Edit: one idea is to look at docker and spin up an isolated OH 5.1. You might be able to copy your files. If it fails you still have your current setup. Both can’t run at the same time unless you resolve ports

[justaoldman (Justan Oldman)]

Hi so here is another option you might consider
Are you running Openhab as windows service? If so disable it in services and stop openhab.
you do not have to do docker things if you are running OpenHab in windows.
All you need to do is copy the entire openhab directory to a new folder (right click openhab folder (left click show more options) then (left click copy) then right click again (then left click show more options) then left click paste. Now you will have a complete copy of your openhab rename the openhab-copy folder to a different name like openhab_BU

This gives you a complete backup of your existing openhab install fully functional and completely unmessed with you can go back to and run it from the start.bat file.
from here you have 2 options you can upgrade the back up install you just created or upgrade you original either will work fine. just can not run both at same time.
If you upgrade your original and you are running openhab as a service it will all work fine on upgrade and start as a service seamless. if you upgrade the backup copy and decide you want to use it as your version then you will need to redo your windows as a service wrapper build to point the service to the new folder location. .
Or if you decide it all works like you want then upgrade the original install and service will work then.
with windows everything openhab all lives inside that main folder and you can have as many installed versions as you want (as long as each different version is in its own separate folder!). You just need to only run one at a time. and also make sure you have the correct version of JAVA set in your environment variables for the version of OpenHAB you are running (yes you can also have more than one version of java installed as well again in separate folder and configured in the path statement). You just need to make sure your environment variables are pointing to the correct path of java version for java_home. that OpenHAB needs for its specific java version requirements.
If it was me I would upgrade the copy to 4.3.8 and see if all your stuff works as expected. This will get you the later jar you had before you replaced it.
Then if all works you could make a second additional backup of original install for regression testing (or sanity thought process of how things used to work) and upgrade your original install and enable the service.
either way adding docker when you are running a windows install is just extra variables to deal with you may not want to deal with the extra overhead when all you need is to copy a folder IMHO.

I do this all the time on my lab windows install and switch back and forth between many different version of OpenHAB when I am testing things to make sure things scripts widgets rules etc. all work fine before I touch my production environment.
Finally, just give the one finger (click) delete salute to folders (installs) you don’t need and move on.