Skip to content

Add local override for locks TTLock never reports an auto-lock delay for - #310

Open
jbergler wants to merge 2 commits into
developfrom
auto-lock-override-67
Open

Add local override for locks TTLock never reports an auto-lock delay for#310
jbergler wants to merge 2 commits into
developfrom
auto-lock-override-67

Conversation

@jbergler

Copy link
Copy Markdown
Owner

Summary

Some locks never return autoLockTime from TTLock's /lock/detail API 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-lock LockStateStore and only ever fills a gap - the real API value always wins when TTLock reports one. It drives the same auto_lock_seconds field everything else already reads (the relock-assumption logic and the AutoLock switch), so there's no separate code path to keep in sync. The existing configure_autolock service and switch (which try to configure the real lock) are untouched.

Test plan

  • script/check passes (lint, type-check, full test suite - 244 tests)
  • New coordinator tests cover: override fills a None API value, a real API value always wins over a stored override, setting/clearing the override applies immediately
  • New service tests cover: setting the override, explicit None clearing it, an omitted field being a no-op

🤖 Generated with Claude Code

https://claude.ai/code/session_01LkqnVxCQzq4E21ncFrGA2g

jbergler and others added 2 commits July 25, 2026 20:45
…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

codecov Bot commented Jul 25, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.47%. Comparing base (1254842) to head (884c2aa).
⚠️ Report is 3 commits behind head on develop.
✅ All tests successful. No failed tests found.

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.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

auto_lock_seconds set to -1 even though lock is relocking after 5 seconds

1 participant