Utec Ubolt Pro Zwave Stuck Adding/Deleting Pins
Opened this issue · 2 comments
Describe the bug
Similar to what some others have experienced in a thread about the Kwik lock, enabling codes displays a status of "Adding" indefinitely. Manually initiating the keymaster refresh codes service works to push the codes and then they work.
Environment (please complete the following information):
- OS: [e.g. HassOS
- Type of system that HA is running on: Proxmox VM
- Home Assistant version: 2024.6.0
- Core
- Component version: v0.0.95
- Z-Wave integration name: zwave_js
- Lock make and model: Utec Ubolt Pro Zwave
Logs
Subscribed to Z-Wave JS log messages…
2024-06-08T15:45:29.196Z DRIVER all queues busy
2024-06-08T15:45:29.202Z DRIVER » [Node 019] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 121
└─[Security2CCMessageEncapsulation]
│ sequence number: 80
│ security class: S2_AccessControl
└─[SupervisionCCGet]
│ session id: 51
│ request updates: true
└─[UserCodeCCSet]
user id: 1
id status: Enabled
user code: ******
2024-06-08T15:45:29.212Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-06-08T15:45:30.694Z DRIVER « [REQ] [SendDataBridge]
callback id: 121
transmit status: OK, took 1480 ms
repeater node IDs: 2
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -77 dBm
ACK RSSI on repeaters: -87 dBm
ACK channel no.: 1
TX channel no.: 1
route failed here: 2 -> 19
2024-06-08T15:45:31.183Z DRIVER « [Node 019] [REQ] [BridgeApplicationCommand]
│ RSSI: -77 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 130
│ security class: S2_AccessControl
└─[SupervisionCCReport]
session id: 51
more updates follow: false
status: Success
duration: 0s
2024-06-08T15:45:31.186Z DRIVER all queues idle
2024-06-08T15:45:36.189Z DRIVER all queues busy
2024-06-08T15:45:36.193Z DRIVER » [REQ] [GetBackgroundRSSI]
2024-06-08T15:45:36.199Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -96 dBm
channel 1: -105 dBm
channel 2: -105 dBm
channel 3: -90 dBm
2024-06-08T15:45:36.205Z DRIVER all queues idle
2024-06-08T15:46:06.190Z DRIVER all queues busy
2024-06-08T15:46:06.195Z DRIVER » [REQ] [GetBackgroundRSSI]
2024-06-08T15:46:06.203Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -95 dBm
channel 1: -105 dBm
channel 2: -105 dBm
channel 3: -90 dBm
2024-06-08T15:46:06.207Z DRIVER all queues idle
2024-06-08T15:46:08.191Z DRIVER all queues busy
2024-06-08T15:46:08.200Z DRIVER » [Node 019] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 122
└─[Security2CCMessageEncapsulation]
│ sequence number: 81
│ security class: S2_AccessControl
└─[UserCodeCCGet]
user id: 1
2024-06-08T15:46:08.209Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-06-08T15:46:09.676Z DRIVER « [REQ] [SendDataBridge]
callback id: 122
transmit status: OK, took 1460 ms
repeater node IDs: 2
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -77 dBm
ACK RSSI on repeaters: -85 dBm
ACK channel no.: 1
TX channel no.: 1
route failed here: 2 -> 19
2024-06-08T15:46:09.778Z DRIVER « [Node 019] [REQ] [BridgeApplicationCommand]
│ RSSI: -78 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 131
│ security class: S2_AccessControl
└─[UserCodeCCReport]
user id: 1
id status: Enabled
user code: ******
2024-06-08T15:46:09.780Z DRIVER all queues idle
2024-06-08T15:46:09.790Z DRIVER all queues busy
2024-06-08T15:46:09.797Z DRIVER » [Node 019] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 123
└─[Security2CCMessageEncapsulation]
│ sequence number: 82
│ security class: S2_AccessControl
└─[UserCodeCCGet]
user id: 2
2024-06-08T15:46:09.804Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-06-08T15:46:09.887Z DRIVER « [REQ] [SendDataBridge]
callback id: 123
transmit status: OK, took 80 ms
repeater node IDs: 2
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -77 dBm
ACK RSSI on repeaters: -87 dBm
ACK channel no.: 1
TX channel no.: 1
2024-06-08T15:46:09.989Z DRIVER « [Node 019] [REQ] [BridgeApplicationCommand]
│ RSSI: -77 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 132
│ security class: S2_AccessControl
└─[UserCodeCCReport]
user id: 2
id status: Enabled
user code: ****
2024-06-08T15:46:09.991Z DRIVER all queues idle
2024-06-08T15:46:14.637Z DRIVER all queues busy
2024-06-08T15:46:14.646Z DRIVER » [Node 019] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 124
└─[Security2CCMessageEncapsulation]
│ sequence number: 83
│ security class: S2_AccessControl
└─[SupervisionCCGet]
│ session id: 52
│ request updates: true
└─[UserCodeCCSet]
user id: 2
id status: Available
user code: ****
2024-06-08T15:46:14.653Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-06-08T15:46:14.697Z DRIVER « [REQ] [SendDataBridge]
callback id: 124
transmit status: OK, took 40 ms
repeater node IDs: 2
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -77 dBm
ACK RSSI on repeaters: -87 dBm
ACK channel no.: 1
TX channel no.: 1
2024-06-08T15:46:15.350Z DRIVER « [Node 019] [REQ] [BridgeApplicationCommand]
│ RSSI: -77 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 133
│ security class: S2_AccessControl
└─[SupervisionCCReport]
session id: 52
more updates follow: false
status: Success
duration: 0s
2024-06-08T15:46:15.356Z DRIVER all queues idle
2024-06-08T15:46:19.631Z DRIVER all queues busy
2024-06-08T15:46:19.638Z DRIVER » [Node 019] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 125
└─[Security2CCMessageEncapsulation]
│ sequence number: 84
│ security class: S2_AccessControl
└─[SupervisionCCGet]
│ session id: 53
│ request updates: true
└─[UserCodeCCSet]
user id: 2
id status: Enabled
user code: ****
2024-06-08T15:46:19.648Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-06-08T15:46:19.690Z DRIVER « [REQ] [SendDataBridge]
callback id: 125
transmit status: OK, took 40 ms
repeater node IDs: 2
routing attempts: 1
protocol & route speed: Z-Wave, 40 kbit/s
routing scheme: LWR
ACK RSSI: -77 dBm
ACK RSSI on repeaters: -87 dBm
ACK channel no.: 1
TX channel no.: 1
2024-06-08T15:46:20.264Z DRIVER « [Node 019] [REQ] [BridgeApplicationCommand]
│ RSSI: -77 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 134
│ security class: S2_AccessControl
└─[SupervisionCCReport]
session id: 53
more updates follow: false
status: Success
duration: 0s
2024-06-08T15:46:20.267Z DRIVER all queues idle
2024-06-08T15:46:36.190Z DRIVER all queues busy
Additional context
You can see in the zwave log what seems like a failure to communicate to the lock (route failed here: 2 -> 19) when ticking Enable in the lovelace UI, however manually activating the service everything works fine every time.
As a workaround, I created an automation:
Trigger: input_boolean.enabled_frontdoor_2
Any state change initiates the automation.
Then do: keymaster.refresh_codes
That has everything working. Can the refresh codes service be added to the underlying component? Perhaps with a setting to enable this functionality if you experience a similar issue?
+1 to this issue. This is also a fairly big security problem, as for the Utec Ubolt Pro Zwave devices you can't delete the codes while it is stuck in this pending state.