Smart home standards keep fighting, and your house is the battlefield

This is written to be used rather than admired. Each section below is a decision about smart home standards, and each one has a default.

Three layers, three chances to be incompatible

A device has a radio protocol, an application layer that defines what its messages mean, and an ecosystem that decides which assistants can control it. Two devices can share a radio and still not interoperate because they disagree at the application layer. Most consumer confusion comes from marketing that names only one of the three.

The recent standardisation effort targets the application layer specifically, which is the right layer and not the whole problem.

Mesh protocols exist for good reasons

Zigbee and Thread build low-power mesh networks where mains-powered devices relay for battery-powered ones. This gives long battery life and good coverage without loading the Wi-Fi network with dozens of clients.

It also requires a bridge or border router, which is the component people forget to buy. Battery-powered nodes achieve their runtime by sleeping and waking only to report, so commands sent to them are held by a parent device until they check in, which is why a sensor responds instantly and a battery-powered valve does not.

Cloud dependency is the real risk

A device that routes commands through a manufacturer's servers stops working when those servers do, and several product lines have been discontinued exactly this way. This has happened often enough to be a predictable category of failure rather than a rare accident. The question worth asking before purchase is whether the device functions with no internet connection at all.

The end is rarely announced as a shutdown: support quietly stops, the app is withdrawn from the stores, and the device dies at the next phone replacement rather than on a date anybody published.

Local control changes the calculation

Devices that expose a local interface can be controlled by home automation software running on your own hardware, independent of any vendor. That converts a subscription risk into a maintenance responsibility, which some people want and many do not. It is also the only way to guarantee a device outlives the company that made it.

The responsibility is genuine, because a local system needs its own backups and updates and a plan for the household when the person who configured it is away or no longer interested.

What to check before buying

Whether it works without internet, whether it needs a proprietary hub, which ecosystems it is certified for, and how long firmware support is promised. Certification logos on the box answer more of this than product descriptions do.

In practice, anything requiring an account to perform its basic function should be assumed to be temporary. Certification is granted against a version of a specification, so a logo records what the device could do when it was tested rather than what it supports after two years of updates on both sides.

Firmware updates change this behaviour more often than hardware does.

Radio range in a house is not what the box says

Low-power mesh radios are specified in open air, and plasterboard, foil-backed insulation, tiled walls, mirrors and metal appliances all attenuate them severely. Every mains-powered node is usually also a repeater, so the order in which a network is built determines its shape as much as the floor plan does.

At the protocol level, adding a repeater in a dead spot achieves nothing if the repeater itself cannot hear the hub, which is the most common installation mistake and the hardest to see from an app that only shows which devices are online. Some mesh standards share the crowded 2.4GHz band with Wi-Fi while others use sub-gigahertz spectrum that travels further through walls, and that choice is made for you when you pick an ecosystem.

The takeaway

Ask whether it works with the internet unplugged. That one question filters most of the market.

Once you know what it is trading away, the design stops looking arbitrary.