Add local override for locks TTLock never reports an auto-lock delay for - #310
Open
jbergler wants to merge 2 commits into
Open
Add local override for locks TTLock never reports an auto-lock delay for#310jbergler wants to merge 2 commits into
jbergler wants to merge 2 commits into
Conversation
…ckTime for Some locks (missing featureValue bit 4) never return autoLockTime from TTLock's API, so the coordinator has no way to guess when they've auto-relocked and the lock entity sits stuck at "unlocked" (issue #67). Rather than have the integration infer a relock delay from a missing field, this lets a user assert one explicitly via a new local-only override, persisted in the existing LockStateStore and consulted only when the API itself reports nothing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkqnVxCQzq4E21ncFrGA2g
Code review flagged the async_ prefix as inconsistent with this coordinator's other public coroutines (lock, unlock, set_auto_lock, set_lock_sound), none of which use it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LkqnVxCQzq4E21ncFrGA2g
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #310 +/- ##
===========================================
+ Coverage 95.43% 95.47% +0.04%
===========================================
Files 17 17
Lines 1555 1570 +15
===========================================
+ Hits 1484 1499 +15
Misses 71 71 ☔ View full report in Codecov by Harness. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Some locks never return
autoLockTimefrom TTLock's/lock/detailAPI at all (locks missing featureValue bit 4 - "support configuration of auto lock time"). Without that field, the coordinator has no way to guess when the lock has auto-relocked, so the lock entity sits shown as "unlocked" until the next 15-minute poll happens to catch the real state (#67).A previous suggestion in that thread - silently assume a fallback delay whenever the field is missing - was rejected by the maintainer, since TTLock's own docs say a missing field can mean either "not supported" or "just never configured," so the integration itself shouldn't infer lock behavior from an absent value.
This instead adds a new service,
ttlock.set_config_override, that lets a user assert a locally-known auto-lock delay for their own lock. It's stored in the existing per-lockLockStateStoreand only ever fills a gap - the real API value always wins when TTLock reports one. It drives the sameauto_lock_secondsfield everything else already reads (the relock-assumption logic and theAutoLockswitch), so there's no separate code path to keep in sync. The existingconfigure_autolockservice and switch (which try to configure the real lock) are untouched.Test plan
script/checkpasses (lint, type-check, full test suite - 244 tests)NoneAPI value, a real API value always wins over a stored override, setting/clearing the override applies immediatelyNoneclearing it, an omitted field being a no-op🤖 Generated with Claude Code
https://claude.ai/code/session_01LkqnVxCQzq4E21ncFrGA2g