After I brought home a new LG TV a few months ago two of my Kasa sockets started activating briefly roughly every 11 minutes while the TV was on.

I raised this to TP-Link and their support was absolutely hopeless and eventually boiled down to replace the sockets at my expense because they are no longer supported or in warranty.

I found a similar issue on this forum but impacting HS220 that sounds very similar.

I have 6 sockets, a mixtures of HS100 and HS110, this issue impacts only HS100 v4.1 (and presumably the HS220) running firmware 1.1.1 which TP-Link advised me if the latest available for this hardware.

I also have HS100 v1.0 running 1.2.6 and, HS110 v2.1 running 1.5.10, none of these are affected by this.

I have isolated the problem on my network down to the format of the message sent by the LG TV when it attempts to discover devices on the network, this differs from the format of the message sent by the official Kasa app and other smart home systems like Home Assistant.

The message sent by the LG contains two commands, get_sysinfo and get_realtime, the latter is intended only for energy monitoring devices, it is ignored by well-behaved HS100 models. the Kasa app and Home Assistant only send get_sysinfo during discovery.

{system":{"get_sysinfo":{}},"emeter":{"get_realtime":{}}}

29 seconds after this command is sent, the HS100 v4.1 units crash and reboot, activating the relay. I have isolated this packet and can send it on demand reproducing this crash every time it is sent. Interestingly, sending get_realtime on its own doesn't trigger the crash, it only happens when sent as part of a multi-command message like this.

This is a major bug in firmware 1.2.6 and TP-Link are unwilling to fix it. I have informed LG of the problem this is causing but they are unwilling to address it in their WebOS software, I presume they source it from elsewhere and have little or no control over the Kasa integration they use. Unfortunately they also dont provide a way to disable it when you dont use it.

Other threads have recommended using a guest network which is a workaround because once they are out of the broadcast domain of the TV it cannot trigger the bug. However I'm not willing to modify my network to work around this problem.

Hopefully TP-Link will wake up to their responsibilities to their customers and fix this but I'm not holding my breath and will be switching to another vendor. I'm just leaving this here for other customers frustrated by their sockets behaving erratically and getting nowhere with TP-Link support on this issue.