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!

  • silasmoeckel@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    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.

    • MikeP001@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      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.

      • silasmoeckel@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        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.

        • MikeP001@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 months ago

          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.

          • silasmoeckel@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            10 months ago

            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.

            • MikeP001@alien.topB
              link
              fedilink
              English
              arrow-up
              1
              ·
              10 months ago

              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.

              • silasmoeckel@alien.topB
                link
                fedilink
                English
                arrow-up
                1
                ·
                10 months ago

                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.

                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.

                • Silent-Piccolo@alien.topB
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  10 months ago

                  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.

  • MikeP001@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Right, the problem is that the kasa local API needs to be polled for state changes. Belkin wemo switches are similar in feel and they have a better local API - they send immediate state change event notifications (I can speak to whether the HA plugin uses them). The cheaper switches that can be flashed with Tasmota or similar could notify immediately over MQTT but their feel isn’t as solid.

    You could try a cloud based integration just for this switch, but 1-2s is probably as fast as you’d get.

    OTOH if you can live with 1-2s, it’s not really a bad solution - that polling rate isn’t going to do any harm to your network (though I agree it’s a stupid API).