GeezerVison

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.22%. Comparing base (76d9f68) to head (8b1f6b8).
⚠️ Report is 21 commits behind head on master.

@@           Coverage Diff           @@
##           master    #1692   +/-   ##
=======================================
  Coverage   93.22%   93.22%           
=======================================
  Files         157      157           
  Lines        9815     9817    +2     
  Branches     1003     1004    +1     
=======================================
+ Hits         9150     9152    +2     
  Misses        472      472           
  Partials      193      193           

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

✅ Independently confirmed this fix works on real hardware.

I hit this exact bug on an HS103 (US) HW 5.0, FW 1.1.3 Build 250908 running on Home Assistant 2026.5.4 (python-kasa 0.10.2). Device reports with in discovery, but mapped it to (v1, MD5) — causing .

I independently arrived at the same fix (upgrading to when ) before finding this PR. Validated by:

1. Raw KLAP handshake1+2 with SHA-based (v2) hashes → ✅ success
2. Raw KLAP handshake1 with MD5-based (v1) hashes → ❌ mismatch
3. Patching identically to this PR → device fully controllable via python-kasa and HA

This is blocking real HA users — anyone with HS103/HS200/HS300/KP303 on newer firmware (HW 5.0+) can't add these devices. The fix is minimal, correct, and well-tested. Would love to see this merged. 🚀

Hey Brad! Another Brad here confirming this against real hardware.

I hit the same failure path in Home Assistant with a TP-Link HS103:

• Home Assistant Core: 2026.1.3
• python-kasa: 0.10.2
• Device: HS103(US), HW 5.0
• Discovery metadata:
  • device_type: IOT.SMARTPLUGSWITCH
  • mgt_encrypt_schm.encrypt_type: KLAP
  • mgt_encrypt_schm.http_port: 80
  • mgt_encrypt_schm.lv: 2
  • mgt_encrypt_schm.new_klap: 1

Before applying this patch, Home Assistant/python-kasa selected the normal KlapTransport path for IOT.KLAP and failed during handshake1:

Finding protocol for 192.168.5.241
Finding transport for IOT.KLAP
Created KLAP transport for 192.168.5.241
Handshake1 success ... Response status is 200
Device response did not match our challenge on ip 192.168.5.241

I applied the same selection logic from this PR inside the HA container and restarted HA. A direct transport-selection probe then showed:

login_version None -> KlapTransport
login_version 1    -> KlapTransport
login_version 2    -> KlapTransportV2

After that, the HS103 began authenticating/querying successfully from Home Assistant:

Device 192.168.5.241 query posted ... Response status is 200
Device 192.168.5.241 query response received
Finished fetching 192.168.5.241 data ... success: True

So this is another confirmation that IOT KLAP devices advertising lv: 2 / new_klap: 1 need KlapTransportV2; otherwise valid TP-Link credentials fail with the challenge mismatch. This PR is the minimal fix for the behavior I observed.

paging @rytilahti to review this PR

I independently validated this failure and the two-part fix against a real HS300 power strip through Home Assistant.

Environment and device:

• Home Assistant Core: 2026.6.4
• python-kasa: 0.10.2
• Device: HS300(US)
• Discovery/device data:
  • device_type: IOT.SMARTPLUGSWITCH
  • mgt_encrypt_schm.encrypt_type: KLAP
  • mgt_encrypt_schm.http_port: 80
  • mgt_encrypt_schm.lv: 2
  • mgt_encrypt_schm.new_klap: 1
  • port 80 open, port 9999 closed

Stock HA / python-kasa 0.10.2 failed immediately during reauth with valid TP-Link credentials:

Device response did not match our challenge

A direct KLAP v2 handshake succeeded with the same credentials, and IotProtocol + KlapTransportV2 was able to query the device successfully. I then patched HA's vendored integration locally with the same two behavioral changes as this PR:

1. select KlapTransportV2 for IOT.KLAP when login_version >= 2
2. use system.get_sysinfo during connect to pick the concrete IOT device class

After restarting HA, the reconfigure flow completed successfully and the config entry stored the credential hash. The sysinfo/class-detection part was also required: without that path, this HS300 gets treated as a generic IotPlug, losing the strip children. With both parts of the fix in place, HA created the strip plus all child outlets and energy/voltage sensors as available.

So this PR matches the fix required for HS300 as well as the HS103 confirmations above: the transport change fixes auth, and the sysinfo class detection fixes child outlet/entity creation for strips.

There is already an existing, extensively tested PR that handles all of the CLI and API changes, #1580, we are working to get this implemented and a new version released soon.

Adding KP303 power-strip evidence for the two changes in this PR, also relevant to #1580.

On 2026-09-02 I upgraded Home Assistant Core from 2026.7.2 to 2026.8.3, retaining a local backport on python-kasa 0.10.2 that:

• selects KlapTransportV2 for IOT KLAP with login_version >= 2;
• uses system.get_sysinfo to identify the concrete IOT device class, including strips and their children.

After replacing the HA container and restarting, the real KP303 parent and all three child outlets were still present. The outlet states remained one ON and two OFF, matching the pre-upgrade snapshot; none of those outlets became unavailable.

The candidate image also passed isolated checks with networking disabled: login version 1 selects KlapTransport, version 2 selects KlapTransportV2, and a get_sysinfo response containing children resolves to IotStrip.

Scope: this is evidence for an equivalent local backport and its HA restart/upgrade behavior, not a test of the complete #1692 or #1580 branch. The isolated class test calls the sysinfo class resolver, not the full connect() path. I did not issue physical outlet-toggle commands during this maintenance check, and I have not captured hardware/firmware revisions for this report.

I tried using this change for 2 of my HS200 that I updated and that stopped responding, it didn't work.
#1580 on the other hand worked right away.
Thanks for the great work though!