Repository navigation
C100: one network timeout permanently disables multi-requests (0.11.0.1), single requests get -40210 → endless re-handshakes → lockout #1801
Description
Summary
Four Tapo C100 cameras worked fine for months with python-kasa 0.10.2 (Home Assistant 2026.10.0 tplink).
About an hour after upgrading to Home Assistant 2026.10.1 (python-kasa 0.11.0.1), all four lost
control (every query failed) and stayed in that state for hours, recovering only after no client tried to
log in for ~15 minutes. Then it happened again ~3.5 h later. I believe the new behaviour from #1771
(re-handshake immediately when passthrough answers HTTP 401) makes these cameras count failed logins until they
lock the account out.
Devices
- 4 × Tapo C100, firmware 1.5.7 Build 260709 Rel.28020n (unchanged during the incident)
- Transport: SslAesTransport, SMART.IPCAMERA, encryption_type: AES, https: true, login_version: 4
- Home Assistant OS, tplink integration, default polling
- Tapo bulbs (L430C, KLAP) on the same account and HA instance were not affected
Before (0.10.2) — worked, but noisy
Each camera drops its session about every 10 minutes (as described in #1771 / #1739). HA logged exactly
24 errors/hour for 4 cameras (6 per camera), e.g.:
ERROR [kasa.smart.smartdevice] Error querying <ip> for modules 'BabyCryDetection, devicemodule, Led, LensMask, MotionDetection, PersonDetection, TamperDetection, Time' after first update: <ip> responded with an unexpected status code 401 to passthrough
The next poll always worked. Entities never went unavailable for more than a few seconds.
After (0.11.0.1) — cameras lock up
- HA updated 2026.10.0 → 2026.10.1 at 22:27. The 401 lines disappear from the log (Use log-level debug for smartdevice query error reporting #1587 moved them to debug).
- 23:41 first camera fails, 05:47 the other three fail within 6 seconds of each other; none recover.
- Every request then fails with a mix of:
- getDeviceInfo not found in {... INTERNAL_QUERY_ERROR (-100001) ...} for every method
- AuthenticationError: Invalid password hash in handshake2 (credentials are correct — they work minutes later)
- DeviceError: Error sending secure_passthrough message: PROTOCOL_FORMAT_ERROR(-40210)
- AuthenticationError: Error trying handshake1: {'error_code': -40404, 'result': {'sec_left': 572}}
- A fresh python-kasa 0.11.0.1 session from another host fails the same way while HA keeps polling,
so it is not a stale session inside HA. Power-cycling one camera did not help. - Disabling the four HA config entries (no login attempts at all) for 15 minutes → all four answer
cleanly, twice in a row. Re-enabled → fine from 09:45 until 13:21, when all four failed again within
3 seconds. - Trigger correlation: both simultaneous failures came seconds after a short Wi-Fi blip (another Wi-Fi
device on the LAN, a Broadlink RM4, timed out at 05:46:55 and 13:20:43). Such blips are common on this
network and also happened on the two days before the upgrade — back then the cameras went unavailable for
a few seconds and recovered by themselves. Since 0.11.0.1 the same blip ends in a lockout. - I have now downgraded HA to 2026.10.0 (python-kasa 0.10.2) and will report back whether the lockouts stop.
Suspected mechanism
With #1771, a 401 on passthrough sets HANDSHAKE_REQUIRED and raises _RetryableError, so the protocol
immediately logs in again and retries. On these C100s, the immediate re-handshake right after the 401
appears to be rejected (Invalid password hash / -40210), and each rejection counts as a failed login.
When a session drop coincides with a short network blip, the immediate re-handshake and retries fail
in quick succession and the camera enters its lockout (-40404, sec_left). From then on, HA's regular polling keeps adding failures, so it
never leaves that state on its own.
The old behaviour (fail this request; next poll does a fresh handshake a few seconds later) never caused
this.
Possible fixes
- Back off (e.g. a few seconds) before re-handshaking after a 401, or do not retry the handshake within the
same request for SslAesTransport cameras. - Do not keep retrying handshakes while the device reports -40404 — honour sec_left.
- Treat Invalid password hash immediately after a 401 as retryable-later, not as a reason to retry now.
Happy to run a debug build or capture kasa.transports debug logs on one camera if that helps.
Related: #1771, #1739, home-assistant/core#179553
Activity
hugaraujo commented on Oct 14, 2026
Correction / more data after a controlled test.
I ran python-kasa 0.11.0.1 standalone against one of the C100s (fw 1.5.7 Build 260709), polling every 5 s like HA, with kasa.transports/kasa.protocols at debug, while that camera was removed from HA (no other client):
So the plain 401 re-handshake works on these cameras — my "immediate re-handshake is rejected" theory in the description was wrong, sorry about that.
What still stands: on 0.10.2 the cameras rode out short Wi-Fi blips (unavailable for seconds, then fine); on 0.11.0.1 both incidents started seconds after such a blip and ended in the -40404 lockout that HA's polling then kept alive. My current suspicion is the behaviour during a network blip (handshake/retries whose requests reach the camera but whose responses are lost, being counted as failed logins), not the 401 path itself. I'll try to reproduce a blip in a controlled way and post debug logs.
hugaraujo commented on Oct 14, 2026
Reproduced and root-caused — it's not the 401 path, it's the new timeout handling in SmartProtocol._execute_multiple_query:
A single network timeout during a batched request permanently switches the device to batch size 1. On a C100 (fw 1.5.7 Build 260709, SslAesTransport, login_version 4) every single (non-batched) request is then answered with PROTOCOL_FORMAT_ERROR (-40210), which sets HANDSHAKE_REQUIRED, so each module query triggers a new handshake: ~30 logins/min that never stop. On real cameras this ends in the -40404 lockout I reported. A new Device object works immediately, which is why it looked like "the camera is broken until HA stops polling".
Test setup: standalone python-kasa against one C100 through a local TCP proxy that can drop camera→client bytes (request arrives, response lost) to simulate a Wi-Fi blip. Poll every 5 s. Same 20 s "responses lost" blip, same camera, run back to back:
multipleRequest sent: 30 before the blip, 0 after it on 0.11.0.1.
(For completeness: the plain 401/-40421 session expiry every ~10 min re-handshakes fine with #1771, as noted above.)
Suggested fix: only fall back to batch size 1 on a timeout if the device has never answered a batched request on this protocol instance (that still covers the P300 case, where the very first batch times out), or reset the batch size after the next successful handshake. A device that has answered hundreds of batches shouldn't lose batching because of one network blip, and for smartcam devices batch size 1 seems to be broken altogether (-40210 on every single request). I'm happy to open a PR with the first option plus a test, if that approach sounds right to you.
hugaraujo commented on Oct 14, 2026
Additional data point, to be fair to 0.11: after downgrading HA to 2026.10.0 (python-kasa 0.10.2), one camera (office C100) also got stuck once, at 15:00:44 today. Every poll failed with INTERNAL_QUERY_ERROR for all methods, and HA did not recover on its own for ~1.5 h.
While HA kept polling it, a fresh 0.10.2 client got -40210 on its first batched request. That is consistent with HA's handshakes invalidating the other client's session. With the HA entry disabled for 40 s, a fresh 0.10.2 client worked immediately (2/2 polls OK), and re-enabling the entry (new Device object) recovered it. So 0.10.2 can also end up with a device object that never recovers, but through a different and rarer trigger that I haven't captured yet. The 20 s blip that kills 0.11.0.1 every time is handled fine by 0.10.2.
One candidate is the pre-existing JSON_DECODE_FAIL_ERROR/INTERNAL_UNKNOWN_ERROR → batch size 1 fallback, which has the same effect on cameras. #1802 guards that path too, but I can't confirm that's what happened. I'm enabling kasa debug logging in HA to catch the next occurrence and will post it here.
rytilahti commented on Oct 14, 2026
#1802 potentially related? Maybe the cameras do not support the single request format at all, and the new queries are too large after the new module additions?
hugaraujo commented on Oct 14, 2026
Yes, I think so. freeKC confirmed on a C510W that cameras reject single requests altogether. On query size: a 40-min run with 0.11.0.1 (new modules included) had zero timeouts. The timeouts that trigger the fallback come from real network blips: other Wi-Fi devices on the LAN time out at the same moments, e.g. a 4-min outage this evening. So the batch size doesn't look like the cause, only the path that the timeout takes.