Somfy Shades via zrtsi <> zwavejs2mqtt <> zwave-js ws issue w/ "cover.stop_cover"

have a weird issue here w/ the cover.stop_cover on the following configuration:

  • Somfy Shades using RTS
  • Somfy ZRTSI zwave<>RTS controller
  • zwavejs2mqtt:
  • zwave-js: 7.7.3
  • HASS - 2021.6.5

the biggest issue is when i issue the cover.stop_cover command it seems to send 2 MultilevelSwitchCCStopLevelChange commands each time (based off the zwavejs logs). having come from ST and then Hubitat i’m more used to a system which you have more visibility into custom devices etc so i’m a bit lost here. so i’m not sure if it is a zwavejs issue or a where the device drivers lie…

I think I’m running into something similar. Did you ever figure this out?

nope. my workaround was to enable mqtt and use a direct mqtt command in my scripts that i use to set a room’s shades to the preset spot.

for my shades i used the zwavejs web control to find the command for the preset call which was zwave/L2/Master_Bedroom_Shade_Left/38/0/Up/set in mqtt

You’ve lost me a bit there. You can use mqtt to control the zwave blinds? I have the same setup as you as far as I can tell, but I’m pretty ignorant when it comes to mqtt. Any guidance or can you point me to some documentation?

The stop cover command implemented by the integration sends both an Up and Down command. Submit a bug if it’s wrong.

1 Like

@nervling -
ah sure. i can try… i’m using zwave-js as part of the zwavejs2mqtt project installation. Since i knew i could issue the stop/home command from the zwave-js web control panel i decided to figure out how to integrate MQTT into my setup to send that command directly - i am also now running a mosquitto MQTT server to support this and any future MQTT related things i decide to do.

caveat: my setup is … not standard. i’m running a standalone zwavejs2mqtt and a standalone HASS setup on MACOS but the concepts should work in other HASS installations - i just don’t know how to make them happen.

i’m not sure that this is what the code is showing? it appears to send an “up stop” when the cover is opening and a “down stop” when the cover is closing. whereas my expectation was that it would just send a stop command when i hit the stop button. (my shades use the stop button as both a ‘stop motion’ and also a ‘go to preset position’ command.

The code I linked is for the cover.stop_cover command for zwave_js, and it sends two MultilevelSwitchCCStopLevelChange commands. “Up” with false or “Down” with False do the same thing, which is to issue the StopLevelChange command, and explains why you saw two of them in the logs. There is no such thing as “up stop” or “down stop” commands, there is a single Stop command for any ongoing transition no matter the direction. The Z-Wave JS API is translating what you see in that code to a Stop command. “Up” or “Down” with True instead issue StartLevelChange commands with those directions. It’s just a bit of an awkward API.

I suggested you submit a bug if you think issuing two Stop commands is wrong, because you seem to be affected by it, and otherwise it won’t get fixed. Personally, I think there was a misunderstanding with the code because it was basically a copy and paste from the OZW integration which had the same behavior, but that was a workaround due to a poor API.

Is there actually some problem resulting from the two stop commands? You didn’t mention anything except that you saw the two log messages. EDIT: n/m saw your last message.

fwiw what I found on mine was the stop_cover command was somehow triggering the “my position” setting in somfy, which corresponds with hitting the stop button twice on my somfy remote.

I don’t actually need favorite positions, so I cleared them and it fixed the problem for me (I think).

Thanks @spikenheimer, I need to do some research on use mqtt with zwavejs. I’m already running a docker for mqtt and zwavej2smqtt, so it shouldn’t be too hard, and I have another reason for wanting the finer control of mqtt.

If anyone is looking to use the “MY” functionality for Somfy ZRTSI and struggling with cover_stop not behaving as expected, the secret appears to be to trigger a Z-Wave Command Class API service call, with:

command class = 38
method name = stopLevelChange
parameters = []

This is now working for me :slight_smile: