Looking for advice in refreshing / recalibrating my setup

[HANR]

I’ve been running Home Assistant on a Raspberry Pi 4 in my home, spread over three floors and have been fairly reliable for over three years now. I’ve recently backed up the system, installed the HAOS dedicated image and restored my backup and all seems to still work.

However, I’m still finding that automations are getting missed, which when it’s a thermostatic radiator valve (TRV) command, is becoming more and more frustrating; I don’t want radiators left on all day. It’s not limited to the TRVs, sometimes the lights won’t switch on/off (both group or single) when the switch is pressed or there’s a latency that can be a few seconds, or sometimes (albeit rarely) the proximity sensor doesn’t turn a light on (whether it’s the signal from the sensor to the controller or the controller to the lights I don’t know) and so it goes on.

I reportedly have 114 devices in the system using one controller, although currently there are 99 online; batteries are flat in some devices and being endpoints they’re not routers. A repeater was added about a week ago with the hope of relieving the load on some of the devices, though this hasn’t happened as I expected; with the number of mains devices I have the also behave as router I think this is probably redundant. The controller is on the ground floor and is more-or-less central in my home, while the repeater is on the first floor; again, more-or-less central.

I’m running ZHA throughout with mainly Tuya devices.

My configuration is as follows:

Home Assistant (updated today, 2025-12-13)
Core 2025.12.3
Supervisor 2025.12.3
OS 16.3

Areas: 20
Bulbs: 57 as 54x TS505B and 3x ZB-CL01; 20x lighting groups
TRVs: 8x TS0601 (so far)
Magnetic Switch Sensors: 4x TS0203 (so far)
Proximity Sensors: 6x TS0202 (so far)
Switches (4 button): 13x TS0044
Mains Switches: 2 (so far) as 1x SONOFF S26R2ZB and 1x SONOFF 01MINIZB
Temperature / Humidity Sensors: 3x TS0201 (so far)
Repeaters: 1x TS0207
Controllers: 1x ZBDongle-P reporting as TI CC2652

Recent Error: (Running on 2025.12.2)
Perform action ‘Climate: Set target temperature’ on Front Single Bedroom Thermostat
Executed: 13 December 2025 at 06:54:39
Error: Failed to send request: Failed to send request: <Status.APS_NO_ACK: 183>
Suggests that the device failed to respond.

alias: Cal AM FSB Rad On
description: Calendar schedule - Morning, Front Single Bedroom, Radiator On
triggers:
  - at: "05:30:00"
    trigger: time
conditions: []
actions:
  - data:
      temperature: "{{ states('input_number.fsbtemp')|int }}"
    target:
      entity_id: climate.front_single_bedroom_thermostat
    action: climate.set_temperature
mode: single

Automations are mainly configured to use entities but there are some with device or possibly even area use cases too, which I’m correcting as and when I spot them. I don’t use scenes as I found these too unreliable.

While I’ve mainly configured the devices in their respective placements, some devices were not. I’m therefore wondering if there’s a one stop way to recalibrate and refresh the whole network in one go for the signal paths to be more efficient and robust, allowing the signals to be more consistent?

[ShadowFist]

@HANR

I’m therefore wondering if there’s a one stop way to recalibrate and refresh the whole network in one go for the signal paths to be more efficient and robust, allowing the signals to be more consistent?

First things first. Make sure you read this and that you’re ruling out interference.

Next, the best way to start is to fire up your ZHA map and see what routes your devices are currently taking. If you see some routes which don’t make sense (like a router on the first floor directly connected to the coordinator instead of a nearby router), then you might want to remove that router and pair it to the other router yourself.
It won’t guarantee that the router will maintain that route, but at least you’ll know that if it starts routing via the coordinator again, the device is correctly selecting what it feels is the best route.

Second thing you need to watch out for is how many devices are connected to your coordinator directly. The Dongle-P page has some inconsistencies regarding how many direct connections it can handle.
The main product page says it’s 21 direct connections & 40-100 children via firmware update:

Meanwhile the FAQ section at the bottom says 50 direct connections & up to 200 children:

Either way, check if there’s a firmware update available for your coordinator, maybe that helps improve things.

Lastly, you don’t mention whether the groups you have set up are HA groups or Zigbee groups in ZHA. HA groups will fire multiple zigbee commands, one for each device, while a ZHA group will only fire a single zigbee command.
Switching to zigbee groups (if you haven’t done so already) will reduce the traffic on your network.

If all else fails, you have 2 options:

• Have your automations repeat the command multiple times using a delay and a repeat.
• Nuke your entire zigbee network and build out your mesh from scratch, starting from the ones closest to the coordinator and adding further away devices as you go along.

[HANR]

Firstly thanks for the speedy reply, it gave me quite a bit to investigate and is much appreciated!

I had looked the visualisation of my setup and I saw a lot of things that didn’t make sense, such as the TRV that’s about 1.5 - 2m away from the controller reporting LQI of 118, which is also routed via a light at the far end of an adjacent room!

My WiFi is currently running on channel 10 (it was channel 1 the other day), which is around channel 21 in Zigbee terms, while my Zigbee network is running on channel 15. Looking at the allocation slots, 15 is far enough from 10 so as to minimise interference according to this.

These are my current readings so I’m not too worried about the current channel configuration. Could it be better - yes, but potentially at the cost of other problems.
“energy_scan”: {
“11”: 60.0,
“12”: 27.058823529411764,
“13”: 0.0,
“14”: 0.0,
“15”: 30.58823529411765,
“16”: 14.117647058823529,
“17”: 16.470588235294116,
“18”: 37.64705882352941,
“19”: 22.352941176470587,
“20”: 41.1764705882353,
“21”: 60.0,
“22”: 58.8235294117647,
“23”: 32.94117647058823,
“24”: 7.0588235294117645,
“25”: 1.1764705882352942,
“26”: 32.94117647058823
},

Firmware:
It turns out that I’m using the stock firmware - Zigbee 20210708…yikes!!! I’ll look at updating this to the latest Zigbee 20250321, which apparently brings the following:
General Improvements Across Versions

• Improved Stability & Bug Fixes: The older 20210708 firmware had a known issue with adding devices when “joining is only permitted on specific router” was enabled in Home Assistant’s ZHA integration, which caused some devices to not join via a router. Subsequent updates between these dates included numerous stability improvements to address such issues.
• Enhanced Network Performance: Newer versions often include optimizations for larger networks, such as improved Link Quality Indication (LQI) and increased message delivery success rates, especially for devices with specific polling intervals.
• Updated SDK Base: The 20250321 version is built on a much newer Texas Instruments SimpleLink SDK (e.g., 8.30.01.01 in related builds), compared to the older SDK used in 2021. This incorporates all underlying platform improvements from TI.
• Increased Network Capacity: Configuration changes and optimizations allow newer firmware to support more devices. While the official firmware typically supports up to 40 children, the underlying stack has been optimized to handle larger tables and potentially more concurrent connections.
• Better Device Compatibility: Each new community firmware release incorporates general bug fixes and improved compatibility with a wider range of third-party Zigbee devices as they are released onto the market.

Looking at the flashing the firmware, it reports that it will clear out all data in the controller. To this end, I’ll update the firmware in the morning when we’re not so reliant on lights and such, which will give me more time to address any problems that may arise.

As far as I’m aware, I’ve created Zigbee groups: Settings, Devices, Coordinator, Zigbee Home Automation, Configure, Groups. I have one room with 11 lights and they all switch on/off at once - usually. I also have a night time shut-off that switches off every light in the house that aren’t in bedrooms. I tried using scenes when I first started using HA and it was a nightmare. I’m fairly confident that I’ve configure the groups correctly.

Regarding the duplication of commands separated with delays, I’ve already done this to an extent for some time now. While it may make the system a little more robust, it’s hard to see whether or not it’s actually making a difference. I appreciate it is what it is but it’s a hack to a problem that I had hoped to overcome with other methods short of having to reconfigure the entire system; it’s a lot more difficult to maintain too. On this note, I’ll see what the latest firmware update brings and report back to how I get on with that. I was actually considering migrating to the SLZB-MR3 or MR4, which should hopefully give me more breathing room for the number of devices as well as adding support for matter/thread to help future proof.

Otherwise for the short-term, I can see that once I update the firmware that I’ll probably benefit a lot by repairing a number of devices that have erroneous routes.

One question to end with, while I will apparently lose all the data that’s in the controller after flashing the new firmware, will I benefit by migrating the radio and making a backup?

Thanks again for your help!

[ShadowFist]

@HANR

One question to end with, while I will apparently lose all the data that’s in the controller after flashing the new firmware, will I benefit by migrating the radio and making a backup?

Not sure where migrating the radio comes into play when updating the firmware. You’re simply upgrading the firmware on your coordinator, not switching to a new one.

All you need is a backup (just in case) and to make sure that ZHA is stopped before attempting a firmware update (you can’t have 2 different softwares attempting to communicate with the same hardware). Once the firmware upgrade is done, then simply switch ZHA back on.

I’m not even sure that you’ll actually need to re-pair all your devices after the update - I certainly don’t recall having to do so, but that was a couple of years ago on Z2M. At most, you can use the ZHA backup to restore your old config if things go wrong.

PS - next time you want someone to be notified you replied to their post, use the grey reply button at the bottom of their post instead of the blue one at the bottom of the thread. I only stumbled on your reply by accident

[HANR]

Thanks for the reply.

I updated the coordinator and it was thankfully uneventful. I had performed a backup just in case. I had meant doing the backup with the button next to the radio migration.

So far, all the devices appear to be in good working order. I’m in the process of trying to reorientate devices with low LQI and irrational routes; it’s proving tough having migrated from an earlier version of the visualiser that had the RSSI/LQI on each device.

Thanks for the tips…soldiering on!