GeezerVison

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.45%. Comparing base (38a3184) to head (ee5061e).

@@            Coverage Diff             @@
##           master    #1792      +/-   ##
==========================================
+ Coverage   93.41%   93.45%   +0.04%     
==========================================
  Files         159      159              
  Lines       10113    10116       +3     
  Branches     1043     1044       +1     
==========================================
+ Hits         9447     9454       +7     
+ Misses        472      470       -2     
+ Partials      194      192       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Confirming this on HS110(UK) hw 4.1, fw 1.1.1 Build 201203 Rel.135822, the same model and firmware as #1788. I'm on HA 2026.10.1 with python-kasa 0.11.0.1. Discovery works, but the first update() times out three times on port 9999 and the config flow fails. An HS100(UK) hw 2.1 on fw 1.5.10 on the same network works normally.

I sent raw XOR requests directly to the plug, opening a new connection for each, with a 6 s timeout:

This firmware matches @ewalker101's finding: it hangs whenever an unsupported module comes directly after system. HomeKit sent on its own returns the unsupported error cleanly, and the rest of the batch works without it, so the #1792 approach should work for this device. Because foo.bar after system also hangs, it may be worth covering that general case too, so a future module doesn't reintroduce the bug.

I haven't run the #1792 branch yet. I'm happy to test it if that helps.

Confirmed the production change in this PR (ee5061e37ccad6bd95cd2cacaa812a9db773817f) restores two EP10(US), hardware 1.0, firmware 1.0.2 Build 200915 Rel.085940 plugs, both in an isolated macOS/Python 3.14 test and in Home Assistant OS 18.3 / Core 2026.10.1.

• Published python-kasa==0.11.0.1: initial update times out on both physical plugs.
• Exact candidate _modular_update method applied in memory: both complete two consecutive status updates, disconnecting between updates (approximately 0.12–0.27 seconds/update).
• Same replacement loaded inside HA using a temporary startup custom component: after restart, both config entries are loaded and both switch entities recover.
• HA switch.turn_on / switch.turn_off succeeds on both plugs. Independent direct get_sysinfo reads verify the real relays report 1 then 0; HA state publication settles in roughly one second. Both restored to their initial off state.

The temporary loader checks the exact library version and original/replacement source fingerprints, then constructs the replacement with FunctionType(candidate.__code__, original.__globals__, ...) and assigns it to IotDevice._modular_update. It uses the PR's unchanged method, retaining HomeKit queries as separate requests; it does not use the workaround that disables the HomeKit module. No installed library files, device firmware, cloud pairing, or firewall settings were changed, and no HA rollback was needed.

Full test results, installation method, guards, and limitations.

This confirms the PR's production change via a locally constructed runtime backport, rather than installing/testing the entire candidate package. I did not run the full upstream suite or test a HomeKit-capable device. This is immediate post-restart verification, not a long-term soak test.

For review: HS110(UK) hw 4.1 / fw 1.1.1 Build 201203 Rel.135822 is now confirmed too. That's the beta-firmware model from #1788, and the one gap #1791 called out. @AlecRust ran ee5061e on all three of their plugs: updates work, including after reconnecting, and energy readings are intact (comment on #1788).

So this commit now has real-hardware passes on EP10, HS103, KP115 and HS110(UK). KP100 (#1799) and HS200 (#1803) show the same failure signature but haven't been run against it yet.

Another confirmation matching #1803:

• HS200(US), hardware 5.0
• Firmware 1.0.2 Build 200819 Rel.105309
• HA Core upgraded from 2026.9.3 to 2026.10.2
• python-kasa 0.11.0.1

The switch stopped initializing after the upgrade. Power cycling the switch and restarting HA did not help. The Kasa app still controlled it locally with internet access blocked.

HA debug logs showed standalone system.get_sysinfo succeeding in about 0.11 seconds. The combined initialization query, with smartlife.iot.homekit.setup_info_get immediately after system, repeatedly timed out waiting for the response header.

A version-guarded custom component making HomeKit.query() return {} restored initialization and normal switching from HA after a restart.

To clarify, this validates the probe-suppression workaround, not this PR’s separate-request implementation. Thanks for working on the long term fix!

Tested PR #1792 against TP-Link KP100(US), hardware v3.0, firmware 1.0.1 Build 200831 Rel.142128.

Results:
python-kasa 0.10.2: Previously confirmed working.
python-kasa 0.11.0.1: Timeout during state query.

PR #1792 (ee5061e): Successfully retrieves device state.
Multiple consecutive state queries: Successful.

This confirms the proposed fix resolves the regression on KP100(US) hardware v3.0.

Thank you for working on this!

Another affected device, and it's a dimmer: HS220(US) hw 2.0, fw 1.0.4 Build 200907, python-kasa 0.11.0.1 (Home Assistant 2026.10.2). Same symptom as #1791: the first update times out, TCP connects, and every module answers fine on its own.

I haven't seen dimmers among the tested devices so far, and they add something relevant here: IotDimmer also registers the probe-only PIR and LAS modules (both reply module not support at module level on this device).

Raw TCP results, keys in the order sent:

Reading the diff, only HomeKit is moved into its own request, so on this dimmer the requests should be homekit alone, then system, schedule, anti_theft, time, cnCloud, PIR, LAS, dimmer. Both of those passed on this device (the second 5/5). I haven't run the PR itself on it.

Two observations that may matter for the fix. PIR and LAS aren't special-cased, so they avoid hanging here only because other modules sit between them and system. And the last row hangs even though nothing unsupported is adjacent to system, so "an unsupported module directly after system" doesn't look like the whole rule on this firmware. I can test this branch on the switch if useful.

Ah, thanks for taking a look @rytilahti

Yeah, I think you're approach is much better for the future when more modules will inevitably be added :)

Will close this one/defer to that. Thanks!