StopLevelChange sending twice with ZwaveJS

📢 Feedback
,
1

I'm using the stop level change command in my Somfy ZRTSI driver and after upgrading to ZwaveJS it has broken.

hubitat/somfy-zrtsi/somfy-zrtsi.driver.groovy at master · augoisms/hubitat · GitHub

sendToDevice(zwave.switchMultilevelV3.switchMultilevelStopLevelChange())

It appears that the command is sent twice. This results in the MY position not working as the first command starts movement and the second command stops it.

Can someone on the Hubitat team take a look please? Thank you.

@bobbyD

2 Likes
2

Tagging @bcopeland

3 Likes
3

How does this function ever result in movement starting?
The only command being send to the device is to stop.

void myPosition() {
	logDebug "myPosition()"
    sendToDevice(zwave.switchMultilevelV3.switchMultilevelStopLevelChange()) 
	sendOpeningClosingEvent(50)
	runIn(travelDuration, 'sendEvents', [data: [level:50]]);
}
4

It's a quirk of this particular device. If the window shade is not moving and it receives the StopLevelChange command, then it moves to the pre-programmed "MY" position. If the shade is currently moving it will stop the movement.

5

Typically sending it twice would have no impact which is probably why it has gone unnoticed.

Anyway... I think it would be useful if you opened to the z-wave logs and then run the command again. Then copy and paste the resulting zwave logs into a code block in a reply.

6

I didn't realize there were z-wave logs, thanks for that.

Not sure how to interpret these yet, but I am seeing MultilevelSwitchCCStopLevelChange twice

2025-06-03 02:48:35.216 PMDRIVER all queues idle
2025-06-03 02:48:35.212 PMDRIVER « [REQ] [SendDataBridge] - callback id: 4 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -63 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-06-03 02:48:35.209 PMSERIAL » [ACK] (0x06)
2025-06-03 02:48:35.206 PMSERIAL « 0x011d00a90400000100c17f7f7f7f01010300000000020100007f7f7f7f7ff0 (31 bytes)
2025-06-03 02:48:35.201 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-06-03 02:48:35.193 PMSERIAL » [ACK] (0x06)
2025-06-03 02:48:35.191 PMSERIAL « 0x010401a90152 (6 bytes)
2025-06-03 02:48:35.186 PMSERIAL « [ACK] (0x06)
2025-06-03 02:48:35.184 PMDRIVER » [Node 072] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 4 - └─[MultilevelSwitchCCStopLevelChange]
2025-06-03 02:48:35.180 PMSERIAL » 0x011000a9000100480226052500000000040f (18 bytes)
2025-06-03 02:48:35.176 PMDRIVER one or more queues busy
2025-06-03 02:48:35.172 PMDRIVER all queues idle
2025-06-03 02:48:35.165 PMDRIVER « [REQ] [SendDataBridge] - callback id: 3 - transmit status: OK, took 10 ms - routing attempts: 1 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: LWR - ACK RSSI: -63 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-06-03 02:48:35.161 PMSERIAL » [ACK] (0x06)
2025-06-03 02:48:35.157 PMSERIAL « 0x011d00a90300000100c17f7f7f7f01010300000000020100007f7f7f7f7ff7 (31 bytes)
2025-06-03 02:48:35.152 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-06-03 02:48:35.150 PMSERIAL » [ACK] (0x06)
2025-06-03 02:48:35.147 PMSERIAL « 0x010401a90152 (6 bytes)
2025-06-03 02:48:35.142 PMSERIAL « [ACK] (0x06)
2025-06-03 02:48:35.140 PMDRIVER » [Node 072] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 3 - └─[MultilevelSwitchCCStopLevelChange]
2025-06-03 02:48:35.135 PMSERIAL » 0x011000a90001004802260525000000000308 (18 bytes)
2025-06-03 02:48:35.132 PMDRIVER one or more queues busy
7

I found this same thing for MultilevelSwitchCCSet which I posted over in beta for anyone who has access you can see the whole thread.

Just trying this two reports together.

8

@bobbyD @bcopeland Has this been issue been acknowledged yet and in the pipeline for fixing? I've had to implement a hacky workaround in my driver where I send my own commands twice to make this work. Thanks.

9

This appears to be a ZWave-JS code issue.. I am able to reproduce on the version that is out there, but I am testing a newer version that doesn't have this same issue.

3 Likes
10

That's good news. Thanks for the update!

2 Likes
11

12

Observed similar trigger "Echos". The triggering device logs shows a single event but the rule log showed a second trigger event ~ 250ms after the first which caused my dimmer level logic to misbehave. Forced me into private boolean to block triggers until the end of the rule plus a little delay ducking that second trigger.