tado integrated locally — then six weeks of wrong diagnoses

Twelve thermostats in the Vienna flat, eight radiator heads and four room thermostats. The goal: control them locally, without an account and without a subscription.

That works. But it has two blind spots you should know about in advance — and afterwards it sent me in the wrong direction four times over six weeks.

The detour that was necessary

Home Assistant offers a tado dialog of its own accord. That one leads into the cloud. The local route has a different name and has to be started by hand.

On the first attempt the local route did not offer tado at all. Measured via the service announcement on the network:

tado Internet Bridge ..._hap._tcp.local
    sf=0  ->  already paired

For comparison, the Hue bridge stood next to it at sf=1, meaning free.

A HomeKit accessory only ever allows one controller. Here it was the Apple Home hub in the living room. Only after the home there had been deleted did the field jump to 1, and the pairing went through on the first try.

A HomeKit accessory is not a shared device. Pair it and you take it away from the other side.

Matter would have been the better route — it provides for several controllers at once. But the bridge did not advertise it in its announcements, and whether it could do it in principle remains unclear.

One small check that saves time: HomeKit codes have eight digits, Matter codes eleven. My pairing script checks the length and stops with a note when it does not match — instead of failing on a code meant for the other method.

What arrived

13 devices, 61 entities: temperature and humidity per device, plus the twelve actual thermostats, the display unit and an “Identify” button.

Control has run entirely inside the house ever since. No account in daily operation, no subscription, no dependence on being reachable from outside.

The two blind spots — the price of the local route

There is not a single battery sensor. Not one among 61 entities. On this route tado does not publish the battery level.

Which means: unavailable is the only warning signal. There is no “battery low” warning in advance; a head simply fails without notice — in the middle of the heating season, in a room you are not currently entering. Want it otherwise and you need the cloud connection, and with it an account and a subscription.

And there are no room names. Over HomeKit the devices are named by model and serial number. Checked in the entity map: each accessory carries exactly one name, and that name is the model designation plus number. The bridge’s local interface answers on no path at all.

I solved that with a one-off read through the account, using the device flow: the script requests a code, a human confirms it in the browser, and a token comes back.

Claude never gets to see a password in the process. And it was a one-off read — control continues to run locally.

One trap was hiding in the matching: one room thermostat is named differently in the two systems, same number, different beginning. So the renaming does not only match on equality but also on the end of the name. The other twelve matched word for word — which is exactly why the special case nearly slipped through.

And then operation: four diagnoses, four errors

After integration, three of twelve devices reported in. The rest were silent. That part was simple: the batteries had to be replaced.

After that it got murky. Two devices stayed away, and over six weeks Claude wrote four interpretations for it:

Interpretation	disproved by
weak battery	the account reported the battery state as normal
genuine device failure	a bridge restart brought both back in 19 minutes
a damaged network cable	new cable, new socket — state unchanged
a failed negotiation at 10 Mbit	my own remark: “that is an ancient bridge, check whether it can only do 10 Mbit”

Each of these rested on one observation, and each was plausible.

The finest error was the last one

10 Mbit half duplex is normally the fallback of a failed negotiation. That holds as a rule, and that is exactly how Claude read it.

Here it was the device’s ceiling. tado’s own help even describes the situation the other way round: some newer routers no longer support 10 Mbit half duplex at all, and then the bridge cannot be connected there; the advice is to put an older switch in between.

That also explains why neither the socket change nor the new cable changed anything: there was nothing to change. Both sides correctly negotiated what the device has to offer.

A rule that almost always holds becomes a trap when you forget the exception: a device that never could do more.

And a warning for anyone now thinking this can be forced: do not fix the port to the faster setting. The switch offers it, the bridge does not. The result would be no link or a duplex mismatch — and the heating control would be gone until somebody on site puts it back.

My rule of thumb was wrong too

Along the way I had built myself a rule: if the account and the local view contradict each other it is the bridge; if both say the same thing it is the device.

That is not right. It misses exactly the case at hand: the bridge had lost the two devices and never looked for them again — and the account merely relayed that loss. Both said the same thing, and the device was fine.

If both say the same thing it can be the device or the bridge. Before you give up on a device, restart the bridge.

The real lesson came at the end

Six weeks of individual observation, four interpretations, each from a look at the current state.

The answer had been in the database the whole time. Home Assistant records the history. A single query over thirty days would have shown on day one what six weeks of looking never settled: how often, how long and in what pattern those two devices had actually been gone.

Where the recorder is writing, count instead of concluding.

What I’d suggest

1. Check before pairing whether the accessory is free. The status field in the service announcement says so. It saves you the false conclusion that “the integration cannot do this”.
2. Expect pairing to take it away elsewhere. With HomeKit that is not a defect, it is the design.
3. Ask about the battery sensor before buying — not whether the device has a battery, but whether the route you intend to use reports its level.
4. Read once what is missing locally, and say so plainly. Fetching names through the account is fine, as long as control stays local and stays that way.
5. Do not force a link setting a device cannot deliver. The damage outweighs the gain.
6. Count before you interpret. If your system records history, one query over thirty days is worth more than thirty glances.

Update of 07.11.2026: it has got worse

This article used to end with a solved problem. That is still true of the question it asked — and no longer true of the installation.

Since publication, devices no longer drop out one at a time but in growing numbers:

Date	lost from HomeKit	zones with no device at all
13.09.	1	—
01.10.	4	—
07.11.	6	two

That defeats my safeguard. The heating scenes address every device of a zone individually, so a room does not stall when one drops out. That holds as long as one device is left. Two rooms now have none and cannot be set from Home Assistant at all.

The counter-check says the same thing every time: through the account, tado has contact with all twelve devices. It is the HomeKit path, not the heating.

So far the only thing that has helped is restarting the bridge — pull the plug, wait ten seconds. Last time all twelve were back within three and a half minutes.

Pulling a plug every two weeks through the winter is not maintenance, it is a workaround. From here on, replacing the bridge becomes the more honest solution.

And the ten megabits remain no argument. That is the device’s ceiling and was never the fault — the escalation from one to six is the argument.

What this leaves open

• Swap two radiator heads for two others from the same flat. That decides between device and location and costs nothing.
• Watch the error counter on the switch port the bridge hangs off. If it stays put, the old cable caused the error packets back then.
• Build a battery warning through the account — the local path does not provide one, and that is the point in this article that bothers me most by now.

So what?

The verdict on the local route is clear: it works and it is worth it. The heating depends on no account, no subscription and no reachability from outside.

You pay with two things you have to plan for — no advance battery warning and no room names — and with a bridge running at the edge of its design, which it never concealed. I just did not believe it for six weeks.

That the matter was cleared up in the end is not down to the diagnosis. It is down to one sentence that doubted an assumption nobody had tested for six weeks because it counted as settled — and that sentence was mine, not Claude’s.