Unstable pairing for yale lockset while using S2 security

[hassan-xy]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

What is happening?
So I am trying to pair yale lockset SD-M1100 using S2 based pairing method, however I see that the pairing in some cases downgrades to S0 and the pairing is incomplete though displayed as complete in the ui. (MID/PID/ battery percentage is missing). But the lockset itself announces as paired, but uncontrollable from the ui as well.

What did you expect to happen instead?

Steps to reproduce the behavior:

1. Start inclusion
2. enter name yale and tap on the lock to start pairing. It may ask for the first 5 pins of the dsk key. Sometimes also asks to choose method of inclusion(I always choose S2 and S0).
3. In some cases I see paired as S2 device(Access_control system) which is what we want to happen.
4. Error: In many cases it pairs as S0(downgraded) and pairing is incomplete and device cant be controlled.I have tried re-interviewing the node, healing, ping and all other remedies but to no avail.

Anything else we should know?

My product code is ZST10-700. The product is FW: v7.15.4, SDK: v7.15.4. My chipset is ZGM130S037HGN 700 series.
Unfortunaltely I cant modify or upgrade to the latest versions.

Software versions

My product code is ZST10-700. The product is FW: v7.15.4, SDK: v7.15.4. My chipset is ZGM130S037HGN 700 series.
Unfortunaltely I cant modify or upgrade to the latest versions.

Device information

Manufacturer: ...
Model name: ...
Node ID: ...

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwave_yale_pairing_fail.zip

[zwave-js-bot]

👋 Hey @hassan-xy!

It looks like you attached a logfile, but its filename doesn't look like it a driver log that came from Z-Wave JS.

Please double-check that you uploaded the correct logfile. If you did, disregard this comment.

As a reminder, here's how to create one:

• Z-Wave JS UI
• Home Assistant Z-Wave Integration
• ioBroker.zwave2 Adapter

[hassan-xy]

Hi,
Actually I it is a driver log. I just named it as per the convinence. Please have a look at it once. Let me know if you are facing any issues.

[hassan-xy]

Let me know if you still want me to add a new log file as per the the correct standard.However it may take some time as the its a bit time consuming to reproduce the error case. Though I am sure the current log file should be enough.

[AlCalzone]

The logfile you posted looks okay. The bot just doesn't recognize that name. I'll have a better look when I find some time -> #6521

This may be caused by connectivity issues though, you may want to take a look at these links in the meantime:

• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting
• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=testing-the-connection-strength

[hassan-xy]

z-ui_2023-12-11.log
Hi guys, I have added the new log file as per request. Please have a look and guide me.

Thanks,
Hassan

[hassan-xy]

Hi guys,
So this issue is of the utmost priority for me. If possible, i request you to support me at the earliest.

If it will take more time then can you guys suggest me if there is a command class which i can call as a api and fetch the MID,PID or any other missed data.

Thanks guys,
Hassan

[hassan-xy]

Hi @AlCalzone Its been two weeks and here is no update on the issue. I request you to look into it and provide your valuable inputs. What I have noticed using the zniffer there is an S2 inclusion timeout and the payloads are released a little later. So overall here is conclusion.
We cant modify the firmware in the end device module.We also cant upgrade to the latest zwave version to 7.18 due to remote location of my devices. We need to increase the S2 pairing timeout limit to more than the usual setting. Let me know if you have any suggestions. Thanks

[hassan-xy]

hi @robertsLando Can you have a look at this issue. I really need your help right now.

Thanks

[hassan-xy]

Hi @The00Dustin can you also have a look at this issue.
Thanks

[robertsLando]

Hi @hassan-xy, I'm sorry for the delay but this is something on driver side that I cannot fix on z-ui. @AlCalzone is on parental leave so may be slow to respond, please be patient

[AlCalzone]

@hassan-xy unfortunately, the log only shows that the lock stops communicating in the middle of the key exchange. Since it is the lock's turn to request information at the point it happens, there's nothing we can do about it.
You could try bringing the lock closer and follow the recommendations I posted before.

[hassan-xy]

Hi @AlCalzone Thanks a lot for the reply. I understand and have gone through the recommendations you posted. The main issue is the pariring is unstable and the lockset pairs with S2 security around 3 out of 10 times. Also my client compares the pairing of the my 700 series chipset with a different vendor device(they also use 700 series but not sure if they are using zwavejs or any other sdk), but somehow the pairing is very stable in their case. I know that the "Security S2 bootstrapping failed, the node was not granted any S2 security class" could be the main reason for this failure. I have tried to ping, reinterview, and every other feature available in the UI but to no avail. My request to you is "Is it possible to increase the timeout limit or number of retries the controller makes before it prints the Timed out message and downgrades the security class to None?".

PS: I tried S0 security as well and the pairing success/failure is still the same as above case.

Thanks and Best Regards,
Hassan

[AlCalzone]

This sounds a lot like a connectivity problem between The controller and the end device.
Do you or your client have access to a Zniffer to look at the traffic near the end device? That would help figure out if the controller is simply not receiving the commands it should.

Unfortunately increasing timeouts is out of the question as that would go against the Z-Wave specifications.

[hassan-xy]

Actually we dont see traffic near the end device. The client performs a zwave reset, then pairs the yale lockset. Somehow the yale does not release the data in time. Using Zniffer I had noticed that the lockset would go into sleep mode and controller would send wakeup beams. Once the S2 bootstrapping would fail then lockset would send the S2 keys, so I was looking to increase the timeout. Once the security is downgraded to "None" the physical lockset announces "paired successfully" but unable to control from the UI. Alternately I was thinking of increasing the number of retries if that could resolve. Let me know if this is possible.

Regards,
Hassan

[AlCalzone]

If you take a look at the specifications, page 833, you'll see that the key exchange for S2 is very strict, both in sequence and in timing.

Looking at the logs, you're getting to the red line:

After Z-Wave JS has sent the network key for S2_AccessControl, the lock has a maximum of 10 seconds to verify the key. Afterwards, the key exchange has to be aborted. It sends the NonceGet very quickly, and acknowledges the NonceReport, but then never follows up with the key verification.

Looking at the RSSI values, I don't think this is actually a connectivity issue, so it has to be a firmware bug in the device.

There's no way to repeat anything or retrying, as it would a) violate the specifications, and b) it's the device's turn to send something.