Replies: 2 comments
-
|
Great discussion, sucks that no one is jumping on to help. im in the same boat i have 130 devices on UZG-01 |
Beta Was this translation helpful? Give feedback.
-
|
I have had the same Problem. For me the only fix was first to seperate in 2 Networks. Now i have already 5 Networks :D For the Aqara devices i have found out that the old Firmware was buggy. So i installed also a new firmware with the Aqara Gateway manually. I use now version 1.0.3 on the Switches (07 and 08) and have only the problem that my reporting is not configuratable and binding does not work :D |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
I’m looking for advice on tuning a large Zigbee network with many Aqara WP-P01D plugs. My goal is to keep on/off reporting instant, but dramatically reduce chatter (especially power telemetry) and improve overall network stability.
🖧 Network Context
Coordinator: SMLIGHT SLZB-MR1 (CC2652P7 chip, ZStack3x0 firmware (20240710), Zigbee2MQTT 2.6.1)
Channels: Zigbeee: 15, Thread: 20, Wifi 2.4Ghz: 11
Transmit power: 20 dBm (as per SMLIGHT docs)
Devices: 116 total
Routers: 106
End devices: 9
Heavy on Aqara: 41× WP-P01D, 20× WS-K08E, 11× WS-K07E
LQI distribution: Majority 90–140, some >200 but many in the 70–90 range after TX power increase
General feel: network is bursty and sometimes congested — automations occasionally lag, and previously I had devices dropping offline (improved somewhat after ISO8601
last_seen)📉 What I’ve Already Tried
Binding cleanup:
EP1 + EP2 → only
genOnOffbound to coordinatorEP21 (
genAnalogInput) unboundReporting tuning:
EP21 reporting disabled (
max=65535) → power-cycled all devicesTried “loose but enabled” profile (min=60 s, max=7200 s, Δ=15 W) → traffic maybe decreased, but still present
Network hygiene:
Staggered bind/report writes with delays
ISO8601
last_seenformat → noticeably fewer availability pingsIncreased TX power to 20 dBm for better mesh balance (but LQI seemed to drop, if that makes any sense)
Despite these, power updates still come in every few seconds from some plugs — looks like unsolicited lifeline reports that ignore my “disable reporting” config.
📊 Binding & Reporting Snapshot (Redacted)
Here is the current configuration from my fleet (only showing clusters we care about).
This should make it easy for others to compare their setup:
(Across fleet: EP1+EP2 mostly bound, EP21 mostly unbound, EP21 reporting disabled.)
🔎 Current Observations
Some outlets still publish
powerat 8–12 s intervals even with EP21 reporting removed.These reports dominate traffic (20–40 msgs per 5 min window per plug).
On/off state reporting is instant and reliable.
LQI dropped slightly after limiting TX power to 20 dBm — unsure if this improved or worsened retries / congestion.
❓ Questions for the Community
Are Aqara WP-P01D outlets known to ignore “reporting disable” and keep sending lifeline
presentValuereports?Is there a better way to fully silence or at least slow them down at the firmware/ZCL level?
Would it be better to re-enable reporting but use large deltas (e.g. Δ=15–20 W) so the device respects cadence?
Should I consider lowering TX power back to get better LQI?
Is filtering
power/current/voltageattributes at the Z2M layer (so they don’t hit MQTT/HA) a sensible last resort, even though it doesn’t reduce on-air traffic?Are there recommended binding/reporting “best practices” for large Aqara-heavy networks to minimize broadcast storms?
I’d love input from others running large Aqara networks or using SMLIGHT coordinators on what’s worked for you to tame traffic without losing real-time responsiveness.
Network report:
Beta Was this translation helpful? Give feedback.
All reactions