Sensors keep going offline: the six causes, in the order you should check them

Why do my sensors keep going offline?

Nearly always because the mesh has too few mains-powered devices in it, not because the sensor is faulty. Battery sensors cannot relay for each other, so every one of them needs a permanently powered device within radio range to hang off. Add a plug or a powered bulb between the hub and the far sensor and most dropouts stop.

The five-minute triage, in order

Work down this list rather than starting with the sensor that annoys you most. Each step rules out a cause of the ones below it, which is why the order matters more than any individual check.

1. Is it one sensor or several? One sensor is a battery, a magnet gap or a dead unit. Several, especially several at the same end of the house, is the network — and no amount of re-pairing that one sensor will touch it.
2. Is the hub itself online? A coordinator that has lost wifi takes every child device down with it, and most apps report that as a list of offline sensors rather than as one offline hub.
3. How many mains-powered devices sit between the hub and the sensor? If the answer is none, you have found it. This is cause 1 below and it is the most common by a wide margin.
4. Fresh cell, correct chemistry, in the sensor that drops. Two minutes, and it eliminates the fault that imitates every other fault on this page.
5. Where is the coordinator physically? On a USB 3 port, behind a metal case, or on top of the router are three separate ways to cripple a mesh from the center outward.
6. Only then change a radio setting. Channel changes are the last resort, not the first move, because on Zigbee they can cost you a re-pair of the whole network.

A battery sensor is asleep most of the time, and that changes the diagnosis

The single most useful thing to understand about a contact sensor is that it is not listening. The Home Assistant ZHA documentation puts it plainly: battery-powered products are “so-called ‘sleepy devices,’ so they normally are asleep and only receive commands when the state of the device is changed.” The radio wakes, sends, and goes back to sleep. That is how a cell the size of a shirt button lasts a year or more.

Thread names the same idea formally. The OpenThread primer divides nodes into those that forward packets for other devices and keep the transceiver enabled at all times, and end devices that do not forward and “can disable [their] transceiver to reduce power.” A Sleepy End Device is one whose radio is “normally disabled, wakes on occasion to poll for messages from its parent.” And critically: “The relationship between a Mesh Extender and an End Device is a Parent-Child relationship.”

Two consequences follow, and they explain most of the confusion in this category. First, a sensor that reports state changes correctly but shows “offline” in an app may simply have missed a check-in with its parent, not lost the network. Second, when its parent goes away — the plug you unplugged, the bulb on a switch you turned off at the wall — the child has to find a new one, and on a sparse network there may not be one to find. The radio in the sensor is not the weak link. The absence of a parent is.

Cause 1: the network has endpoints but no routers

This is the big one. The ZHA documentation states that “Zigbee networks depend heavily on having multiple Zigbee Router devices to expand coverage and increase device capacity,” that router devices are mains-powered and “help pass messages to other nearby devices in the Zigbee network and therefore can improve range and increase the number of devices you can add,” and — the figure worth writing down — that the coordinator can directly connect up to 32 end devices.

That number is where a lot of houses quietly hit a wall. It is not a bug and it is not vendor-specific: the design deliberately pushes you toward a mesh rather than a star. The same documentation notes that in theory a coordinator with three router devices could support 77 devices in total, while adding that “in practice, you will likely need to add a lot more Zigbee router devices than in this example to extend the coverage.”

The practical fix costs less than a sensor. Add permanently powered devices — a smart plug, a mains-powered smart bulb, a wired wall switch — on the same protocol as your sensors, and put them between the hub and the part of the house that drops out rather than next to the hub. Then give the network a day: re-parenting is not instant, and a sensor that only wakes on a state change may not notice a better parent exists until the next time the door opens.

Cause 2: the coordinator is in the worst place in the house

A mesh degrades from the center outward, and the center is usually the least considered object in the installation. The ZHA documentation is specific about three things, all of which are free to fix.

Do not use a USB 3 port.The instruction is to “make sure to only connect the Zigbee USB adapter to a USB 2.0 port (and not to a USB 3.x port),” and where only USB 3 ports exist, to connect the coordinator through a powered USB 2.0 hub. USB 3 controllers radiate broadband noise in the 2.4GHz band, and a stick plugged directly into one can lose most of its usable range.

Do not sit it on the router.The same page says to place the coordinator “away from any Wi-Fi access points and all other sources of Wi-Fi,” and “away from electrical wires/cables, power supplies, and household appliances.” The most common installation — coordinator stick in the back of a server that lives in the cabinet with the router — manages to violate both at once.

Get it out of the metal. A coordinator inside a steel rack, a media cabinet with a mesh door, or a basement utility box is transmitting into a shield. A short USB 2.0 extension that moves the stick a foot into open air is the highest-value change in this whole guide per dollar spent.

Cause 3: wifi and your sensors are sharing the band

Zigbee and Thread both run in the crowded 2.4GHz band, alongside wifi, Bluetooth and a microwave oven. When they overlap, the low-power mesh is the one that loses — a sensor transmitting at 13dBm or less is not going to win a contest with an access point.

The order of operations here is counterintuitive and worth following. The ZHA guidance is to “not change the Zigbee channel from the ZHA default,” and that “if you have issues with overlapping frequencies between Wi-Fi and Zigbee, then it is usually better to first only try changing and setting a static Wi-Fi channel on your Wi-Fi router.” Where a Zigbee channel does get picked automatically, the Smart option “scans all of the channels and then picks the best one, preferring 15, 20, 25 over all other channels.”

The reason to move wifi rather than the mesh is entirely practical: your router will change channel in seconds with no consequences, and changing the Zigbee channel on an established network can require re-pairing devices one at a time, on ladders, with the manual. Fix the loud radio, not the quiet one.

Cause 4: the cell is fine at rest and not fine under load

This is why a multimeter reading of “3 volts, looks fine” is misleading. A coin cell has real internal resistance, and it rises as the cell ages. The sensor draws almost nothing while asleep and then a short, sharp pulse when the radio transmits, and it is during that pulse that a tired cell's voltage collapses below the radio's cutoff. The symptom is not a dead sensor. It is a sensor that works when you test it at the door and drops off overnight, or reports the first event of the day and nothing after.

Three details matter more than they should:

• Match the chemistry on the cell, not the size. A CR1632 and a CR2032 are both 3V lithium coin cells and are not interchangeable; a rechargeable lithium coin cell at 3.6V or a 1.5V alkaline button cell in the same physical size will either damage the device or never work properly.
• Replace all cells in a multi-cell sensor at once, from the same pack. An uneven pair sags under load and behaves exactly like a flat one.
• Buy dated stock and check it. Lithium coin cells self-discharge slowly but they are not immune, and a bargain multipack that has sat in a warehouse is a plausible explanation for a brand-new cell that lasts weeks.

The arithmetic for how long a cell should have lasted in the first place — cycles per day, not hours of use — is set out in the battery section of our door and window sensor roundup, which also names the sensors whose makers publish a battery figure at all.

Cause 5: the sensor is past its published temperature range

Every manufacturer that publishes a specification sheet publishes an operating temperature range, and almost nobody reads it before mounting a sensor in an unheated garage, on a storm door, or inside a shed. Below the lower limit a lithium cell's internal resistance climbs and the pulse problem in cause 4 arrives early; the device has not failed, it is simply outside where the maker says it works.

Read those numbers against where the sensor actually is. A garage in a cold climate spends weeks below 14 °F; a south-facing conservatory window or a metal storm door in direct sun spends afternoons above 113 °F. Both are outside the published range of sensors that are perfectly reliable indoors, and neither is a defect. The other half of that specification — humidity with no condensation — rules out an unconditioned crawl space or a bathroom window more often than people expect.

Cause 6: it is the hub, not the sensor

When a whole group disappears at once, stop looking at sensors. A coordinator reboots after a firmware update and comes back on a different wifi channel; a hub on DHCP gets a new address and the app cannot find it; a Thread border router you did not know you were relying on — an Apple TV, a HomePod, a Nest hub, certain Echo models — gets unplugged or moved to another room. The sensors are all fine; the thing they were children of has gone.

Two habits prevent most of this. Give the hub a fixed address on your router rather than letting DHCP move it, and know which box in your house is acting as a border router or coordinator before you tidy a cable. If you are not sure which box that is, or whether you should own a dedicated one at all, smart home hubs for security separates the four jobs a hub does, and Matter and Thread, explained covers the border router requirement that Thread sensors depend on and their packaging rarely states clearly.

What “offline” even means, and why two apps disagree

There is no standard definition. One platform marks a device offline when it misses a scheduled check-in, another when a poll goes unanswered, another only when an automation fails. That is why the same sensor can read offline in a vendor app and perfectly healthy in Home Assistant at the same moment, and why “it went offline for an hour” is not always a fault at all.

The test that settles it is behavioral rather than cosmetic: open the door and watch whether the state changes. If it does, the sensor and its parent are talking and you are looking at a reporting artifact. If it does not, work the list above. And if a sensor is genuinely dropping in a way that breaks an automation you rely on, the protocol you chose is part of the answer — which is the whole of Z-Wave vs Zigbee vs Matter.