Smart Home Compatibility: What to Check Before You Buy Anything

Smart home buying goes wrong in a specific way. Each device works perfectly on its own, and the collection does not work together — three apps, two assistants, a hub that supports some things but not others, and automations that break whenever one manufacturer changes something.

Almost all of it is avoidable by asking compatibility questions before the first purchase rather than after the fourth. This guide sets out the questions.

The four layers of compatibility

“Compatible” is used for four different things, and a device can be compatible at one layer and useless at another.

The radio layer. How the device communicates physically — which protocol it speaks. Devices on different protocols cannot talk directly and need something to bridge them.

The application layer. The common language that lets devices from different makers understand each other’s capabilities. Two devices can share a radio protocol and still not interoperate without this.

The control layer. The app or platform where devices are managed and automations are built. This is where fragmentation is felt daily.

The voice layer. Assistants, which sit on top of everything else and typically expose only a subset of a device’s capabilities.

When a box says “works with” something, establish which layer it means. The claim is often true at the voice layer and much weaker at the control layer — and that gap is where most disappointment lives.

Protocols and standards, decoded

Wi-Fi provides the network connection through your router. It does not, by itself, tell you whether a separate controller, manufacturer app or cloud account is required.

Bluetooth is used for setup and for short-range, often battery-powered devices. Limited range and generally dependent on a nearby phone or bridge.

Low-power mesh protocols — the family that includes Zigbee, Z-Wave and Thread — are designed for smart home use: low power, long battery life, and mesh networks in which mains-powered devices relay for battery ones. They require a hub or border router to bridge onto your network.

Matter is an application-layer standard rather than a radio, designed to run over Thread, Wi-Fi and Ethernet so devices from different manufacturers can interoperate through a common language.

The practical implication: a device’s protocol determines what infrastructure it needs, and its application-layer support determines what it can work with. Both belong on the specification checklist, and a listing that omits either has told you something — the reading habit from product specifications explained.

Hubs: when you need one

Separate the network connection from the controller. Matter-over-Thread needs a Thread border router to reach the home IP network; the Matter controller manages devices and commands. Both roles may be built into one product. See the Connectivity Standards Alliance’s explanation of controllers and border routers.

A hub can bring several devices into one app, but check its supported protocols and where each automation runs. A hub label alone does not establish offline operation or compatibility with every device.

What to check on any hub: which protocols it supports; whether it acts as a border router for the mesh protocol you plan to use; whether automations run locally or in the cloud; whether it works if the internet is down; and — the durability question — how long it will be supported, using the method in software support lifespan.

One structural caution: a hub is a single point of failure for everything attached to it, so its reliability and support horizon matter more than any individual device’s.

Local control versus cloud dependency

This is the most consequential distinction in the whole category and the least visible at the point of purchase.

Local control means commands and automations execute within your home. The system continues working when the internet is down, responses are faster, and less data leaves the house.

Cloud dependency means a command travels to a manufacturer’s servers and back — including, absurdly, a command from a phone in the same room as the device. It works well while the service works, and stops entirely when the service does not.

Most systems are a mixture, so ask specifically: does the device function locally, or only via the cloud? Do automations run on a hub or on a server? Does the app work on the local network without internet access? Is there a physical control that works regardless?

The last question is underrated. A smart light with a normal switch, a smart lock with a key, a thermostat with buttons — physical fallbacks turn a service outage into an inconvenience rather than an emergency.

Voice assistants and partial support

Voice compatibility is the most advertised and least complete layer.

“Works with” an assistant typically means core functions are exposed — on and off, brightness, temperature — while advanced features stay in the manufacturer’s own app. So a device can be genuinely voice-compatible and still require its own app for the capability you bought it for.

Three checks. Which specific functions are available by voice, rather than whether the badge is present. Whether voice commands are processed locally or in the cloud, since that determines behaviour during an outage. And whether the integration is maintained, because voice integrations are periodically deprecated by both sides.

Treat the assistant as a convenience layer rather than the foundation of a system. Building automations exclusively inside an assistant makes them hard to move if you change platforms — the switching cost described in total cost of ownership.

What happens when a service is discontinued

Manufacturers discontinue products, retire apps, and occasionally exit categories. This is normal commercial behaviour rather than a remote risk, and the consequences vary enormously.

When a cloud service closes, check which local controls still work and whether the device can join another supported controller. Hardware functionality and consumer remedies are separate questions: retain the seller’s description and support commitment if an advertised function disappears.

Four questions to ask before buying, and to record: does it work without the manufacturer’s service; does it support an open standard another system could adopt; can data be exported; and is there a published support commitment with an end date?

Where a device fails all four, treat it as a subscription with an unknown termination date rather than a purchase, and price it accordingly.

Building a system you can add to later

Systems grow. The decision that matters is not the first device but the first architecture.

Three approaches, honestly compared. Single-manufacturer ecosystems are simplest to set up, give the most complete feature support, and carry the highest switching cost. Open-standard systems take more work initially and let you replace one manufacturer without replacing everything. Mixed systems are where most people end up, and they work best with a deliberate hub in the middle rather than four apps in parallel.

Whichever you choose, three habits keep options open: prefer devices supporting a common application-layer standard even where you use the manufacturer’s app today; keep automations in a layer you control rather than inside one manufacturer’s cloud; and start with a small number of devices in one category, confirm the workflow suits you, and expand from there — the shortlisting discipline applied to systems.

A pre-purchase compatibility checklist

1. What protocol does it use, and do I already have what it needs?
2. Which application-layer standard does it support, and which functions are exposed through it rather than only in the app?
3. Does it need a hub, and does my hub support this device type?
4. Does it work locally if the internet is down, and do automations run locally?
5. Is there a physical fallback — a switch, a key, a button?
6. What is the published support end date for security updates?
7. What happens if the manufacturer withdraws the service, and can another system adopt the device?
8. What are the ongoing costs — subscriptions, cloud storage, features behind a plan?
9. Can I export my data and transfer the device to a new owner?

Answer these for the first device and you have effectively designed the system. The build-quality questions in how to judge product quality online still apply — a smart device is also a physical object — but in this category the compatibility answers determine lifespan more than the hardware does, which is the broader argument in how to choose future-proof tech.

How should you build the system?

Our verdict

Compatibility must be verified function by function. Pick the control architecture first, document the required hubs and keep essential household functions operable without the cloud.