I had a report where a Drayton Wiser heating setup started dropping its TRVs after Quinetic smart switches were added. The pattern points to 2.4GHz interference. Zigbee runs on 2.4GHz, many Quinetic devices also talk on 2.4GHz, and a busy Wi‑Fi network will make that band noisy. The steps below are a practical troubleshooting path I use on site. Follow them in order and record results.
What you see
Typical symptoms are intermittent device dropouts and repeated re-pair attempts in the hub logs. Expect logs like these from Zigbee software or a coordinator:
- 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
Network-level signs include the TRVs remaining reachable only when the Quinetic devices are powered down or moved. On the router, client devices may report lower link speeds on 2.4GHz or repeated deauths.
Run these diagnostic commands and note actual output versus what you expect.
- Wi‑Fi scan (Linux): sudo iwlist wlan0 scan
- Expected: list of SSIDs with channel numbers and signal dBm.
- Actual problem indicator: many strong networks on channels 1, 6 or 11 and very strong local SSID on same channel as Zigbee interference suspected device.
- Network manager (Linux): nmcli device wifi list
- Expected: 2.4GHz entries at 2412–2484 MHz. Note channel column.
- Zigbee coordinator logs (Docker example): docker logs zigbee2mqtt –tail 200
- Expected: steady heartbeats and occasional LQI reports.
- Problem indicator: repeating “no response” or “timeout” lines correlated to times Quinetic gear is active.
Record exact errors and timestamps. I use them to correlate cause and effect. Without timestamps this is guesswork.
Where it happens
Intermittent failures are usually localised. The Wiser Hub will drop devices closer to Quinetic receivers or near an ISP router. Check these locations first: hub cabinet, kitchen lighting cluster, meter area or where the Quinetic receivers live.
Device proximity issues to watch for:
- 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.
Environmental factors that worsen 2.4GHz interference include large metal surfaces, transformers and unshielded power supplies. Thick walls and floors change signal paths and force devices to single-hop links. That makes the Zigbee mesh fragile. Note where devices share walls with neighbours or where the router is placed in a cupboard. I physically move devices during tests to isolate the problematic zone.
Find the cause
Start isolating with an elimination test. Power off the Quinetic gear, but leave everything else running. Watch the Zigbee log for improvement. If the TRVs stabilise, the Quinetic gear is either occupying the same airtime or creating harmonics.
Identify 2.4GHz sources by scanning:
- Run sudo iwlist wlan0 scan while Quinetic gear is active and while it is powered down. Compare RSSI and channel occupancy.
- Temporarily set client Wi‑Fi to 5GHz-only and recheck Zigbee behaviour.
- Use a basic RF sniffer app on a phone (an app that reads Wi‑Fi environments) to spot overlapping channels and strong local sources.
Check for overlapping channels. Zigbee channels map across the 2.4GHz band and overlap with Wi‑Fi channels. Non‑overlapping Wi‑Fi channels are 1, 6 and 11. If your 2.4GHz SSID sits on channel 6 and your Zigbee traffic is heavy around the same spectrum slice, expect collision and packet loss.
Example correlation test and expected vs actual:
- Action: Move Wi‑Fi to channel 1 and switch laptops to 5GHz.
- Expected: Zigbee retries fall to near zero; LQI improves by 10–20 points.
- Actual problem: If retries remain, suspect hardware placement or a bad repeater chain.
Root causes I find in these cases are radio contention and a weak Zigbee mesh with single points of failure. Both must be fixed.
Fix
Device placement is the cheapest and most effective first step. I follow these rules.
- Put the Wiser Hub centrally in the house, not in a cupboard. Raise it off the floor and away from metal.
- Keep Quinetic receivers at least 1m from the coordinator during tests. Avoid stacking 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.
Hardware settings to update.
- Move client Wi‑Fi devices to 5GHz where possible. Set the main Wi‑Fi to 5GHz-only for phones and laptops, keep a simple 2.4GHz SSID for IoT.
- Lock the 2.4GHz SSID to a single channel (1, 6 or 11) after scanning which is least busy. Avoid auto or mixed channel settings.
- If the ISP router is old, put it into modem/bridge mode or replace it. Older routers have poor RF filtering.
Add Zigbee repeaters. Mains-powered devices make the mesh strong.
- Fit powered devices like smart plugs on each floor. They act as reliable hops.
- Aim for devices so the hub is never more than two hops from any TRV.
- Re-join or re-route heavy devices (like Quinetic receivers) to a nearby powered repeater rather than directly to the hub.
If you run Zigbee2MQTT or similar, increase logging to monitor LQI and link count as you make changes. Watch for the log line changes described earlier moving from “no response” to “device ready”.
Check it’s fixed
Use monitored tests and a realistic load. I run these verifications.
- Continuous log watch: docker logs zigbee2mqtt -f for 24–48 hours.
- Expected: no repeated “no response” errors, occasional single retries only during power cycles.
- LQI and RSSI checks from your coordinator frontend. Expect LQI improvements of 10–30 points on nodes that were dropping.
- Test with multiple devices: toggle the Quinetic switch multiple times while monitoring the TRVs. TRVs should not drop or show timeout messages.
Practical test schedule.
- Stage 1: Baseline – record errors for 24 hours before changes.
- Stage 2: Make one change only (move hub, change Wi‑Fi channel, or power down Quinetic) and observe 24 hours.
- Stage 3: Add repeaters and observe 48 hours.
Collect user feedback after each stage. Ask the homeowner to report exact times a device misbehaves and cross-check those timestamps in the logs. If errors stop after a specific change, that is your remediation and the root cause is confirmed.
Root cause and remediation summary: in my experience the drops come from 2.4GHz airtime contention combined with a weak Zigbee mesh. Fix placement, segregate Wi‑Fi to 5GHz, lock the 2.4GHz channel, and add mains-powered Zigbee repeaters. Those steps restore network stability and reduce home automation dropouts.
