search

zwave-js / node-zwave-js

Z-Wave driver written entirely in JavaScript/TypeScript
https://zwave-js.github.io/node-zwave-js/
MIT License
742 stars 593 forks source link

Inovelli LZW36 - incorrect status reported when turning on fan #2155

Closed themitzman closed 3 years ago

themitzman commented 3 years ago

Checklist:

Describe the bug When I turn on the fan on my fan/light dimmer switch, Zwave is reporting the light as turned on as well even though it is not.

Device information

Which device(s) is/are affected (make/model)? Inovelli LZW36 What are the node IDs? 7

Did you change anything?

Did this use to work before?

How are you using node-zwave-js

To Reproduce

Steps to reproduce the behavior:

  1. Go to '...' in HA, go to devices and select "Master Bedroom"
  2. Click on '...' Turn on "Master Bedroom (2)" this is the fan
  3. Scroll down to '...'
  4. See error - "Master Bedroom" indicator turns on as well. This is the light but the light is not actually on.

Additional context

Add any other context about the problem here.

Logfile: dc781aff_files.zip zwavejs_1.log

blhoward2 commented 3 years ago

@AlCalzone I think this is the same issue as with Zooz:

01:25:48.055 CNTRLR   [Node 007] Mapping unsolicited report from root device to first supporting end
                      point #1

Endpoint 2 turning on is sending a root device message mapped to endpoint 1.

blhoward2 commented 3 years ago

User confirmed via discord that adding the compat flag to disable root mapping fixes this bug. I have reported this to Inovelli for their comment.

AlCalzone commented 3 years ago

@themitzman it looks like your lifeline group contains two associations, one for Node 1, Endpoint 0 and one for Node 1, Endpoint 1. Please remove the one to Node 1, Endpoint 1 (you can do that in zwavejs2mqtt), operate the fan afterwards and post a log of that. I want to make sure that this is not just the result of an incorrect association.

AlCalzone commented 3 years ago

The main problem here is that we're getting a multi channel encapsulated report from endpoint 2 (correct) and a multicast (!) report from the root device. The latter not only seems incorrect but it is impossible to assign it to the correct endpoint when there are multiple possible sources it could have come from.

Unless this is just the result of the incorrect association, I might have to disable mapping altogether if it is ambiguous.

themitzman commented 3 years ago

Could you explain that in dummy terms? I'm still fairly new to zwavejs so I'm notn100% clear on what you mean by lifeline.

On Thu, Mar 25, 2021, 5:44 AM AlCalzone @.***> wrote:

@themitzman https://github.com/themitzman it looks like your lifeline group contains two associations, one for Node 1, Endpoint 0 and one for Node 1, Endpoint 1. Please remove the one to Node 1, Endpoint 1 and operate the fan afterwards. I want to make sure that this is not just the result of an incorrect association.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/2155#issuecomment-806508464, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBJKKDW7VKQKIKVK7MFCXLTFMAYLANCNFSM4ZYNFVZA .

AlCalzone commented 3 years ago

Z-Wave devices use associations to report changes to other devices and the controller. There is a dedicated group for the latter (normally group 1), which is called "Lifeline". Yours contains two associations, one of which might be the cause for the wrongly addressed reports.

themitzman commented 3 years ago

Ok I see. When I get to my desk for work I'll take a look and reply back. I appreciate the guidance. Maybe this happened when I migrated from ozw to zwavejs.

On Thu, Mar 25, 2021, 7:34 AM AlCalzone @.***> wrote:

Z-Wave devices use associations to report changes to other devices and the controller. There is a dedicated group for the latter (normally group 1), which is called "Lifeline". Yours contains two associations, one of which might be the cause for the wrongly addressed reports.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/2155#issuecomment-806578621, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBJKKFGXGBLJ3VXRW2VWN3TFMNVRANCNFSM4ZYNFVZA .

AlCalzone commented 3 years ago

It's likely that OZW set up the endpoint 1 target and didn't map the weird root device report to an endpoint. AFAIK OZW does not hide the unnecessary root device values by default.

Zwave-js sets up the endpoint 0 target during the device interview but now you have 2 associations. It would have cleaned up unnecessary node associations (without an endpoint), but the endpoint 1 association does not automatically get removed.

themitzman commented 3 years ago

Got it. I am going to revert the compat change we did last night, reinterview the node, then remove it from the lifeline. I'll let you know how it goes.

On Thu, Mar 25, 2021 at 8:19 AM AlCalzone @.***> wrote:

It's likely that OZW set up the endpoint 1 target and didn't map the weird root device report to an endpoint. AFAIK OZW does not hide the unnecessary root device values by default.

Zwave-js sets up the endpoint 0 target during the device interview but now you have 2 associations. It would have cleaned up unnecessary node associations (without an endpoint), but the endpoint 1 association does not automatically get removed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/2155#issuecomment-806635430, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBJKKFNLT5MZS5T2ETWBBLTFMS6JANCNFSM4ZYNFVZA .

AlCalzone commented 3 years ago

Probably better if you first remove the unnecessary association. Not sure if that changes anything, but this way it should not leave any traces.

themitzman commented 3 years ago

OK so I removed the compat flag from last night, restarted the container, removed the second entry from the lifeline association (endpoint 1), then reinterviewed the node. The issue is now resolved!

So out of curiosity, do you think the migration from openzwave 1.4 was the potential cause? Meaning, openzwave created that association when it shouldn't have?

On Thu, Mar 25, 2021 at 8:31 AM AlCalzone @.***> wrote:

Probably better if you first remove the unnecessary association. Not sure if that changes anything, but this way it should not leave any traces.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/2155#issuecomment-806652399, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBJKKHHRKKP2KJFF46WNDTTFMUJNANCNFSM4ZYNFVZA .

AlCalzone commented 3 years ago

I think its a combination. OZW set up a weird association, which worked for OZW because it didn't do anything special with the root reports. And zwave-js doing over-eager mapping between endpoints.

themitzman commented 3 years ago

Fair enough assessment. Appreciate the assistance and glad it's something easily fixed.

On Thu, Mar 25, 2021 at 9:09 AM AlCalzone @.***> wrote:

I think its a combination. OZW set up a weird association, which worked for OZW because it didn't do anything special with the root reports. And zwave-js doing over-eager mapping between endpoints.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/2155#issuecomment-806712505, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBJKKHXLF5PZW46NKH4SLTTFMYZHANCNFSM4ZYNFVZA .