fix: track lock _notifications_enabled state on enable#497
Draft
bluetoothbot wants to merge 2 commits into
Draft
fix: track lock _notifications_enabled state on enable#497bluetoothbot wants to merge 2 commits into
bluetoothbot wants to merge 2 commits into
Conversation
_enable_notifications never set self._notifications_enabled = True, so the flag stayed False forever. Two consequences: - _disable_notifications short-circuits on `if not self._notifications_enabled`, meaning the disable command would never actually fire on the lock. - Every lock/unlock invocation re-sent the enable command instead of recognising notifications were already on. Set the flag on a successful response, return False on failure, and no-op when already enabled. Existing test only checked the return value; expand it to assert state plus a no-op second call, and add a failure-path test that the flag stays False if the lock rejects the command. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests.
🚀 New features to boost your workflow:
|
Member
|
Looks like a real bug. I'm traveling so can't test on a real device. |
Collaborator
|
I am currently away on a business trip; once I return tomorrow, I will perform the testing on the device. |
zerzhang
reviewed
May 20, 2026
Collaborator
zerzhang
left a comment
There was a problem hiding this comment.
The purpose of the _enable_notifications function is to enable the device to periodically report messages. For instance, when the device is being unlocked, its status transitions sequentially through "unlocking" and "unlocked"; conversely, when the BLE connection is lost, this status is reset.
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.
What
Set
_notifications_enabled = Trueon a successful_enable_notificationscall (and skip the BLE write when already enabled). Tighten the existing test and add a failure-path test.Why
SwitchbotLock._enable_notificationsonly returned the command result — it never updatedself._notifications_enabled. The flag therefore stayedFalsefor the lifetime of the device. That has two consequences:_disable_notificationsearly-returns onif not self._notifications_enabled: return True, so the disable command would never actually be sent to the lock.lock()/unlock()/unlock_without_unlatch()/half_lock()re-issues the enable command rather than recognising notifications are already on.Surfaced while looking at #489 (lock event subscription). The notification-tracking gap is unrelated to that question's root cause but is a real bug in its own right.
How
_enable_notifications: short-circuit when the flag is alreadyTrue; on a successful command, set the flag; on failure, returnFalseand leave the flagFalse.test_enable_notificationsnow asserts the flag flips toTrueand that a second call is a no-op (call count stays at 1).test_enable_notifications_failure_keeps_state_falsecovers the failure path.Testing
.venv/bin/python -m pytest -q→ 1085 passed.🤖 Generated with Claude Code
Quality Report
Changes: 2 files changed, 38 insertions(+), 2 deletions(-)
Code scan: clean
Tests: failed (FAILED)
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline