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

1 Like
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