Repository navigation
IoT HomeKit query ordering causes update timeouts for legacy devices in 0.11.0.1 #1791
Description
Summary
Some legacy Kasa plugs stopped updating after Home Assistant 2026.10.0 to 2026.10.1, which changes its python-kasa requirement from 0.10.2 to 0.11.0.1. I reproduced the failure outside Home Assistant and isolated it to the ordering of the IoT HomeKit probe added in #1566.
On the affected devices, a request containing system.get_sysinfo followed by smartlife.iot.homekit.setup_info_get times out. Reversing those two module keys works, and querying HomeKit alone immediately returns {"err_code":-1,"err_msg":"module not support"}. Keeping HomeKit in a separate request restores normal updates.
This adds a minimal protocol reproduction and testing on three additional models to the HomeKit-probe regression reported in #1788.
Affected devices
The complete update failure and candidate fix were tested on four HS103, two EP10 and one KP115. The detailed request-ordering experiment and old-release comparison were performed on one representative of each model:
| Model | Hardware | Firmware reported by the device |
|---|---|---|
| EP10(US) | 1.0 | 1.0.2 Build 200915 Rel.085940 |
| HS103(US) | 5.0 | 1.0.3 Build 201015 Rel.142523 |
| KP115(US) | 1.0 | 1.0.7 Build 200825 Rel.100128 |
The tested devices do not expose the HomeKit module; the standalone query returns an explicit unsupported-module response.
Reproduction
Run this against an affected device using the legacy XOR protocol on TCP port 9999:
import asyncio
import sys
from kasa.iot import IotPlug
async def main():
device = IotPlug(sys.argv[1])
try:
await device.update()
await device.update()
finally:
await device.disconnect()
asyncio.run(main())With published 0.10.2, both updates succeed. With published 0.11.0.1, the initial update fails with:
kasa.exceptions.TimeoutError: Timeout after 5 seconds sending request to the device DEVICE_IP:9999:
Minimal failing request
{"system":{"get_sysinfo":{}},"smartlife.iot.homekit":{"setup_info_get":{}}}TCP connects successfully. The timeout occurs in XorTransport._execute_send() while awaiting the first four-byte response header, at self.reader.readexactly(self.BLOCK_SIZE).
Same queries, reversed order: succeeds
{"smartlife.iot.homekit":{"setup_info_get":{}},"system":{"get_sysinfo":{}}}The response contains both system information and the HomeKit unsupported-module error.
Standalone HomeKit query: succeeds
Request:
{"smartlife.iot.homekit":{"setup_info_get":{}}}Response:
{"smartlife.iot.homekit":{"err_code":-1,"err_msg":"module not support"}}Standalone system.get_sysinfo and normal update batches without HomeKit also succeed. Fresh connections were used between requests in the ordering experiment. Reordering the same commands without changing the payload length is sufficient to change the outcome, which isolates this from a general connectivity failure or merely exceeding a request/response-size limit. The firmware's internal parser implementation is unknown.
Tests performed
| Configuration | EP10 | HS103 | KP115 |
|---|---|---|---|
| Published 0.10.2, two updates | Pass | Pass | Pass, including energy readings |
| Published 0.11.0.1, initial update | Timeout | Timeout | Timeout |
| 0.11.0.1 with a standalone HomeKit probe before the regular batch | Two updates pass | Two updates pass | Two updates pass, including energy readings |
| Candidate patch keeping HomeKit requests separate | Two updates pass | Two updates pass | Two updates pass, including energy readings |
| Candidate patch on Python 3.14, disconnect between updates | Pass | Pass | Pass, including energy readings |
Proposed fix
Send HomeKit in its own request from the shared IoT modular-update path, then merge its response normally. The existing module support detection caches the unsupported response and omits HomeKit on subsequent updates. This retains HomeKit support without a firmware/model list or interpreting genuine communication timeouts as proof that a feature is unsupported.
The local candidate passes on all seven affected plugs. Supported HomeKit behavior is covered with the existing EP25 fixture; HS110 beta-firmware confirmation is still needed.
Related reports
- HS110(UK) v4.1 beta firmware times out with the HomeKit probe in 0.11.0.1 #1788: closely matching HomeKit-probe regression on HS110(UK) hardware 4.1 beta firmware. Direct sysinfo works and omitting HomeKit restores updates. The standalone-query behavior and candidate fix still need confirmation on that firmware.
- TP-Link HS103 issues home-assistant/core#185859: closely matching downstream HS103 report with the same hardware 5.0, firmware 1.0.3 Build 201015 Rel.142523, HA 2026.10.0 to 2026.10.1 regression, and request timeout. Comments also report HS100 hardware 4.1 and HS220 hardware 2.0 failures; those devices were not tested in this investigation.
- KLAP HS100(UK) hw 4.1 fails after HA bumped python-kasa to 0.11.0.1: "Bad status line" on /app/request #1790: potentially related HS100(UK) hardware 4.1 regression across the same HA/library upgrade, using IoT over KLAP. It reports a malformed HTTP response after a successful handshake rather than an XOR response timeout, so a shared cause is not established.
Activity
ewalker101 commented on Oct 11, 2026
Additional data point confirming this on KP115(US) hw 1.0 / fw 1.0.7 Build 200825 Rel.100128 (identical firmware to the KP115 above), plus results suggesting the trigger is not HomeKit-specific.
Raw XOR probes, one TCP connection each, 10 s timeout:
A made-up module placed directly after system hangs exactly like HomeKit, while any other position works. So on this firmware the trigger appears to be any unsupported module immediately following system, not HomeKit specifically. Size is ruled out (a 75 B request hangs while the 381 B 0.10.2 batch with a 2575 B reply works).
Suggestion: in addition to sending HomeKit separately, it may be worth probing any newly introduced iot module in its own request on first update, so a future module doesn't reintroduce the same failure on these devices.
Happy to test a candidate branch against this device.
igiannakas commented on Oct 13, 2026
Confirming this on HS110(UK) hw 4.1, fw 1.1.1 Build 201203 Rel.135822 also
psiberfunk commented on Oct 15, 2026
Confirming the same regression on two additional physical EP10(US) plugs, both with:
Both had been working normally. Their HA entities became unavailable together on October 11, immediately after the Core update, and the integration now repeatedly fails setup with Timeout after 5 seconds sending request to the device ...:9999.
I reproduced the request-order failure directly on both plugs, outside HA, using raw XOR requests over TCP port 9999. Each request used a fresh TCP connection and a 4-second socket timeout:
The reversed-order response includes valid system information and "smartlife.iot.homekit":{"err_code":-1,"err_msg":"module not support"} on both units. TCP connection establishment succeeds for the failing request; it times out waiting for a response.
This independently confirms the reported request-order regression on this exact EP10 hardware/firmware combination. At the time of this initial report I had not tested PR #1792; the follow-up below records the subsequent successful backport tests. No Home Assistant rollback was performed.
Follow-up: verified PR #1792's production change on both EP10s, including inside Home Assistant
I have now tested the exact _modular_update replacement from PR #1792, commit ee5061e37ccad6bd95cd2cacaa812a9db773817f, on the two EP10(US) hardware 1.0 / firmware 1.0.2 Build 200915 Rel.085940 plugs reported above.
Results:
How the temporary HA backport was applied:
The core assignment is:
This is a locally constructed temporary loader for testing/backporting the upstream production change, not an installation mechanism supplied or endorsed by the PR author. I tested its idempotence, refusal to patch unexpected original source, and skip behavior on a different library version. It does not rewrite installed library files; on a library-version change it becomes inactive and can be removed after verifying the official fix. A version change alone is not proof the fix is included.
Scope: two physical EP10s, repeated read updates, and HA service-to-real-relay control. I did not run the full upstream test suite or test a HomeKit-capable device, and this is immediate post-restart verification rather than a long-term soak test. No firmware upgrade or Home Assistant rollback was needed.
frogen1 commented on Oct 15, 2026
Confirming on HS103 (US), hardware 5.0, firmware 1.0.3 Build 201015 Rel.142523 (5 plugs): HA 2026.10.1 / python-kasa 0.11.0.1 times out; HA 2026.10.0 / python-kasa 0.10.2 works. Also reported downstream at home-assistant/core#185859.
Reproduced the ordering finding with raw XOR requests (no python-kasa), and compared against the same hardware on newer firmware:
fw 1.0.13 on the same hardware handles either order; the hang appears specific to fw 1.0.3.
Tested #1792 (commit ee5061e) with python -m kasa.cli --host <ip> --type plug state (Python 3.14, Windows): published 0.11.0.1 times out (~24 s with retries); commit ee5061e returns full state in ~0.8–1.0 s on all 5 HS103 fw 1.0.3 plugs and still works on the HS103 fw 1.0.13.