Repository navigation
Z-Wave Lock: Ensure a default pin length is set - #3336
Conversation
|
Channel deleted. |
|
zwave-lock_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against fd0a646 |
Test Results 73 files 570 suites 0s ⏱️ Results for commit fd0a646. ♻️ This comment has been updated with latest results. |
4f7a7b9 to
b8064df
Compare
hcarter-775
left a comment
There was a problem hiding this comment.
lots and lots of little nits, but it looks fine to me.
hcarter-775
left a comment
There was a problem hiding this comment.
Very clean! I still think we don't need to ensure the pin bounds in both added and init. I don't know how this would bite us, but things like this usually, eventually, do!
09ac637 to
362112a
Compare
362112a to
721c086
Compare
|
@ctowns I just realized we're not setting this explicitly during migration. We should do that as well. |
Good catch @hcarter-775 ! I have just pushed up a small commit to address the migration case: fd0a646 |
Description of Change
Z-Wave locks using
lockCredentialscould end up with nominPinCodeLen/maxPinCodeLenat all, which means that the pin code length then defaults to the 6-10 that is enforced by the app by default. This causes problems for users who have a lock that doesn't report their pin code length, but does support pin codes of length 4.The User Code command class has no way to report PIN length, so only Schlage (through a configuration parameter) ever filled these in.
DEFAULT_MIN_PIN_LENGTH/DEFAULT_MAX_PIN_LENGTHtolock_utils/constants.lua. These are the PIN length limits in the Z-Wave spec.lock_utils.ensure_pin_length_bounds(device): Oninit, emits the default min and max (not displayed) only if no value exists yet. This covers existing devices that were set up before this change. Values already present, such as ones migrated fromlockCodesor reported by the lock, are left alone.minPinCodeLenas a length the lock had reported. If a new report differed, it assumed the lock had wiped its codes and cleared all users and credentials. With the 4–10 default in place, the lock's first real report would have triggered that wipe.pinLengthFromDevice, now records whether the lock itself has reported a length. The wipe only happens when the lock's own earlier length changes.add_credential_handlernow checks this field instead ofminPinCodeLen == nilto decide whether to query parameter 16 and wait before adding the credential. Without this, the default value would stop the handler from ever asking the lock for its real length.Summary of Completed Tests
Tested on-device with a Yale door lock. New unit tests have been added.