Improve Zigbee stability by moving noisy kit away

I had a report where a Drayton Wiser heating setup started dropping TRVs after Quinetic smart switches were added. The pattern points to 2.4GHz interference. Zigbee runs on 2.4GHz, many Quinetic devices also use 2.4GHz, and a busy Wi‑Fi network can make that band noisy. The steps below are the same ones I use when I have to sort it on site. I keep notes and timestamps from the start.

What you see

The usual signs are intermittent device dropouts and repeated re-pair attempts in the hub logs. The logs tend to look like this:

• zigbee2mqtt: 2025-03-01 14:22:11 ERROR Device 'TRV_01' no response, retry 1
• zigbee2mqtt: 2025-03-01 14:22:22 WARN Received last will from 'Quinetic_Kit' - unexpected disconnect

At network level, the TRVs may stay up only when the Quinetic devices are powered down or moved. On the router, client devices may show lower link speeds on 2.4GHz or repeated deauths.

Run these checks and compare the output with what you expect.

• Wi‑Fi scan on Linux:

sudo iwlist wlan0 scan

• Expected: a list of SSIDs with channel numbers and signal dBm.
• Problem sign: lots of strong networks on channels 1, 6 or 11, plus a strong local SSID on the same channel as the device you suspect.
• Network manager on Linux:

nmcli device wifi list

• Expected: 2.4GHz entries at 2412–2484 MHz. Check the channel column.
• Zigbee coordinator logs, using Docker:

docker logs zigbee2mqtt --tail 200

• Expected: steady heartbeats and the odd LQI report.
• Problem sign: repeated no response or timeout lines that line up with Quinetic activity.

Record exact errors and timestamps. Without those, it is guesswork.

Where it happens

The failures are usually localised. I see the Wiser Hub drop devices that are closer to Quinetic receivers or sitting near an ISP router. Check the hub cabinet, kitchen lighting cluster, meter area, and anywhere the Quinetic receivers live.

Watch for these proximity issues:

• Quinetic receiver less than 0.5m from the Wiser Hub.
• Quinetic receiver mounted inside a metal back box directly behind the TRV.
• Old ISP router sitting on the same shelf as the hub.

Large metal surfaces, transformers and unshielded power supplies can make the problem worse. Thick walls and floors change the path the signal takes, and that can leave devices on single-hop links. The mesh gets brittle. I move kit around during tests so I can see which area is actually causing the grief.

Find the cause

Start with an elimination test. Power off the Quinetic gear, leave everything else running, and watch the Zigbee log. If the TRVs settle down, the Quinetic gear is either eating airtime or throwing off enough noise to matter.

Check the 2.4GHz sources by scanning:

• Run sudo iwlist wlan0 scan while the Quinetic gear is active and again while it is powered down. Compare RSSI and channel occupancy.
• Set client Wi‑Fi to 5GHz only for a test and see whether Zigbee behaves better.
• Use a basic RF sniffer app on a phone to spot overlapping channels and strong local sources.

Wi‑Fi and Zigbee share the same band. Wi‑Fi channels 1, 6 and 11 do not overlap with each other, but they still sit in the same 2.4GHz space as Zigbee. If the 2.4GHz SSID is on channel 6 and Zigbee traffic is heavy in the same slice of spectrum, packet loss becomes more likely.

One simple test:

• Move Wi‑Fi to channel 1 and switch laptops to 5GHz.
• If retries drop and LQI improves, the channel placement was part of the problem.
• If retries stay high, look harder at placement or a bad repeater chain.

In practice I usually find a mix of radio contention and a weak Zigbee mesh. Both need attention.

Fix

Placement is the cheapest place to start.

• Put the Wiser Hub centrally in the house, not in a cupboard. Raise it off the floor and keep it away from metal.
• Keep Quinetic receivers at least 1m from the coordinator during tests. Do not stack them on or behind the hub.
• Avoid mounting receivers in metal back boxes. Use an external mounting plate or move the module line side out of the metal enclosure.

Then sort the Wi‑Fi side.

• Move client devices to 5GHz where you can.
• Keep a simple 2.4GHz SSID for IoT.
• Lock the 2.4GHz SSID to one channel, usually 1, 6 or 11, after checking which is least busy.
• If the ISP router is old, put it into modem or bridge mode, or replace it.

Add Zigbee repeaters. Mains-powered devices make the mesh more forgiving.

• Fit powered devices such as smart plugs on each floor.
• Try to keep the hub within two hops of any TRV.
• Move heavy devices like Quinetic receivers onto a nearby powered repeater instead of leaving them directly on the hub.

If you run Zigbee2MQTT or something similar, raise logging while you make changes. Watch the LQI and link count, and look for the log lines changing from no response to device ready.

Check it is fixed

Use monitored tests and a normal load. I check the following.

• Watch the logs continuously with docker logs zigbee2mqtt -f for 24–48 hours.
• Expected: no repeated no response errors, with only the odd retry during power cycles.
• Check LQI and RSSI in the coordinator frontend. Nodes that were dropping should improve by about 10–30 points.
• Toggle the Quinetic switch several times while watching the TRVs. They should stay up and not throw timeout messages.

A simple test schedule works best:

• Stage 1: record errors for 24 hours before any changes.
• Stage 2: make one change only, such as moving the hub, changing the Wi‑Fi channel, or powering down Quinetic gear, then watch for 24 hours.
• Stage 3: add repeaters and watch for another 48 hours.

Ask the homeowner for exact times when a device misbehaves, then line those up with the logs. If the errors stop after one change, you have your fix and your likely cause.

From what I have seen, the drops usually come from 2.4GHz airtime contention plus a weak Zigbee mesh. Move the kit, keep Wi‑Fi off 2.4GHz where you can, lock the channel, and add mains-powered repeaters.