search

zwave-js / node-zwave-js

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

Schlage BE469 does not always reflect correct state/output CC notification #2216

Closed FuzzyMistborn closed 3 years ago

FuzzyMistborn commented 3 years ago

Checklist:

Describe the bug

A clear and concise description of what the bug is. Describe what causes the bug, what you observe, and what happens as a result.

I'm trying to get the event notification for my door lock to determine what user code unlocked the lock. However, the notification is intermittent in actually showing up, and oftentimes the devices state isn't accurately reflected in HASS (IE I'll manually unlock the door and 30 seconds later it'll show unlocked, sometimes a lot longer). Other times it's instant and shows up right away.

Device information

Which device(s) is/are affected (make/model)? Schlage BE469 What are the node IDs? Node 78

Did you change anything?

Did this use to work before?

How are you using node-zwave-js

To Reproduce

Steps to reproduce the behavior: Just lock/unlock the lock. Sometimes I can do it in rapid sequence without issue. Other times even a delay of 5-10 seconds even trips it up. No rhyme or reason for when it fails.

Additional context

Add any other context about the problem here.

Logfile:

zwavejs_1.log

sstratoti commented 3 years ago

I'm experiencing similar issues. I don't know if this helps, but I compared the Zwave-JS json file to the OZW equivalent.

In the OZW config file, it looks like it was updated from what was generated from the ZWA specs by a user "Jaburges" in November 2020.

Parameter 6 has the following:

<CommandClass id="113">
    <!-- These Door Locks don't send a DoorLockReport when the
        Lock Status is Changed, but instead send a Alarm Message -
        So we trigger a Refresh of the DoorLock Command Class when
        we recieve a Alarm Message Instead -->
    <TriggerRefreshValue Genre="user" Index="6" Instance="1">
      <RefreshClassValue CommandClass="98" Index="1" Instance="1" RequestFlags="0"/>
    </TriggerRefreshValue>
  </CommandClass>

For parameter 6 in Zwave-JS:

        "6": {
            "label": "User Slot Bit Field",
            "description": "Occupied slots for User Codes",
            "valueSize": 4,
            "minValue": 0,
            "maxValue": 255,
            "defaultValue": 0,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },

HTH.

sstratoti commented 3 years ago

Also, so you don't have to go hunting: Original issue: https://github.com/OpenZWave/Zwave2Mqtt/issues/742 and revision in OZW: https://github.com/OpenZWave/open-zwave/commit/c9697ac2eb6278252675eb699ab8b6c7138015f8

So it looks like the original file that was added to OZW had this fix in it, but the parameter index was wrong (0 instead of 6).

However, parameter 6 IS different between the two projects, and I didn't have any issues when I was on OZW. I just migrated yesterday, and my front door lock is not updating/refreshing its values/status in homeassistant whenever someone unlocks the door.

AlCalzone commented 3 years ago

I'll be able to look at the logs on Monday. Just a heads up, comparing configuration param 6 with whatever OZW's value index 6 for the Notification CC is, is like comparing apples and oranges.

sstratoti commented 3 years ago

Totally get that. Was just trying to note that both files were generated by ZWA xml, and OZW seems to have a note indicating that they fixed a problem with that generation.

Thanks for taking a look, and all the work you’re doing with this. Aside from this lock it’s been mostly smooth sailing!

AlCalzone commented 3 years ago

@FuzzyMistborn

The loglevel is a bit low, but I can see that the device is spamming requests for nonces (number used once) to encrypt the secure messages several times per second:

2021-04-01T02:46:04.539Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport
2021-04-01T02:46:04.549Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport
2021-04-01T02:46:04.588Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport
2021-04-01T02:46:04.689Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport
2021-04-01T02:46:04.706Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport
2021-04-01T02:46:04.894Z CNTRLR   [Node 078] in the process of replying to a NonceGet, won't send another NonceR
                                  eport

As a result, zwave-js either does not respond to most of these requests and always invalidates all but the last one, because only one per device must be valid at a given time. When an encrypted commands with one of those invalidated onces is received, it gets discarded. zwave-js conforms with the Z-Wave specifications in its strict nonce handling whereas OZW did not - which is likely why you didn't notice in OZW which mess was going on behind the scenes.

Usually this spamming seems to be a result of a bad network health - messed up routes et cetera. I suggest you start by performing a network heal.

FuzzyMistborn commented 3 years ago

Huh. I swear I'd turned on "silly" logging. I'll try a heal and report back.

FuzzyMistborn commented 3 years ago

A heal seems to have vastly improved performance. Likely cause was that I replaced a bunch of switches and probably forgot to heal to reset all the pathways. @sstratoti I'd suggest giving that a try.

FoxxMD commented 3 years ago

@FuzzyMistborn how exactly are you getting the user code from an event in HA? That value, along with whether the lock event was manual (from inside) or with keypad, used to be attributes in new_state (in node-red payload from HA on lock event) when using the old ozw (not beta) integration but are no longer there.

EDIT -- Figured it out, for posterity:

The event payload will include everything you need to determine lock type and user id