Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.22%. Comparing base (76d9f68) to head (8b1f6b8).
⚠️ Report is 14 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.