MatterODM by Shenan YangguangThe short answer, and the two words that decide it
Every Matter device needs a Matter controller to be commissioned and controlled, and many customers already own one inside a smart speaker, display or router from a major ecosystem, while a Matter over Thread sensor in addition needs a Thread border router on the local network and a Matter over Wi-Fi sensor needs the controller but not a separate border router. The single word that changes the answer is the radio: "Thread" or "Wi-Fi". We decide that radio at the design stage when we integrate a standard CSA-certified Matter connectivity module, and the brand's whole go-to-market story for "do I need a hub?" flows from that one choice. Both radios are legitimate Matter transports; they just carry a different infrastructure expectation for the end customer.
Controller vs border router: the distinction everyone mixes up
A Matter controller is the app or device that commissions devices onto a fabric and issues commands to them, whereas a Thread border router is the device that connects a Thread wireless mesh to the local IP network and the internet, and a single product such as a smart speaker or a Wi-Fi router can perform both roles at once, which is why the two are so often confused. You can think of the controller as the "brain that knows your devices" and the border router as the "bridge that lets Thread devices talk to the rest of the network". A customer with an Apple TV, a Google Nest Hub, an Amazon Echo or a recent Wi-Fi router frequently has both already, which is the quiet reason so many Matter sensors "just work" in a modern home without the brand shipping any extra box.
Matter over Thread sensors: yes, they need a border router
A Matter over Thread sensor joins a Thread mesh and cannot reach a Wi-Fi or Ethernet network except through a Thread border router, so without one on the premises the sensor has no path to the controller and no path to the internet, and the system will not commission. This is the most common setup failure we see at support: a customer buys Thread sensors, has no border router, and the devices simply will not pair. The good news is that Thread is designed to be forgiving — any powered Thread device can extend the mesh, and a single border router typically covers a normal home — but the border router itself is not optional. For a brand selling Thread sensors into a first-time-smart-home buyer, we strongly advise either bundling a border router or printing the requirement on the box, because the alternative is a support ticket that reads "nothing connects".
Matter over Wi-Fi sensors: controller, but no border router
A Matter over Wi-Fi sensor connects directly to the customer's Wi-Fi network and needs a Matter controller to set it up and control it, but it does not need a separate Thread border router because it never uses the Thread mesh. For a battery sensor, Wi-Fi is the heavier radio on the power budget, which is why most small security sensors choose Thread; but for a mains-powered device or a gateway, Wi-Fi removes the border-router dependency and simplifies the customer's mental model to "connect to my Wi-Fi, done". The trade is purely on power and range economics, not on whether the device is "real Matter" — both are fully Matter, and both need the controller.
What the customer usually already owns
The customer who already uses a major smart-home ecosystem almost certainly already owns both a Matter controller and, in most recent hardware, a Thread border router, so a brand selling into that installed base can safely assume the infrastructure exists and focus the packaging on the sensors themselves. The customer buying their very first smart device is the exception that needs the box spelled out. We help brands write that on-boarding copy accurately rather than over-claiming "no hub required" in a way that is only true for the Wi-Fi variant — because an over-broad claim on a Thread product is a guaranteed return.
What this means for a brand selling sensors
Whether to bundle a hub is a target-customer decision: if the buyer likely already owns a Matter controller or Thread border router from an existing ecosystem, bundling one is redundant cost, but for a standalone security kit aimed at first-time buyers, including or clearly recommending a border router removes the single most common setup failure we see. There is also a product-line angle: a brand that sells a Matter gateway or hub as part of its range can offer Thread sensors that pair to its own border router, giving a clean out-of-box story, while a brand that sells only Wi-Fi sensors can legitimately say "no extra hub" on the Thread-free variants. The decision is strategic, not technical, and we scope both radio options on a standard CSA-certified Matter connectivity module so the brand can pick per SKU.
Local-first: why an outage is not a security failure
Matter is designed for local control, so once a sensor is commissioned, the local device behaviour — detection, alerting and automation on the home network — keeps working without the internet, and what an outage removes is normally the remote access and notifications that a cloud or app layer provides, not the local function. This matters enormously for security: a door contact that stops alerting because a server fell over is not a security device. With Matter the local path is the primary path, and the white-label app and cloud stack we can build for a brand is the convenience layer on top, never the thing the alarm depends on. We are explicit with brands about that split, because selling "cloud-dependent security" to a customer who then loses alerts during an outage is how trust dies.
Factory stance: we spec the radio and tell you the truth about the box
Shenan Yangguang designs, prototypes, validates and mass-produces these sensors; we do not relabel a third party's product. When a brand asks "do my sensors need a hub?", we answer with the radio we integrated and the customer we are targeting, not a slogan. We build on a standard CSA-certified Matter connectivity module, we validate the commissioning flow against real controllers, and we write the on-boarding requirement accurately per variant so the box never over-promises. Where we are unsure whether a given customer segment already owns the infrastructure, we say so and recommend the conservative packaging — because a sensor that fails to pair on day one is a returned product, not a feature.
For the radio decision behind this, see our Thread vs Wi-Fi guide for alarm sensors; for what happens at first setup, our onboarding and multi-admin note covers the factory's commissioning duties.