I have 11 Qubino Flush Shutter modules, that I use in Venetian Blind mode.
At the moment, I’m still using the old OZW 1.4 integreation “in production”, but currently preparing the move to Z-Wave JS on my “test platform”.
By checking the functionalities of one module with Z-Wave JS integration, I have seen a behavior change in the cover entities created by HA.
Let’s say the cover is closed (position 0) : When I set the position to “100”, the cover moves up as expected. The problem is, that the reflected state of the cover directly changes to position “0”, before the move is finished.
It’s like HA doesn’t wait anymore on the feedback of the module to reflect the status of the cover.
In Z-Wave JS Web dashboard, I see that the state feedback is coming as expected from the module at end of the shutter move operation, so I don’t think Z-Wave JS is the problem here.
Has anyone an explanation about that ? and a workaround or solution ?
Closing or opening a cover is done by setting a position: position 0 is off and position 99 is open. The default behavior for node-zwave-js is to assume the command is going to succeed, so it sends an immediate optimistic value. When you set position 99, it responds to HA with the current value as 99. The same Z-Wave commands are used to set brightness for Z-Wave light switches. I think this behavior is due to (mostly) HA user complaints about light switches toggling between off and on in the HA UI because not all devices send immediate updates or transition quickly enough. Sending the fake optimistic value works around this, of course it’s bad for covers.
One solution is to disable this behavior but it requires a custom node-zwave-js configuration, which means you’re either using zwavejs2mqtt or the zwave-js-server manually, no addons. The setting is also global, which means it affects lights and other similar devices.
Still struggling with that “by design” behavior. Didn’t migrate yet away from the legacy OZW1.4 integration because of that.
I have no way making my scripts work in a “proper way”: setting the tilt on a venetian blind often comes after an up or down move of the venetian blind. Without a proper handling of the acknowledgment (move requested → moving → move is finished), I cannot use a condition in the script to set my sequences of moves as I’m doing now with the legacy Z-Wave integration
Show stopper for me.
I believe it depends on the firmware version on the Qubino Roller Shutter modules (and any other Qubino devices generally how and when they report things)
I think the set value and current value has just been recently separated, so you need to set the device to report back at the end of the motion and the current value then updates.
I tried ZwaveJS with a Qubino Roller Shutter and it provides two entities. A switch and a cover. The switch you can use to open and close, I believe it sends a basic set command with 00 or FF. You need to define in the device configuration what FF means for the device, either last open position or fully open. The cover entity has the slider and the up/stop/down buttons. The slider should send multi level switch commands, the up/stop/down I don’t know how is working exactly. But the device needs to have the group associations set to report back correctly.
If I look at the DEBUG in the Z-Wave JS Configuration while trigger an UP move of one of my test Qubino cover module, we can clearly see that the module sends back its state after the move. But it’s unfortunately not used in the HA entity as it used to be with the OZW 1.4.
Hey @gucki,
Coming back one year later, nothing seems to have changed there. I just did a full upgrade of my setup, and my venetian blinds Qubino modules are still showing this “update to early” behavior…
Not using MQTT for these blinds (as in your workaround), but are you aware of any (new) settings in zwavejs2mqtt to correct this behavior ?
Isn’t that a thing from the device itself? I mean it updates the value meanwhile still moving? Or is it the value updates as you send the command?
In theory you send the command, the device reacts, does the move, and once finished it send the reach value.
Have you set your groups correctly that the device would report the latest value when reached? Qubino has tracked history of misbehaving firmwares on early devices, which cannot be even updated OTA.
I tackle a similar situation that I start move the blind, wait 60 seconds force an update request, and once that is good act on it.
