Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

zwaveJS: Closed status applied twice to cover when sending close command (on starting and completing the command) #47950

Closed
hauserbv opened this issue Mar 15, 2021 · 14 comments
Closed

zwaveJS: Closed status applied twice to cover when sending close command (on starting and completing the command) #47950

hauserbv opened this issue Mar 15, 2021 · 14 comments
Labels
integration: zwave_js stale

Comments

@hauserbv
Copy link

The problem

After the change from Zwave 1.4 to zwaveJS I noticed a change in behaviour.

When a cover (= Fibaro FGR222) is closed, the close status comes twice.

  • first immediately when the command is issued by an automation
  • second when the cover is actually closed
    in between it is detected that the cover is not closed and it is reopened again.

There are automations starting when the cover reaches the ´closed´ or ´open´ status. So there is unnneeded traffic.

What is version of Home Assistant Core has the issue?

2021.3.4 with zwaveJS

What was the last working version of Home Assistant Core?

2021.3.3 with Zwave 1.4

What type of installation are you running?

Home Assistant OS

Integration causing the issue

zwaeJS

Link to integration documentation on our website

No response

Example YAML snippet

# Put your YAML below this line

Anything in the logs that might be useful for us?

# Put your logs below this line
@probot-home-assistant
Copy link

Hey there @home-assistant/z-wave, mind taking a look at this issue as its been labeled with an integration (zwave_js) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@firstof9
Copy link
Contributor

Please attach a dump of your device so we can look into this.

@hauserbv
Copy link
Author

hauserbv commented Mar 22, 2021 via email

@firstof9
Copy link
Contributor

Your file did not attach, please drag and drop it into your reply on github.

@hauserbv
Copy link
Author

hauserbv commented Mar 22, 2021 via email

@github-actions
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jun 20, 2021
@hauserbv
Copy link
Author

hauserbv commented Jun 21, 2021 via email

@github-actions github-actions bot removed the stale label Jun 21, 2021
@raman325
Copy link
Contributor

thanks @hauserbv - unfortunately the attachment still hasn't worked. It looks like you are using email, perhaps email attachments don't get logged in GitHub. Can you try attaching your state dump directly to a comment on the GH website? Thanks!

@hauserbv
Copy link
Author

hauserbv commented Jun 22, 2021 via email

@hauserbv
Copy link
Author

hauserbv commented Jul 2, 2021

Now, in core2021.6.6 and zwavejs 0.1.28 the problem is still present. I noticed that in a situation where covers are embedded in groups the problem gets worse. Automation scripts and group are setting the status of the cover device. The device reacts by resetting its status every time until the device itself finds its status is closed.

I have a temporarily fix by disabling/enabling the effected automations before and while the cover is physically closing.

It may be possible to let the trigger check which component issued the status of the cover. But that seems insane as the only one who can say something about the status of a device is the device itself.

The new dump:

zwave_js_dump 2021-07-02 core2021.6.6 zwavejs0.1.28.json.zip

@kpine
Copy link
Contributor

kpine commented Jul 8, 2021

This behavior you are observing is by design. It is implemented by the driver, node-zwave-js. I don't have a great solution for you, but I can explain what is happening. Maybe some answer will come of that.

HA uses the Multilevel Switch CC to control shutters. When you open a cover in HA, you send a Multilevel Switch Set command with level 99, and to close you set level 0. These commands are the same when dimming a light switch (level 1-99) or turning it off (level 0).

With Z-Wave, a roller shutter and a dimming light switch look the same from the driver and application point of view. They both use the Multilevel Switch CC. For a light the command adjusts the brightness. Because of numerous complaints by HA users, at some point node-zwave-js changed its design to optimistically report the current value of the multilevel switch CC based on the value just set target value. After a fixed time interval it will then perform a Get and refresh the actual value. By returning that optimistic value immediately, it avoids the "flip-flopping" of the light toggle element in the UI for slow dimming light switches, which was the chief complaint.

In your case, what you are seeing is:

  1. HA sets multilevel cc target value to 0 to close it
  2. node-zwave-js sends the command to the node
  3. node-zwave-js immediately returns the optimistic fake current value of 0 (closed) to the application (this confuses your automation)
  4. The device may update the status on its own with different values, the current value will be updated in HA
  5. If the device does not update the status, after 5 seconds node-zwave-js will issue a manual refresh

OpenZwave does the following:

  1. HA sets multilevel cc target value to 0 to close it
  2. OZW sends the command to the node
  3. OZW issues a refresh (GET) immediately
  4. Because it's still closing, the device returns a value that is not closed (not 0), either in response to the GET or on its own.
  5. OZW returns the refreshed value to the application
  6. The device may update the status on its own later, the current value will be updated in HA

So the different is the optimistic fake value issued by node-zwave-js. You cannot get the same behavior as OZW without a change in the driver. Via a configuration option you can disable this optimistic value update behavior (disableOptimisticValueUpdate). However, this setting is not accessible if you are using either of the addons, and a downside is that it is a global option, affecting all nodes and values. So if you did have some slow dimming light switches, their behavior would be worse.

I'll note there's actually a comment regarding this and window covers specifically in the docs for the config setting:

Some SET-type commands optimistically update the current value to match the target value when the device acknowledges the command.

While this generally makes UIs feel more responsive, it is not necessary for devices which report their status on their own and can lead to confusing behavior when dealing with slow devices like blinds.

So a possible solution for you would be to disable this option in the driver configuration, but you could only do that with a non-addon installation.

Another workaround I was thinking of would be to try and use Basic Set, but according to your dump, no Basic values are exposed to HA by node-zwave-js (I don't know why), so that cannot be used. The idea would have been to use Basic Set to control the devices, which would avoid the optimistic value refresh, and you'd get the expected behavior. (Basic Set is an alternative to Multilevel Switch Set)

I don't know why node-zwave-js doesn't expose the Basic values, maybe it hides them in some cases. If these values were available, you could use them in your automation instead, at least that's my theory.

A third solution would be to invoke the Basic CC Set command explicitly without using values, which is something not yet implemented in HA, but I think it is in the works.

Sorry if some of that doesn't make sense, it's hard to detail if you don't know how the driver works.

@hauserbv
Copy link
Author

hauserbv commented Jul 8, 2021 via email

@github-actions
Copy link

github-actions bot commented Oct 6, 2021

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 6, 2021
@hauserbv
Copy link
Author

hauserbv commented Oct 7, 2021

If it is by design, it is in my opinion not the best design. There are in zwaveJS multiple sources that set the status of an object, including the best (and for me only) source: the object itself. Second there is a time constraint with covers (it takes time to close, so the actual status is postponed until the cover is closed.).
But if the design cannot support the request, i am out of options.
So, i reluctantly close the subject.

@hauserbv hauserbv closed this as completed Oct 7, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Nov 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
integration: zwave_js stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kpine @firstof9 @raman325 @cgarwood @hauserbv