UserCodeCCSet for Yale Locks has an artificial length requirement

[oddllc]

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?
UserCodeCCSet is forcing a minimum length of a UserCode to 4. This is an actual requirement when a code is being set.

However, for Yale Locks, the Yale locks itself, SiLabs, and OpenHab will set the UserCode to '' (empty string) when deleting the code (setting UserIdStatus = 0). They are pushing both properties to the device. So, other tools will remove the UserCode, which makes the lock more secure as the code has been removed and disabled. For all these tools, the lock will report the code as '', but not with zwave.js

If I try to wipe it with four spaces, I will be told that the code is already in use. If the value is a number, the lock will Enable the code (instead of deleting it).

This is not possible with zwave.js

2024-07-10 10:48:29.096 INFO Z-WAVE: Calling api writeValue with args: [ { nodeId: 6, commandClass: 99, endpoint: 0, property: 'userCode', propertyKey: 58 }, '', null, [length]: 3 ] 2024-07-10 10:48:29.096 INFO Z-WAVE: Writing '' to 6-99-0-userCode-58 2024-07-10 10:48:29.098 ERROR Z-WAVE: Unable to write '' on 99-0-userCode-58: UserCodeCCSet: The user code must have a length of 4 to 10 characters (ZW0322) 2024-07-10 10:48:29.099 INFO Z-WAVE: Success zwave api call writeValue { status: 5, message: 'UserCodeCCSet: The user code must have a length of 4 to 10 characters (ZW0322)' }

What did you expect to happen instead?
When setting the UserIdStatus to 0, wipe the UserCode (this is what the lock does natively)
or
Allow the UserCode to be set to an empty string (this is what other tools do).

Steps to reproduce the behavior:
Call writeValue to a Yale lock and try setting the userCode to wipe the code.

Anything else we should know?
The codes could contain other secret material that should not be stored in the lock.

Software versions

zwave-js-ui: 9.1.0.f2b51e2
zwave-js: 12.5.4
home id: 3968072557
home hex: 0xec83fb6d

Device information

This is a software limitation based on an assumption about the ZW0322 specification, which does not include the manufacturer's values setting to empty strings on disabled CC.

Since the limitation is in UserCodeCC.ts, not the driver, the driver file does not have any log of this issue.

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

No response

[zwave-js-bot]

👋 Hey @oddllc!

Thanks for opening an issue! It doesn't look like you provided a logfile though. While not strictly necessary for every issue, having a driver log on loglevel debug is required to diagnose most issues.

Please consider uploading a logfile that captures your problem. As a reminder, here's how to create one:

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

[oddllc]

The log file is not required because the TypeScript code blocks access to the driver for this issue.

[oddllc]

[AlCalzone]

Z-Wave JS follows the specification and sets the user code to 0x00000000 when setting the status to available, so clearing it manually is not necessary. Please share a log of what happens when you change the status from Occupied to Available. It might be that the value for the UI is just not updated.