[Aqara/Locks] Improvement of credential info management #2712
Conversation
Test Results 71 files 480 suites 0s ⏱️ Results for commit eaad1cd. ♻️ This comment has been updated with latest results. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against eaad1cd |
|
linter fail |
I have removed the whitespace. |
| local HOST_COUNT = "__host_count" | ||
| local PERSIST_DATA = "__persist_area" | ||
|
|
||
| credential_utils.attrCopy = function(table) |
There was a problem hiding this comment.
I believe this is an unnecessary function. utils.deep_copy is already doing this recursively for the whole table.
There was a problem hiding this comment.
Thank you for your feedback. I have revised the implementation to manage data at the table unit level now.
| local credentialInfoTable = device:get_field(PERSIST_DATA) | ||
| if credentialInfoTable ~= nil then | ||
| device:emit_event(lockCredentialInfo.credentialInfo(credentialInfoTable, { visibility = { displayed = false } })) | ||
| end |
There was a problem hiding this comment.
Should there be an else clause where we call backup_data in the case that there is nothing persisted? I think this will help ensure existing devices have the state for this capability persisted.
There was a problem hiding this comment.
Could you please elaborate on this part a bit more? Are you suggesting that adding a check for backup_data would be beneficial if capability information could be deleted during normal use? I'd appreciate further explanation to ensure my understanding is correct.
There was a problem hiding this comment.
This sync function is called on device_init. Devices out there right now, do not have PERSIST_DATA set on the device object yet. We want any device that does not yet have this persisted, to have it persisted as soon as we detect that it hasnt been persisted. So my suggestion is, if table is nil, then we should read the current state and persist it in the driver datastore with credential_utils.backup_data. If we do not detect and persist in the device_init handler, then we are waiting for a capability command to come in that will cause the persistence, which may or may not happen before a hub failover.
3 participants
Check all that apply
Type of Change
Checklist
Description of Change
Summary of Completed Tests