Troubleshooting

Organised by symptom, not by brand — because "the sensor keeps dropping off" has the same few causes whatever badge is on it. Each entry names the likely cause first, then the fix in order of how likely it is to work. Moving to a different hub? Skip to help with migrations.

Mesh & connectivity

A Zigbee or Z-Wave device keeps dropping off the network

Affects: Zigbee · Z-Wave · Thread

Most likely cause: the device is at the edge of the mesh with no repeater between it and the hub. Battery devices don't relay traffic, so a house full of sensors and no mains-powered devices has no mesh to speak of.
  1. Add a mains-powered device of the same protocol (a plug or bulb) roughly midway between the hub and the problem device. This fixes it far more often than moving the hub.
  2. Check the device isn't sitting on or near metal — a boiler, a fuse box, a metal door frame, foil-backed insulation.
  3. On Z-Wave, run a network heal or rebuild so routes are recalculated after adding the repeater.
  4. Replace the battery even if it reads healthy. Voltage sag under transmit load causes dropouts long before the percentage looks low.
  5. If it only drops in hot or cold weather, suspect the battery chemistry — alkaline cells lose capacity sharply below freezing, so use lithium for outdoor sensors.

Zigbee devices became unreliable after I upgraded my Wi-Fi router

Affects: Zigbee · Thread

Most likely cause: channel overlap. Zigbee, Thread, and Wi-Fi all share 2.4 GHz, and the new router has probably picked a channel that sits on top of your Zigbee channel.
  1. Set your Wi-Fi to a fixed 2.4 GHz channel of 1, 6, or 11 rather than "auto".
  2. Set your Zigbee coordinator to a channel that avoids it — 15, 20, or 25 are the usual safe choices.
  3. Move the hub at least a metre away from the router. They interfere with each other at close range.
  4. Note that changing the Zigbee channel can require re-pairing some devices, so change Wi-Fi first.

A device won't pair, or pairing fails repeatedly

Affects: all protocols

Most likely cause: the device is still paired to a previous hub. Zigbee and Z-Wave devices must be removed from the old network before joining a new one.
  1. Run an explicit exclusion (Z-Wave) or reset/leave (Zigbee) from the old hub if you still have it.
  2. If the old hub is gone, most hubs offer a "force remove" or "exclude unknown device" mode that resets the device without it.
  3. Factory-reset the device using its documented button sequence — this differs per device and guessing rarely works.
  4. Pair within a couple of metres of the hub, then move the device to its final position afterwards.
  5. For Matter, check the QR code hasn't already been consumed by another ecosystem; you need a fresh sharing code for multi-admin.

A Z-Wave device I imported from abroad won't join at all

Affects: Z-Wave

Most likely cause: frequency mismatch. Z-Wave is region-locked — roughly 868 MHz in the EU, 915 MHz in North America. The radios physically cannot hear each other.
  1. Check the device's region marking against your hub's. There is no software fix.
  2. Return or resell it and buy the correct regional variant. This is the one smart home mistake that can't be worked around.
  3. Note the same applies to hubs — a US hub won't run EU Z-Wave devices either.

Battery & power

Sensor batteries only last a few weeks instead of a year

Affects: Zigbee · Z-Wave · Thread · Wi-Fi sensors

Most likely cause: either it's a Wi-Fi sensor (which will always drain fast), or a mesh sensor is retrying transmissions because it can't reach the hub reliably.
  1. Confirm the protocol. A Wi-Fi battery sensor lasting weeks is behaving normally — replace it with Zigbee, Z-Wave, or Thread if battery life matters.
  2. For mesh devices, poor signal means repeated retries, and retries are what drain cells. Fix the mesh (see above) and battery life usually recovers.
  3. Check the reporting interval. A temperature sensor set to report every 10 seconds will die quickly; every 5–10 minutes is plenty for most automations.
  4. Avoid rechargeable NiMH cells in devices expecting 1.5 V alkaline — the 1.2 V nominal voltage causes false low-battery warnings and early cut-off.

Everything stops working during a power cut, even though my hub is "local"

Affects: all hubs

Most likely cause: local control protects you from internet outages, not power outages. If the hub and router have no power, nothing runs.
  1. Put the hub and router on a small UPS. Both draw very little, so even a modest unit gives hours.
  2. Check your devices' power-restore behaviour — some smart plugs default to "off" after a cut, which can silently leave a fridge or freezer unpowered.
  3. Keep manual overrides available. Any lighting setup that can't be operated from a wall switch will fail badly here.

Automation behaviour

Lights turn off while I'm still in the room

Affects: all hubs

Most likely cause: a PIR motion sensor can't see a motionless person, so the "no motion for X minutes" timer expires while you sit still.
  1. Trigger the off-action on the sensor being continuously clear for X minutes, rather than on a fixed delay after the last motion. Any new motion then resets the countdown automatically.
  2. Increase the timeout for rooms where people sit still — offices and living rooms want far longer than hallways.
  3. For a real fix, add an mmWave presence sensor, which detects stationary occupancy.
  4. Check the sensor's own hardware cooldown ("blind time") — many PIRs won't re-report motion for 30–180 seconds regardless of what your automation asks.

An automation fights my manual switch — I turn a light off and it comes back on

Affects: all hubs

Most likely cause: the automation has no concept of manual intent, so it treats your deliberate switch-off as just another state to correct.
  1. Add a short-lived override flag: when a manual change is detected, set a boolean that suppresses the automation for 20–60 minutes.
  2. Where your hub exposes it, check the event's origin (physical vs. automation) and skip the action if a human did it.
  3. Consider whether the automation should exist at all in that room. Fighting the household is a losing strategy.

A fan, heater, or ventilation system rapidly switches on and off

Affects: all hubs

Most likely cause: no hysteresis. With a single threshold, the reading hovers around it and the device cycles.
  1. Use two thresholds with a gap — on above 1200 ppm, off below 900 ppm, rather than both at 1000.
  2. Add a minimum run time so the device stays on for at least a few minutes once triggered.
  3. Smooth the input where possible by averaging the sensor reading over several minutes.

Automations fire at the wrong time of day through the year

Affects: all hubs

Most likely cause: the automation uses a fixed clock time where it should use solar position. Sunset moves by hours across the seasons.
  1. Trigger on sunset/sunrise with an offset rather than a fixed time.
  2. For "evening" behaviour, combine solar position with a lux reading so overcast days behave sensibly too.
  3. Check your hub's location and timezone are actually set correctly — a wrong location silently breaks every solar trigger.

Matter, Thread & ecosystems

My Thread devices are slow or keep disconnecting

Affects: Thread · Matter

Most likely cause: too few border routers, or several that aren't cooperating because they belong to different ecosystems.
  1. Confirm you have at least one border router, and ideally two or three spread through the house.
  2. Be aware that border routers from different vendors don't always form one shared Thread network — Apple, Google, and Amazon devices may each create separate meshes.
  3. Prefer border routers on Ethernet where possible, so the backhaul isn't competing on Wi-Fi.
  4. Add mains-powered Thread devices, which act as routers within the mesh in the same way Zigbee routers do.

A Matter device won't share to a second ecosystem

Affects: Matter

Most likely cause: you're reusing the original setup code instead of generating a new sharing code, or the device has hit its fabric limit.
  1. In the app that currently owns the device, generate a fresh pairing/sharing code — don't re-scan the sticker.
  2. Check the device's fabric limit. Many support 3–5; once full, you must remove one ecosystem before adding another.
  3. Enter the new code promptly, as sharing codes usually expire within minutes.

I put a cloud camera on my local hub and it still won't work offline

Affects: all hubs

Most likely cause: a local hub doesn't make a cloud device local. Each integration keeps its own architecture — the hub sets the floor of your privacy and reliability posture, not the ceiling for every attached device.
  1. Check whether the camera exposes RTSP or ONVIF. If it does, connect via that instead of the vendor integration.
  2. If it doesn't, no hub can make it work offline. Replace it with a PoE or ONVIF-capable model if offline operation matters.
  3. See our camera comparison for what to look for.

Help with migrations

Switching hubs is mostly tedious rather than difficult — the work is unpairing and re-pairing devices one at a time. These guides cover what transfers, what doesn't, and the order to do it in. Most migration trouble is really pairing trouble, so the symptom guides above cover the rest.

SmartThings → Homey

The most common move, usually prompted by wanting local automation. Zigbee and Z-Wave devices must be excluded from SmartThings first; Matter devices can run in both systems simultaneously via multi-admin while you transition, which makes this far less disruptive than it used to be.

Effort: moderate · allow an evening for 20-30 devices

Wink → any modern hub

Wink's subscription pivot and service instability stranded a lot of hardware. The good news is most of it was Zigbee or Z-Wave and is still perfectly usable — it just needs a factory reset and re-pairing to a new hub. Homey Pro covers both protocols plus the 433 MHz gear Wink users often accumulated.

Effort: moderate · expect to factory-reset every device

Vera / Ezlo → Homey or Hubitat

Long-running Vera installations tend to be Z-Wave-heavy with a lot of custom scenes. The devices transfer fine after exclusion; the scenes have to be rebuilt. Worth auditing which automations you actually still use before recreating all of them.

Effort: high if you have many custom scenes

Hubitat → Homey

Usually a usability rather than capability move — people who want the same local processing with a better app and household-friendly interface. Zigbee and Z-Wave devices need re-pairing; rule logic must be rebuilt in Flow, which is generally quicker than writing it was.

Effort: moderate · protocols overlap well

Home Assistant → Homey

Less common, and worth being honest about: you will lose some integrations Home Assistant has and Homey doesn't. The trade is a far simpler system to maintain and one your household can actually use. Check your critical integrations against Homey's app store before committing.

Effort: varies · audit integrations first

Cloud ecosystem → local hub

Moving off Alexa or Google Home as your automation engine while keeping them for voice. This is the easiest migration of all, because you're adding a layer rather than replacing one — the hub takes over the logic and the assistants keep working as voice front-ends.

Effort: low · nothing needs unpairing

Universal rule: always exclude or factory-reset a device from its old hub before trying to pair it to the new one. A device that still thinks it belongs to another network is the single most common cause of pairing failures, and it is the first thing to check when a migrated device refuses to join.

Frequently asked questions

What should I check first when any smart device misbehaves?

In order: battery (replace, don't trust the percentage), signal path (is there a mains-powered repeater between it and the hub?), and pairing state (is it still joined to an old hub?). Those three account for the large majority of faults across every protocol.

Is it better to move the hub or add a repeater?

Almost always add a repeater. Moving the hub fixes one dead zone and often creates another, whereas a mains-powered device mid-path strengthens the mesh permanently. Put the hub somewhere central and wired, then extend outward with plugs and bulbs.

How do I tell whether a problem is the device, the hub, or the network?

Move the device next to the hub and retest. If it works there, it's a signal or mesh problem. If it still fails, it's the device or its pairing. If several unrelated devices fail simultaneously, suspect the hub, the network, or a firmware update rather than the devices.