Repository navigation
Keep multi requests for smartcam devices after a timeout - #1802
rytilahti merged 2 commits into
Conversation
Sorry, something went wrong.
A timeout during a batched request switched the protocol to batch size 1 permanently. SmartCamProtocol then sends SMART-style single requests, which cameras reject with PROTOCOL_FORMAT_ERROR (-40210); every rejection forces a new handshake, so a single Wi-Fi blip left C100 cameras re-authenticating ~30 times a minute until they locked the account out (-40404). Only fall back to single requests on protocols that support them. Fixes python-kasa#1801 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## master #1802 +/- ##
=======================================
Coverage 93.43% 93.43%
=======================================
Files 159 159
Lines 10116 10120 +4
Branches 1044 1045 +1
=======================================
+ Hits 9452 9456 +4
Misses 471 471
Partials 193 193 ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
|
Confirmed on a second model. On a Tapo C510W (fw 1.3.4, AES login) with master at d6e80d2: after a normal connect I set protocol._multi_request_batch_size = 1 and called update() again. Every module came back as INTERNAL_QUERY_ERROR (-100001) (getDeviceInfo, getConnectionType, getLastAlarmInfo, ...), i.e. the camera refuses the single requests. Setting the batch size back to 5 and resetting the transport, the next update() works again. That is exactly the picture in home-assistant/core#186172: one of the two attached diagnostics has all 13 queries at -100001, the handshake keeps succeeding, and only a reload (a new protocol object, so the batch size back to its default) fixes it. |
Sorry, something went wrong.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rytilahti
left a comment
There was a problem hiding this comment.
Thanks @hugaraujo! I did not yet test this on my test camera, but given the other reports this should be fine.
I will merge it in hopes more people can test it, and try to reproduce and test against my cam before doing a release later this week.
Sorry, something went wrong.
Fixes #1801.
Problem
Since 0.11.0, a TimeoutError during a batched request permanently sets _multi_request_batch_size = 1 (added for the P300, which never answers some batches). For smartcam devices that is fatal: with batch size 1, _execute_multiple_query sends SMART-style single requests (get_smart_request), which cameras reject with PROTOCOL_FORMAT_ERROR (-40210). That error sets HANDSHAKE_REQUIRED, so every module query triggers a new handshake.
So a single network blip leaves the device object stuck forever. On four Tapo C100 (fw 1.5.7) in Home Assistant 2026.10.1 this meant ~30 logins/min per camera until they locked the account out (-40404, sec_left), and HA never recovered on its own. A fresh Device object worked immediately.
Fix
A class attribute CAN_DISABLE_MULTI_REQUESTS (true on SmartProtocol, false on SmartCamProtocol) guards both places that fall back to single requests: the timeout fallback and the JSON-decode fallback. For cameras the timeout is re-raised as before 0.11, so _query resets the transport and retries the batch. The P300 behaviour is unchanged.
Testing
New test test_smartcam_multiple_request_timeout_keeps_batching: a timeout followed by a successful batch keeps the batch size, and only multipleRequests are sent. It fails without the change.
pytest tests → 24022 passed, 905 skipped. ruff check, ruff format --check and mypy kasa/protocols are clean.
Live, against a real C100, through a local TCP proxy that drops camera→client bytes for 20 s to simulate a Wi-Fi blip, polling every 5 s (details in C100: one network timeout permanently disables multi-requests (0.11.0.1), single requests get -40210 → endless re-handshakes → lockout #1801):
The live run used an equivalent local patch (the batch size reset skipped). This exact diff is covered by the unit test.
🤖 Generated with Claude Code