Skip to content

Remove the periodic reporting status of the lock #372

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

zerzhang
Copy link
Collaborator

@zerzhang zerzhang commented Jul 9, 2025

  • suggest remove the lock periodic reporting status when perfoming an action lock or unlock, which contains error status and sometimes causes the status to be overwritten immediately
  • Normally, when we perform a locking or unlocking action, we will actively query the lock status once. At this time, the locking or unlocking action may not have been completed. Then, when the BLE scan detects a change in the device broadcast, we will also actively update the status once. Through these two methods, we can ensure that the final state of the lock is correct.

20250709-185032
20250709-185025

Copy link

codecov bot commented Jul 9, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines Coverage Δ
switchbot/devices/lock.py 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@zerzhang zerzhang requested a review from bdraco July 9, 2025 11:01
@bdraco
Copy link
Member

bdraco commented Jul 9, 2025

How does this work if the user only has passive scans on?

@zerzhang
Copy link
Collaborator Author

If the user only has passive scanning, the user should not be able to add this device.

@bdraco
Copy link
Member

bdraco commented Jul 10, 2025

Historically users turn on active scanning to add the device and than turn it back off once it's discovered. When active scans are on the connection times are much much longer

@zerzhang
Copy link
Collaborator Author

zerzhang commented Jul 10, 2025

If this is the case, there should be no problem. When the device is added, self.model is already determined. In subsequent scans, we only use the manufacturer_data in the advertisement. We don't need to know the service_data because we already know the type when the device is added.

    @callback
    def _async_handle_bluetooth_event(
        self,
        service_info: bluetooth.BluetoothServiceInfoBleak,
        change: bluetooth.BluetoothChange,
    ) -> None:
        """Handle a Bluetooth event."""
        self.ble_device = service_info.device
        if not (
            adv := switchbot.parse_advertisement_data(
                service_info.device, service_info.advertisement, self.model
            )
        ):
            return
        if "modelName" in adv.data:
            self._ready_event.set()
        _LOGGER.debug(
            "%s: Switchbot data: %s", self.ble_device.address, self.device.data
        )
        if not self.device.advertisement_changed(adv) and not self._was_unavailable:
            return

@zerzhang
Copy link
Collaborator Author

@bdraco I have discussed this with our internal team and was told that different devices have different instructions for periodically reporting device status, so I made the following changes.

  • Correct COMMAND_ENABLE_NOTIFICATIONS command for differenct lock device
  • Each time an action is executed, the device status is reported periodically until Bluetooth is disconnected

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.

2 participants