Sure, but that’s the OP’s problem, not mine :)… Already lots of alternate suggestions to his problem, I didn’t need to pile on. When I checked the only answers close to what he ask was “no” which is wrong. A separate kasa account for this solves the problem. And it’s easy to reset the kasa to gain it back if the relationship sours since he has physical control of it.

Lots of other solutions provided, but to answer your question, yes, you can give them your kasa (or tapo) account log in information which would let them control all of your kasa/tapo stuff (including cameras if you have them).

You could create a separate kasa account, then reset your porch light kasa switch and join it to the new account. Then just share that account with your neighbour, she’ll be able to control it from her home wifi via remote access. You won’t be able to integrate the porch light with alexa or any other kasa devices on your main account once it’s separate.

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.

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.

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).

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.