I have a WiFi controlled LED light strip in my bedroom which I use as my main lights. I wanted to control them with a regular wall switch, so I installed a Kasa HS220 smart dimmer switch (not wired to any load) and wrote a Home Assistant automation. If you turn on the smart switch, the led lights come on via the automation, and similarly the brightness controls on the switch control the strip via the automation. So basically, the switch controls the lights “virtually” rather than physically.
The problem is that the Kasa switch has no way of telling Home Assistant that it has changed. Home Assistant can only poll it for changes. I’ve noticed that hitting the switch takes about 10 seconds for the lights to come on. I increased the polling rate and now I can get it to turn on in 1-2 seconds, but it’s just a stupid solution.
Any ideas for fixing this? I’m thinking that an MQTT switch could do the job, just not sure what is good to buy. I like Kasa’s hardware, it feels very solid while being affordable. But the software is dumb. I want full LAN control with events, not polling.
Thanks for your help!
Latency is often an issue and why wifi tends to be a poor choice, devices need to communicate with each other not just via the hub or worse several layers like your seeing. Throwing in poling makes it even worse.
Z-wave works well here you setup the association in your hub but the devices talk amongst themselves from then on.
It’s not latency, and latency is not often an issue with wifi. It’s because the kasa device needs to be polled. Wifi speeds are magnitudes higher than zwave.
Latency is that wifi devices don’t typically talk to each other and have to go out the the cloud and back again, that’s everything from the fairly minor network latency to processing to various polling etc times all put together. It’s not the medium rather the protocol thats running over it.
Z-wave is a lot slower but the latency between pressing a button and the light turning on far lower than your random wifi with a phone app and cloud junk. This is a function of the protocol used not the medium it’s working over.
He’s already using kasa locally with HA, cloud latency isn’t the issue. It’s that the kasa API needs local polling (not the best design). A wifi IoT network (that’s been configured properly) with proper devices that notify on state change will always be faster than slower networks like zwave and zigbee.
Only if they have a device to device communication channel that most wifi devices lack. Like I said the problem is not the medium but the protocol design. Wifi’s orders of magnitude faster throughput does not fix a bad protocol.
The original suggestion was that it was a wifi latency problem. It’s not, there is no perceivable latency due to using wifi. And it’s not cloud, this is a local API.
Kasa picked a poor implementation - there is indeed a TCP protocol standard available (UPNP/SSDP) that works very well over wifi and includes device to device eventing. Most devices, including kasa, don’t implement it - that’s a manufacturer failing. Don’t buy those, or at least buy the ones with a local API that will work with HA (et al).
Yes, zwave has a (expensive) way to solve it by building a redundant network. Most IoT users already have house wide wifi, and many already have a automation/consolidation hub like HA to work around the mismatched API. Zigbee works too, so does wifi if you pick the right devices.
Your fixated on wifi throughput. That’s what I originally said, it’s a protocol issue typical of wifi devices. Not that you can’t get wifi to work well rather that IoT over wifi tend to be implemented badly.
Again, the problem is not Wi-Fi or that the devices use Wi-Fi to communicate. The problem is the protocol that they are communicating with. You can’t immediately say that any Wi-Fi smart home device is inherently bad just because it uses Wi-Fi. Wi-Fi is synonymous with cloud control, but more and more products are including Wi-Fi and local control, including some official standards like matter and MQTT.