I upgraded HA to 2026.3.4 recently and the TP-Link Deco integration broke.
It appears to still connect to to the main Deco (I have 3x M5), find the other units, and gets a list of connected clients, but no further data and the client statuses are all listed as “Unavailable”. I tried deleting and reinstalling the integration, restarting HA, etc., with no change in behaviour.
Looking at the logs in HA there are a lot of 500 API errors relating to it.
Rolling back my docker container to 2026.3.3 resolves the issue, so something’s changed in this release that is causing the issue.
I note, sadly, that the integration is no longer updated by the owner (it’s flagged as in Maintenance Mode). Hopefully someone else will pick it up. I’ve raised a Github Issue .
HA itself is also throwing these errors:
File "/config/custom_components/tplink_deco/coordinator.py", line 49, in async_call_and_propagate_config_error
return await func(*args)
^^^^^^^^^^^^^^^^^
File "/config/custom_components/tplink_deco/api.py", line 218, in async_list_clients
return await self._async_call_with_retry(self._async_list_clients, deco_mac)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/tplink_deco/api.py", line 541, in _async_call_with_retry
return await func(*args)
^^^^^^^^^^^^^^^^^
File "/config/custom_components/tplink_deco/api.py", line 225, in _async_list_clients
response_json = await self._async_post(
^^^^^^^^^^^^^^^^^^^^^^^
...<4 lines>...
)
^
File "/config/custom_components/tplink_deco/api.py", line 456, in _async_post
raise err
File "/config/custom_components/tplink_deco/api.py", line 413, in _async_post
response.raise_for_status()
~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 636, in raise_for_status
raise ClientResponseError(
...<5 lines>...
)
aiohttp.client_exceptions.ClientResponseError: 500, message='Internal Server Error', url='https://192.168.1.110/cgi-bin/luci/;stok=71e36e09e65d86be1055c39adde9aa3b/admin/client?form=client_list'
The APs regularly seem to return HTTP 500 status errors for the web UI, but HA 2026.3.3 seemed to handle them more gracefully.
Looking at it a little more closely: the client_list request is sporadically successful, but when it fails (and gets a 500) the clients are all marked as “Unavailable”. This results in clients flip-flopping between a status of “Home” and “Unavailable”.
This is observed behaviour on HA 20206.3.4, on 2026.3.3 it’s not so eagre to mark them as unavailable. I guess it backs off and retries?
Never mind, it seems related to this bug:
opened 03:34PM - 14 Mar 26 UTC
## Problem
In a multi-node Deco mesh setup, `TplinkDecoClientUpdateCoordinator.… _async_update_data()` uses a bare `asyncio.gather()` to fetch client lists from all nodes in parallel. If **any single node** returns an error (HTTP 500, timeout, connection refused), the entire gather fails with an unhandled exception, and **all** device trackers go to `unavailable` — not just the ones connected to the failing node.
This causes false "away" presence detection events, which in turn triggers automations incorrectly (e.g. arming alarms, turning off lights when people are actually home).
## How to reproduce
1. Set up a Deco mesh with 2+ nodes
2. Use `device_tracker` entities for presence detection
3. Wait for one node to return an intermittent HTTP 500 (this happens regularly on Deco BE63 firmware 1.2.10, and has been reported across many Deco models)
**Expected:** Only clients on the failing node lose tracking; clients on healthy nodes continue updating normally.
**Actual:** All clients across all nodes go `unavailable` simultaneously.
## Root cause
The current code in `coordinator.py` (line ~252):
```python
deco_client_responses = await asyncio.gather(
*[
async_call_and_propagate_config_error(
self.api.async_list_clients, deco_mac
)
for deco_mac in deco_macs
]
)
```
`asyncio.gather()` propagates the first exception from any task, so a single node failure aborts the entire update cycle.
## Proposed fix
I have a fix ready in PR form that:
1. Wraps each per-node fetch in `_async_fetch_clients_for_deco()` which catches errors per-node while still propagating `ConfigEntryAuthFailed`
2. Tracks which nodes failed (`failed_deco_macs`) vs succeeded
3. Preserves last-known client state for devices on unreachable nodes instead of marking them offline
4. Only raises `UpdateFailed` when **all** nodes fail simultaneously
I've been running this patch in production for over a month on a 2-node Deco BE63 mesh. It handles the common case (one flaky node returning 500s) gracefully — presence detection stays stable even with hundreds of per-node errors per week.
## Related issues
- #39 — earliest report of this problem (Feb 2022)
- #95 — feature request for preserving last state
- #276 — devices permanently showing `not_home`
- #294 — same `asyncio.gather` → `TimeoutException` failure path
And a reboot of my Decos solved the immediate problem. Hopefully the PR is accepted and this is fixed.
It doesn’t seem to have been a problem specific to 2026.3.4 after all, it just manifested for me coincidentally.
drenkin
March 25, 2026, 7:31pm
5
Hi
I have a TP Link KH100 Hub and indeed after the upgrade to HA 2026.3.4, the integration to my Smart Radiator Thermostats stopped working, which means also my central heating integration.
What do you mean by “reboot of my Decos”?
I restarted the KH100 but it didn’t help.
The rolled back fixed the problem.
Hopefully the integration gets quickly fixed.