Repository navigation
KLAP HS100(UK) hw 4.1 fails after HA bumped python-kasa to 0.11.0.1: "Bad status line" on /app/request #1790
Description
Summary
A UK HS100 (hardware 4.1, KLAP firmware) stopped working in Home Assistant after updating from 2026.10.0 to 2026.10.1. That release bumped python-kasa to 0.11.0.1. The KLAP handshake succeeds (a TP_SESSIONID cookie is issued), but the following POST to /app/request gets a response with no HTTP status line, which aiohttp rejects.
Rolling Home Assistant back to 2026.10.0 fixes it immediately. A second HS100 on the legacy (port 9999) protocol is unaffected.
Device
- Model: HS100(UK)
- Hardware: 4.1
- Firmware: 1.1.0 Build 201016 Rel.175121
- Discovery reports: encrypt_type: KLAP, http_port: 80, is_support_https: False
- Device type: IOT.SMARTPLUGSWITCH
Failing environment
- Home Assistant 2026.10.1
- python-kasa 0.11.0.1
- aiohttp 3.14.4
- Python 3.14
Working environments
- Home Assistant 2026.10.0: same device, same credentials, no other changes
- python-kasa 0.7.7 CLI on macOS (aiohttp 3.13.5, Python 3.9): kasa --host <ip> --username … --password … --debug state completes the handshake and returns full sysinfo, schedule, time and cnCloud data without errors
Error (Home Assistant 2026.10.1)
Connection error: ('Unable to query the device: 10.1.0.170: 400, message="Bad status line:\n Expected HTTP/, RTSP/ or ICE/:\n\n b\'<html><body><center>200 OK</center></body></html>\'\n ^", url=\'http://10.1.0.170/app/request?seq=-225400294\'')
Request headers on the failing call:
Host: 10.1.0.170 User-Agent: HomeAssistant/2026.10.1 aiohttp/3.14.4 Python/3.14 Accept: */* Accept-Encoding: gzip, deflate, br Cookie: TP_SESSIONID=<redacted> Content-Length: 368 Content-Type: application/octet-stream
Steps already tried
- Removed the device from Home Assistant and the Kasa app, re-added it to Kasa, then re-added it to Home Assistant: same error
- Confirmed the device responds correctly over KLAP locally using the python-kasa 0.7.7 CLI
- Confirmed the regression is tied to the Home Assistant 2026.10.0 → 2026.10.1 upgrade (rolling back restores normal operation)
Notes
On /app/request the device returns a bare HTML body with no status line. Something in the request sent by 0.11.x (headers, connection reuse, or request format) appears to trigger a non-compliant fallback response from this firmware. I can run the 0.11.0.1 CLI with --debug against the device and provide output if useful.
Activity
MrTrag commented on Oct 11, 2026
Hi, thanks for python-kasa, it looks after all our TP-Link plugs in Home Assistant. Same here, with the identical device.
In case it helps narrow it down, another HS100(UK) hardware 4.1 here on older firmware (1.0.6 Build 210522 Rel.141044) is still working after the same update, as are our hardware 1.0 HS100s on 1.2.6.
Happy to send more details or test a fix if that would help. Thanks again.
bpaludo commented on Oct 14, 2026
Possibly related: the same error class on a Tapo C210 camera (smartcam over HTTPS / SslAesTransport), not KLAP.
Environment: Home Assistant 2026.10.1 (HAOS 18.3), python-kasa 0.11.0.1, aiohttp 3.14.4, Python 3.14.6.
Device: Tapo C210, firmware 1.2.7 Build 260818 Rel.64715n. Five identical cameras, added through the HA TP-Link integration with live_view=false.
What the kasa debug log shows (stok/IP redacted):
The camera puts a fragment of the request it just received in front of its real HTTP/1.1 200 OK, with the header separators replaced by NUL bytes. (My log redaction collapsed the part between stok= and the Host value, so I can't show those bytes.) aiohttp rejects the status line, so every module query becomes INTERNAL_QUERY_ERROR (-100001) and the entities go unavailable.
Behaviour:
Not tested: whether HA 2026.10.0 or python-kasa 0.10.x avoids this on this camera.
I can run the CLI with --debug against one of these cameras if that would help.