This command class is not not fully working right.
switchmultilevelv4.SwitchMultilevelReport
Turning the device off from the hub, duration that comes back in the report is null. If the duration is not known I believe it should be 0. Same thing also happens when you turn it on.
2025-04-06 08:08:58.705 PMDRIVER all queues idle
2025-04-06 08:08:58.699 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:58.688 PMSERIAL « 0x0107013b9b98989fc6 (9 bytes)
2025-04-06 08:08:58.680 PMSERIAL « [ACK] (0x06)
2025-04-06 08:08:58.672 PMDRIVER » [REQ] [GetBackgroundRSSI]
2025-04-06 08:08:58.665 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-04-06 08:08:58.656 PMDRIVER one or more queues busy
2025-04-06 08:08:28.677 PMDRIVER all queues idle
2025-04-06 08:08:28.668 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:28.665 PMSERIAL « 0x0107013b9b9797a1f8 (9 bytes)
2025-04-06 08:08:28.662 PMSERIAL « [ACK] (0x06)
2025-04-06 08:08:28.655 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-04-06 08:08:28.648 PMDRIVER one or more queues busy
2025-04-06 08:08:08.198 PMCNTRLR [Node 043] [~] [Multilevel Switch] currentValue: 99 => 0 [Endpoint 0]
2025-04-06 08:08:08.193 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -72 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 37 - │ security class: S2_Authenticated - └─[SupervisionCCReport] - session id: 48 - more updates follow: false - status: Success - duration: 0s
2025-04-06 08:08:08.189 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:08.182 PMSERIAL « 0x011f00a8000001002b119f0325002f4518207f4cd62e345e83b44200b8007f7ff (33 bytes) - 4
2025-04-06 08:08:04.358 PMDRIVER all queues idle
2025-04-06 08:08:04.356 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -72 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 36 - │ security class: S2_Authenticated - └─[SupervisionCCReport] - session id: 48 - more updates follow: true - status: Working - duration: 3s
2025-04-06 08:08:04.352 PMDRIVER « [REQ] [SendDataBridge] - callback id: 188 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 100 kbit/s - routing scheme: LWR - ACK RSSI: -71 dBm - ACK channel no.: 0 - TX channel no.: 0
2025-04-06 08:08:04.344 PMSERIAL « 0x010401a90152 (6 bytes)
2025-04-06 08:08:04.341 PMSERIAL « [ACK] (0x06)
2025-04-06 08:08:04.246 PMDRIVER » [Node 043] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 188 - └─[Security2CCMessageEncapsulation] - │ sequence number: 56 - │ security class: S2_Authenticated - └─[SupervisionCCGet] - │ session id: 48 - │ request updates: true - └─[MultilevelSwitchCCSet] - target value: 0
2025-04-06 08:08:04.239 PMSERIAL » 0x012200a90001002b149f033800477e826026b843a207feb6de672f398c2500000 (36 bytes) - 000bcbf
2025-04-06 08:08:04.228 PMDRIVER one or more queues busy
2025-04-06 08:08:04.210 PMDRIVER all queues idle
2025-04-06 08:08:04.204 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:04.196 PMSERIAL « 0x011f00a8000001002b119f0323005d21c59d8e274ed0040827d89f00b8007f7f0 (33 bytes) - b
2025-04-06 08:08:04.184 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:04.183 PMSERIAL « 0x011d00a9bb00000100b87f7f7f7f00000300000000030100007f7f7f7f7f37 (31 bytes)
2025-04-06 08:08:04.169 PMSERIAL » [ACK] (0x06)
2025-04-06 08:08:04.163 PMSERIAL « 0x010401a90152 (6 bytes)
2025-04-06 08:08:04.151 PMSERIAL » 0x012200a90001002b149f033700ce56403850467900cc0dea7d15753b3f2500000 (36 bytes) - 000bbc2
In prior tests when using the physical switch the duration was working. Now though it seems that is also broken.
That value of 6 reported is while it is still in transition and you can see the duration being reported in the zwave logs.
2025-04-06 08:12:50.471 PMSERIAL » [ACK] (0x06)
2025-04-06 08:12:50.465 PMSERIAL « 0x012000a80000010021129f03310076ca93479d9cb7cf45ff3204284d00bd007f7 (34 bytes) - fad
2025-04-06 08:12:44.234 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -72 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 52 - │ security class: S2_Authenticated - └─[MultilevelSwitchCCReport] - current value: 99 - target value: 99 - duration: 0s
2025-04-06 08:12:44.229 PMCNTRLR [Node 043] [~] [Multilevel Switch] currentValue: 6 => 99 [Endpoint 0]
2025-04-06 08:12:44.223 PMCNTRLR [Node 043] [~] [Multilevel Switch] duration: {"value":3,"unit":"s [Endpoint 0] - econds"} => {"value":0,"unit":"seconds"}
2025-04-06 08:12:44.218 PMCNTRLR [Node 043] [~] [Multilevel Switch] targetValue: 99 => 99 [Endpoint 0]
2025-04-06 08:12:44.213 PMSERIAL » [ACK] (0x06)
2025-04-06 08:12:44.208 PMSERIAL « 0x011f00a8000001002b119f033400d5327514efe5dc969e2b84b82300b8007f7f0 (33 bytes) - f
2025-04-06 08:12:40.195 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -77 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 51 - │ security class: S2_Authenticated - └─[MultilevelSwitchCCReport] - current value: 6 - target value: 99 - duration: 3s
2025-04-06 08:12:40.191 PMCNTRLR [Node 043] [~] [Multilevel Switch] currentValue: 0 => 6 [Endpoint 0]
2025-04-06 08:12:40.187 PMCNTRLR [Node 043] [~] [Multilevel Switch] duration: {"value":0,"unit":"s [Endpoint 0] - econds"} => {"value":3,"unit":"seconds"}
2025-04-06 08:12:40.181 PMCNTRLR [Node 043] [~] [Multilevel Switch] targetValue: 0 => 99 [Endpoint 0]
2025-04-06 08:12:40.177 PMSERIAL » [ACK] (0x06)
2025-04-06 08:12:40.172 PMSERIAL « 0x011f00a8000001002b119f0333007264c8447c8297b5ad85ee013b00b3007f7fd (33 bytes) - 5
2025-04-06 08:12:32.889 PMDRIVER all queues idle
2025-04-06 08:12:32.882 PMSERIAL » [ACK] (0x06)
2025-04-06 08:12:32.878 PMSERIAL « [ACK] (0x06)
2025-04-06 08:12:32.872 PMDRIVER » [REQ] [GetBackgroundRSSI]
2025-04-06 08:12:32.869 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-04-06 08:12:32.861 PMDRIVER one or more queues busy
Ok After futzing with it a bit I got the duration to come back when I physically use the paddle. Not sure if this is useful.
The zwave logs only show the original report with the 3s duration from the device, but looks like the report showing 99 with duration 0 is sent afterwards, is that normal?
2025-04-06 08:19:02.870 PMDRIVER one or more queues busy
2025-04-06 08:18:44.138 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -76 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 69 - │ security class: S2_Authenticated - └─[MultilevelSwitchCCReport] - current value: 99 - target value: 99 - duration: 0s
2025-04-06 08:18:44.132 PMCNTRLR [Node 043] [~] [Multilevel Switch] currentValue: 6 => 99 [Endpoint 0]
2025-04-06 08:18:44.129 PMCNTRLR [Node 043] [~] [Multilevel Switch] duration: {"value":3,"unit":"s [Endpoint 0] - econds"} => {"value":0,"unit":"seconds"}
2025-04-06 08:18:44.125 PMCNTRLR [Node 043] [~] [Multilevel Switch] targetValue: 99 => 99 [Endpoint 0]
2025-04-06 08:18:44.120 PMSERIAL » [ACK] (0x06)
2025-04-06 08:18:44.114 PMSERIAL « 0x011f00a8000001002b119f034500bbba8fd7372d32697867f6fe9000b4007f7f8 (33 bytes) - 1
2025-04-06 08:18:40.136 PMDRIVER « [Node 043] [REQ] [BridgeApplicationCommand] - │ RSSI: -73 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 68 - │ security class: S2_Authenticated - └─[MultilevelSwitchCCReport] - current value: 6 - target value: 99 - duration: 3s
2025-04-06 08:18:40.131 PMCNTRLR [Node 043] [~] [Multilevel Switch] currentValue: 0 => 6 [Endpoint 0]
2025-04-06 08:18:40.118 PMCNTRLR [Node 043] [~] [Multilevel Switch] duration: {"value":0,"unit":"s [Endpoint 0] - econds"} => {"value":3,"unit":"seconds"}
2025-04-06 08:18:40.110 PMCNTRLR [Node 043] [~] [Multilevel Switch] targetValue: 0 => 99 [Endpoint 0]
2025-04-06 08:18:40.098 PMSERIAL » [ACK] (0x06)
2025-04-06 08:18:40.087 PMSERIAL « 0x011f00a8000001002b119f03440096bd2595ef6b99f31e9a428f1e00b7007f7f3 (33 bytes) - e
1 Like
It has been this way for a long time, on zipgateway too. I actually check for null in my drivers to determine if I should use targetValue or currentValue when updating because some devices don't send another report when the transition is complete.
Yes.. ZWaveJS reports the currentValue as what the targetValue was set to after the transition time. For the reason above.
But this driver works 100% fine on ZIP. I will have to switch back to that and get some logs. So either ZIP is also sending the follow up report, or the device is only on ZIP for some reason.
@bcopeland using ZIP
From the paddle, I am getting both the 3s duration and the 0s duration repots back. You seemed to indicate that ZIP would not do this? But it appears to behave the same as JS
I tapped paddle off, then on again.
Commanded off then on again from hub. Duration comes through as 0. My driver works as expected. I have never seen a null value come through on ZIP for duration.
So is this a breaking change on ZWJS and we need to account for a null duration, or will this be fixed so it comes through as 0?
2 Likes
