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 connects devices directly to your router with no hub. Convenient, higher power draw, and each device adds to the load on your network — which matters for battery-powered sensors and for large numbers of devices.

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

You need a hub whenever you use a low-power mesh protocol, because those devices cannot reach your router unaided. You may also want one even where devices could connect directly.

Three reasons to want a hub. It enables local control, so automations run in the house rather than via a distant server. It provides a single point of integration across protocols, which is what turns a collection of devices into a system. And it reduces load on your Wi-Fi and often improves reliability for battery devices.

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.

Devices with local control and open standards support generally keep working, losing remote access and manufacturer features while remaining usable through another controller. Devices that are entirely cloud-dependent can lose most or all functionality, and there is usually no remedy — the hardware is fine and the service it needs no longer exists.

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.

Frequently asked questions

Do I need a hub?

It depends on the protocol. Wi-Fi devices connect directly to your router; low-power mesh protocols need a hub or border router. A hub also enables local control and automations that survive an internet outage.

Does a common standard guarantee devices work together?

It guarantees basic interoperability for supported device types, not feature parity. Advanced features often stay in the manufacturer's app, so check which specific capabilities the standard exposes.

What happens if a manufacturer shuts down its service?

It depends on whether the device needs that service. Locally controlled devices usually keep working with reduced remote features; entirely cloud-dependent devices can lose most functionality.

Should I stay within one ecosystem?

A single ecosystem is simpler and more complete, at the cost of higher switching costs later. Open standards take more setup and leave you able to replace one manufacturer without replacing everything.

How we write this guide

This article is research-led. It describes the published architecture of consumer smart home systems: the distinction between radio protocols and application-layer standards, the role of hubs and border routers for low-power mesh networks, the difference between local and cloud execution, and the partial nature of voice assistant integrations.

We have installed and tested no devices, and this guide names no brands, products, hubs or assistants, and publishes no rankings: we hold no verified comparison data for any smart home category. Protocol and standard support changes with firmware and platform updates, so confirm current support from each manufacturer's own specifications for the specific model before buying.

Recommended Today may earn commission from links to retailers. Commission does not influence our editorial content or the order of any recommendation. Tech & Audio guides are reviewed every 6 months. Next scheduled review: February 2027.