There is a growing problem in the smart home space, and TP-Link is quickly becoming one of the clearest examples of it.
For years, Kasa and Tapo devices earned a strong reputation among home automation users because they were affordable, reliable, widely available, and, most importantly, useful outside of the manufacturer’s own app. For people running Home Assistant, OpenHAB, custom automations, segmented VLANs, local dashboards, and privacy-first smart homes, TP-Link’s smart plugs, switches, bulbs, cameras, and power strips were an easy recommendation.
They worked.
Then firmware updates and platform changes started making that less true.
A thread on TP-Link’s own Smart Home Community, titled “Third Party Integration (Home Assistant)”, has now become a public record of how frustrated customers are with the direction TP-Link appears to be taking. The thread started in May 2025 after Kasa/Tapo devices that had previously worked with Home Assistant began failing authentication, losing local control, or becoming unreliable after firmware changes. The original complaint was simple: customers bought these devices because they integrated well, and now that integration was being restricted or broken.
That thread has continued growing for more than a year.
As of this writing, it has over 30 replies and more than 50,000 views. People are still finding it. People are still commenting. People are still asking TP-Link for an answer. And people are openly saying they are returning products, avoiding future purchases, ripping out Kasa and Tapo devices, and moving to competitors.
That should concern TP-Link.
Instead, the only meaningful official response in the thread came from Wayne-TP, a TP-Link community representative, who stated that Home Assistant is not a supported third-party platform, that the Kasa/Tapo API has not been released to the public, and that using unsupported third-party platforms could pose security risks. Wayne-TP also pointed users toward TP-Link’s “Third-Party Compatibility” option, while making clear that enabling it does not guarantee functionality.
That answer has not aged well.
The Problem Is Not That Home Assistant Is Unsupported
Companies are allowed to decide what they officially support. Nobody is arguing that TP-Link support should troubleshoot every custom Home Assistant dashboard, every HACS integration, every VLAN rule, or every home lab network.
That is not the issue.
The issue is that many customers bought TP-Link devices because they worked locally and because they fit into larger smart home ecosystems. They bought switches, plugs, bulbs, cameras, power strips, hubs, and networking hardware around that expectation. Some users in the thread describe dozens of TP-Link devices in their homes. One user said they had 59 TP-Link devices. I personally had 68 TP-Link smart devices, not counting my Omada infrastructure.
That is not casual use.
That is ecosystem-level investment.
When a firmware update changes the behavior of those devices in a way that breaks local control, breaks Home Assistant integration, forces cloud dependency, or makes the devices unreliable in advanced network setups, customers are not simply “using an unsupported app.” They are losing functionality that influenced their purchasing decisions in the first place.
That distinction matters.
TP-Link can say the API was never officially public. That may be technically true. But customers do not experience this as a licensing footnote. They experience it as devices that worked yesterday and stopped working after an update. They experience it as automations that no longer fire, power monitoring that no longer reports properly, switches that become unreachable, cameras that require re-authentication, and smart home systems that suddenly become less smart.
That is not a Home Assistant problem.
That is a customer trust problem.
“Security” Cannot Be the Entire Answer
TP-Link’s stated concern is security. According to the company’s messaging, using third-party applications may require users to enter TP-Link account credentials into platforms that have not gone through TP-Link’s security review. TP-Link’s FAQ also warns that enabling Third-Party Compatibility may reintroduce previously addressed security risks and that users accept associated risks if they enable it.
Security matters. Nobody serious is arguing otherwise.
But using “security” as a blanket explanation for reducing local control is not good enough.
A local-first smart home is not inherently less secure than a cloud-first one. In many properly designed networks, local control is the more secure and more resilient model. Advanced users often segment IoT devices onto VLANs, block unnecessary outbound traffic, restrict internet access, and keep automation logic inside their own network. Home Assistant users are often exactly the kind of customers who understand those tradeoffs.
That is part of why the response from TP-Link landed so poorly.
The implication felt like this: because Home Assistant is not officially supported, users should accept degraded functionality, cloud dependency, or unreliable behavior. That may satisfy a legal or support policy internally, but it does nothing for customers who bought hardware expecting it to keep working the way it already had.
If security is truly the concern, TP-Link has several options that would be more constructive than quietly breaking local behavior:
- Publish a documented local API.
- Provide an official Home Assistant integration.
- Offer a supported local-only mode.
- Create scoped local tokens instead of requiring full TP-Link cloud credentials.
- Add clear firmware release notes warning users before changes affect local or third-party integrations.
- Make Third-Party Compatibility a serious, stable feature instead of a disclaimer-heavy toggle that may or may not work.
That would be a security-minded approach.
Simply saying “unsupported” is not.
The Community Is Not Asking for Something Unreasonable
The thread is full of people asking for the same basic thing: let us control the devices we bought.
One user said they had a large number of Tapo/Kasa cameras, lights, and plugs that they could no longer control properly through Home Assistant, comparing the situation to other companies locking down previously open workflows. Another said they had moved from SmartThings to Home Assistant and was surprised to find that TP-Link was the weak point in an otherwise functioning smart home. Another had been planning a new home build and said TP-Link was no longer going to be part of it. Others said they were returning Black Friday purchases, avoiding future Tapo/Kasa products, moving to Matter, Zigbee, Z-Wave, Reolink, Ubiquiti, Inovelli, or other local-first alternatives.
This is not one angry customer.
This is a pattern.
There are also practical reports from users saying the “Third-Party Compatibility” toggle is not a complete solution. Some users report devices working only under certain network conditions, such as when everything is on the same subnet. Others report devices becoming unreliable after power outages or requiring the toggle to be switched off and back on again. Some describe newer firmware or newer units behaving differently from older ones. Others say they bought additional units only to find that the new devices would not integrate like the old ones did.
That kind of inconsistency is poison for home automation.
The whole point of smart home infrastructure is that it should be dependable. A switch should switch. A plug should report state. A power strip should reconnect after an outage. A local automation system should not require a guessing game after every firmware update.
TP-Link’s Silence Is Making It Worse
The most frustrating part is not just that something changed.
It is that TP-Link has not clearly explained what changed, why it changed, what devices are affected, what firmware versions are affected, whether the behavior is intentional, whether it will be rolled back, whether a supported local path is coming, or whether Home Assistant users should simply move on.
That silence is doing damage.
The thread started in May 2025. The representative response arrived shortly after. Since then, customers have continued adding their own experiences. The thread has continued gaining views. More users are finding it while researching purchases. Some are saying they found the thread before buying and chose competitors instead.
That is a direct sales impact.
This is the kind of issue that should have been escalated internally months ago. Product, firmware, support, security, community management, and leadership should all know that customers are publicly losing confidence in Kasa and Tapo. If Wayne-TP is representing TP-Link on the company’s own forum, then surely there is some communication channel back to the people who make these decisions.
If there is not, that is its own problem.
If there is, then the lack of a real response is hard to defend.
The Bigger Issue: Do We Own Our Smart Devices?
This is bigger than TP-Link.
The smart home industry keeps drifting toward a model where customers pay full price for hardware but only get full functionality as long as the vendor’s cloud, app, roadmap, account system, and business priorities allow it.
That is not ownership.
That is renting convenience from a company that can change the rules later.
A local API matters because it gives customers continuity. It lets devices continue working when the internet is down. It lets privacy-conscious users keep device traffic inside their own network. It lets advanced users build resilient automations. It lets communities like Home Assistant extend the useful life and value of hardware long after a vendor’s app stops being enough.
TP-Link benefited from that ecosystem.
Kasa and Tapo devices became common in Home Assistant homes because the community made them useful there. People recommended them. People bought them in bulk. People built homes around them. That kind of word-of-mouth is incredibly valuable.
Breaking that trust is expensive.
It may not show up immediately in a quarterly report, but it shows up when a user returns $500 worth of devices. It shows up when someone wiring a new house decides not to use TP-Link. It shows up when a long-time customer replaces Omada, Deco, Kasa, and Tapo with competitors. It shows up when search results lead potential buyers to a forum thread full of people saying “do not buy this if you care about local control.”
What TP-Link Should Do Now
TP-Link still has time to fix this, but the company needs to stop treating this like a niche complaint.
Home Assistant is not fringe anymore. Local control is not fringe. VLANs are not fringe. Matter, Thread, Zigbee, Z-Wave, RTSP, ONVIF, local polling, privacy-first automation, and mixed-vendor homes are not fringe. They are normal parts of the modern smart home market.
Customers are not asking TP-Link to support every random open-source project on the internet. They are asking TP-Link to stop breaking local functionality and to provide a stable, documented path forward.
A reasonable response from TP-Link would include:
- A public statement acknowledging the issue.
- A list of affected Kasa and Tapo models and firmware versions.
- Clear firmware release notes before changes affect local or third-party integrations.
- A real local-control mode that does not depend on cloud availability.
- A documented local API with proper authentication.
- A supported Home Assistant path, either directly or through collaboration with the Home Assistant maintainers.
- A better explanation of what “Third-Party Compatibility” actually enables, what it does not enable, and why it behaves inconsistently for some users.
- A commitment not to remove existing local functionality without warning.
That would not just calm the thread down.
It would restore confidence.
The Bottom Line
TP-Link built a lot of goodwill with smart home users because Kasa and Tapo devices were practical, affordable, and easy to integrate. That goodwill is being burned by vague security explanations, unreliable compatibility, poor communication, and the appearance of a shift toward vendor lock-in.
The official stance may be that Home Assistant is unsupported and the API was never public.
Fine.
But that answer does not solve the problem.
Customers bought devices that worked. They built systems around them. They trusted TP-Link enough to invest in dozens of devices, and in some cases entire home networks. Now those same customers are asking for local control, transparency, and a stable path forward.
That is not unreasonable.
It is exactly what the smart home market now expects.
TP-Link can keep fighting that change, or it can meet its customers where they already are.
Right now, the silence is saying more than the company probably realizes.