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.

he said affordable…

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.

Some silly stuff here. Wifi is not low latency, zigbee and other low rate networks are low latency esp across repeaters. Wifi rates are far, far higher. Slow zigbee response times are actually noticeable, fast local wifi appears instant to humans. Doesn’t matter much for IoT (pun not intended). I’m not a fan of setting up duplicate networks on the same band - was of money. I use zigbee for battery switches and sensors exclusively, lower cost wifi devices for everything else.

Wifi does not suffer dramatically from interference, esp neighbor interference - if it did, forget about zigbee with it’s weaker transmitters and forget router managed thread at 2.4GHz. Wifi is not a continuous carrier transmission protocol. It only transmits when it has data, and the closest transmitter will swamp out any transmitter further away. On the rare instances there is interference the protocol handles it easily and retransmits quickly, at wifi speeds there’s lots of dead space. Folks complaining about wifi interference are almost universally non-network people falling into a classic logical fallacy "I don’t know what it is so it must be ".

Wifi does suffer from crappy routers and APs that drop clients, udp, and multicast often used by wifi devices. Cloud devices suffer whether they’re wifi, or the hubs managed through the cloud (which they must be if you have remote access or google home integration.

Ok z-lots, let the unsubstantiated down votes fly!