This device has Wi-Fi — and still stays outside

Most smart home writing answers the question “how do I integrate this?”. This one answers the rarer question: when do I leave it alone?

Two devices in my house in Kapfenberg have Wi-Fi. For both there is a way to pull them into Home Assistant. For both I decided against it — for two completely different reasons.

One thing up front, because it matters for the first case: what follows is the state of the investigation as of August 2026. What Ayla does today I have not re-checked. The decision is dated, not eternal.

Case one: the grill

A Ninja Woodfire, a wood pellet grill with a core temperature probe. Exactly the device where an integration would make sense — you do not stand next to something that cooks for four hours.

There is even an integration for it. A community project, explicitly marked as a hobby effort: “published as-is, no support, no warranty”, seven stars, tested on a single model. The route runs through Ayla, the cloud platform the grills have been hanging off so far.

The project’s only open issue

It had been opened one day before my investigation, and it made the decision:

SharkNinja is moving its grills off this cloud, and once a grill has moved, this integration reports stale state forever without any sign that something is wrong.

The author had measured it: 24 hours across two real grilling sessions, 2367 requests, zero value changes. Home Assistant showed “idle” and “unknown” while the grill was mid-cook.

That is the worse kind of failure

Not “does not work” but “shows the wrong thing and says nothing”.

A device that is obviously broken costs you ten minutes of annoyance. A device showing plausible old values costs you dinner — and next time, your trust in every other sensor in the house.

With a core temperature probe that is more than annoying. A display saying “not done yet” because it froze two hours ago is worse than no display at all. Without a display you go and look.

There was a pattern on top of it: SharkNinja had introduced additional bot protection, which had already caught the integration for its vacuum cleaners. Somebody is systematically closing their cloud — which is their right, but it is also information.

What I noted instead

Not a refusal forever, but a checklist for later:

• Which version is the Ninja app on? Below a certain version the grill is presumably still on the old cloud and the integration would hold. Above it, that ship has sailed.
• The grill answers locally on port 80. What is there has not been investigated. If the cloud route fails for good, that is the next place to look.

That is the difference between “does not work” and “not now”. A device where I know where to start next time is not lost.

Case two: the switch I was not looking for

The second case is of a different kind. The Tuya switch on the water connection was not sought — it was left over as an unknown address after I had switched off a router feature.

And I nearly classified it wrongly

A scan across ports 1 to 1024 plus twenty common device ports found nothing.

The obvious conclusion: no open port, so a device that only phones outward. Not reachable locally, cloud-only, case closed.

Wrong. A second run across 1025 to 10000 found exactly one port — and it was not in the first list. It is the port of the Tuya local protocol.

A scan that finds nothing proves nothing. It only says that there was nothing in the range you chose. That is a lesson reaching far beyond this device.

Which protocol version the device speaks could then be read from its reply: in the older versions the version number sits in plain text in the payload, in the newer ones it does not. Here it did not.

Why it still stays outside

There are two ways to integrate such a device — one through the cloud, one purely local. The local one would be better.

The catch is the same for both: the local route needs a device-specific key, and you can only get it through a developer account with Tuya. Once obtained, it runs without the cloud afterwards — but you have to go through once.

And here comes the actual reason: the switch is currently unused.

Creating a developer account, extracting a key and maintaining an integration so that a switch which switches nothing appears in a list — that is exactly the kind of work that slowly makes a smart home unmanageable.

For clarity, because the situation invites the assumption: there is no automatic water shut-off set up there. The switch sits on the electrical connection, and what it would do in an emergency has not been tested. Writing about it as if it were a safety feature would be wrong.

A third case, very briefly

An energy storage unit in the same house has no open port at all. There is nothing to decide — the device offers nothing locally.

That is worth mentioning because it shows the range: a device can speak locally and still not be taken in, and another cannot speak at all. “Smart” says nothing about either.

How I judge an integration

Out of these cases came a checklist I now run through before every new integration:

1. What happens when the connection breaks? Does the device show “unavailable”, or does it keep showing the last value? Only the first answer is usable. The second is a trap.
2. Does it depend on somebody else’s cloud that somebody can switch off? Then the integration is a loan, not a possession.
3. Who maintains the integration? A hobby project with seven stars and one tested model is an experiment, not a foundation.
4. What will I do with the value? If the answer is “it will be in the dashboard”, the work is not justified.
5. What does the decision cost later? Adding a device later is cheap. Untangling an automation built on wrong values is not.

Point 1 is the most important and is almost never asked. Most integrations are judged on whether they work in the normal case. What matters is their behaviour when things fail.

So what?

Every household has devices that have Wi-Fi and still contribute nothing. Not integrating is neither laziness nor failure — it is a decision, and it deserves documenting just as much as a successful integration.

My yardstick is simple by now: an integration has to be able to do something the device cannot already do itself. The grill shows its temperature on its own display. The switch switches nothing. In neither case does Home Assistant add anything — except one more place where something can break.

And if you are thinking you would integrate the grill anyway: you might be right. Your app version may be a different one from mine back then, and then the route holds. The point is not the answer, but that the question gets asked.