Closed FuzzyMistborn closed 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.
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.
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.
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!
@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.
Huh. I swear I'd turned on "silly" logging. I'll try a heal and report back.
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.
@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:
zwave_js_notification
)The event payload will include everything you need to determine lock type and user id
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
zwavejs2mqtt
(latest) docker imagezwavejs2mqtt
(dev) docker imagezwavejs2mqtt
Manual Docker buildnode-zwave-js
branch:zwavejs2mqtt
branch:HomeAssistant
version XYZnode-zwave-js
branch:zwavejs2mqtt
branch:node-red-contrib-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