IOT devices connected over KLAP are always built as IotPlug, never IotStrip — HS300 loses all child sockets #1748

Activity

1. luxardolabs commented on Aug 30, 2026

   

   luxardolabs

   on Aug 30, 2026

   Author

   More actions

   Credit where due — this was independently identified by @iamteedoh in #1604 three weeks ago: #1604 (comment)

   I hadn't seen it when filing. I've opened this as its own issue because that analysis is a comment inside a 48-comment thread about the authentication bug, and this is a separate defect that survives #1731 — but I'm happy for this to be closed in favour of that comment if you'd rather keep it in one place.

   Two things to add.

   1. Second independent confirmation, on a different firmware build. @iamteedoh reported HS300 hw2.0; mine are HS300(US) hw2.0 on 1.1.2 Build 241220 Rel.171333. Three units here, all reproduced, all fixed by the same change — so at least it isn't unique to a single build.

   2. Discover._get_device_instance() needs the same treatment, which my original post missed. Quoting @iamteedoh:

   Keying on the discovery model alone isn't enough. HA's coordinator reaches the device through a direct-connect path that carries no discovery info, so the model string is empty there. sys_info["children"] is the reliable signal, and both device_factory._connect() and Discover._get_device_instance() need covering.

   I only patched _connect(). That is sufficient for Home Assistant's setup path — all three strips came back with 18 entities, working per-outlet switching and per-outlet emeter — but a fix covering only _connect() would leave the discovery path still mis-typing strips as IotPlug.

   One more data point, in case it saves someone time: the Third-Party Integration workaround (re-opening port 9999 from the Kasa app) didn't work for me. The setting was already enabled on my account, and my three strips on 1.1.2 Build 241220 still return ConnectionRefused on tcp/9999, while another strip on the older 1.0.21 Build 210524 serves it normally. @beckerben's units were on 1.1.6 Build 240130 and it worked there, so I'd guess it varies by build — but that's only my two builds against theirs, so treat it as one report rather than a general conclusion.
2. luxardolabs commented on Oct 10, 2026

   

   luxardolabs

   on Oct 10, 2026

   Author

   More actions

   Update after 0.11.0.1: #1769 fixed the connect path, but discovery still builds these strips as IotPlug.

   Tested on 0.11.0.1 with no local patches, against three HS300(US) hw 2.0 on fw 1.1.2 Build 241220 (IOT.SMARTPLUGSWITCH / KLAP / login_version: 2):

   Path	Class	Transport	Children
   Device.connect(config=...)	IotStrip	KlapTransportV2	6 (per-outlet emeter works)
   Discover.discover() + update()	IotPlug	KlapTransportV2	0

   So #1731 fixed authentication, and #1769 fixed device_factory._connect. Discover._get_device_instance() still picks the class with get_device_class_from_family(type_, ...), where IOT.SMARTPLUGSWITCH maps to IotPlug. That path never sees sysinfo, so a strip found by discovery loses all its child sockets. update() now succeeds on it (on 0.10.2 it raised), so nothing signals that the class is wrong.

   Strips on fw 1.0.21 answer over XOR and come out of both paths as IotStrip, as expected.

   The workaround we run is to rebuild the device after update() when sys_info["children"] is non-empty, on the same protocol object:

   if isinstance(device, IotDevice) and not isinstance(device, IotStrip) and device.sys_info.get("children"):
       strip = IotStrip(device.host, protocol=device.protocol)
       await strip.update()

   A fix upstream could do the same in the discovery flow, or have _get_device_instance defer the IOT class choice until sysinfo is available, as _connect now does.