zwave-js / zwave-js-ui

Full featured Z-Wave Control Panel UI and MQTT gateway. Built using Nodejs, and Vue/Vuetify
https://zwave-js.github.io/zwave-js-ui
MIT License
984 stars 201 forks source link

[question] Issue with Somfy Zwave-RTS II (ZRTSII) stop #2437

Closed jdiegmueller closed 2 years ago

jdiegmueller commented 2 years ago

I'm not sure if this is a zwavejs2mqtt thing or an HA thing -- hoping someone can point me in the right direction.

I have a Somy ZRTSII Zwave-to-RTS controller which remotely controls motors on window blinds. The controller itelf gets included as the "base node" and each of the 16 RTS channel (blinds & blind groups) can be optionally presented to the Zwave network as a virtual node. The virtual node is what you interact with.

From Homeassistant, cover.open_cover and cover.close_cover towards the virtual nodes work as expected. Looking at things through a Zniffer, I see a single Zwave Switch Multilevel Set message get sent out and the respective RTS channel/blinds start moving up or down accordingly. However, I'm getting undesired behavior with cover.stop_cover. When I send a cover.stop_cover, I see two Switch Multilevel Stop Level Change messages send back-to-back.

These Somfy motors have a "favorite position" concept they call My Somfy. Under the hood the way they implemented it was such that a "stop" command when the blinds are not moving up or down will recall the My Somfy position. Since cover.stop_cover to these Zwave devices result in back-to-back stops, the motors end up stopping on the first message but then changing to the My Somfy position on the second.

My setup is HomeAssistant 2022.5.5->zwavejs2mqtt 6.10.0 -> zwavejs 9.3.0.

I'm attaching a log snippet demonstrating the zwavejs2mqtt side of things. Node 168 is the virtual node in question. From Homeassistant I sent it a cover.close_cover, followed by a cover.open_cover, and then a cover.stop_cover.

Where should I be focusing my attention here? Is Homeassisant simply instructing zwavejs2mqtt to send two stops, or is zwavejs2mqtt doing that of its' own accord?

Thanks for any insight.

zwsnippet.txt

jdiegmueller commented 2 years ago

image

Different timestamps than the log, but a simple Zniffer screenshot showing how up and down are sent as single commands, but stop gets sent as a double.

kpine commented 2 years ago

You didn't actually say how you are using Z-Wave JS with Home Assistant. If you are using the Z-Wave JS integration, then you should submit an issue there. https://github.com/home-assistant/core/issues/new/choose

I assume you're using the integration, because its code sends two stop commands.

Where should I be focusing my attention here? Is Homeassisant simply instructing zwavejs2mqtt to send two stops, or is zwavejs2mqtt doing that of its' own accord?

Assuming again that you are using the integration, zwavejs2mqtt is not involved in anything here, it just provides access to the z-wave driver. You can review this documentation to get an understanding of all the pieces.

jdiegmueller commented 2 years ago

Yes, I guess it is the HA ZwaveJS integration attached to zwavejs2mqtt's websocket server. I figured the issue had to be either on this side or the HA side, and it seems you've rightly found it on the HA ZWaveJS side.

Thank you for the pointer to the specific code; armed with that knowledge, I'm fairly sure I can cook up some sort of local hack to only send stop once.

jdiegmueller commented 2 years ago

Yes, I guess it is the HA ZwaveJS integration attached to zwavejs2mqtt's websocket server. I figured the issue had to be either on this side or the HA side, and it seems you've rightly found it on the HA ZWaveJS side.

Thank you for the pointer to the specific code; armed with that knowledge, I'm fairly sure I can cook up some sort of local hack to only send stop once.

Thanks again for the pointer, I was able to hack the ZwaveJS cover integration to only send only a single stop command. Empowered with the ability to stop the up/down events, I was able to hack together a virtual cover integration for each blind group that handles position by travel time.