u/Typical-Ad-6024

Hey all

Having major issues with Zigbee network, tried ZHA and Z2M. I'm using:

~75 Zigbee2MQTT devices (61 Aqara, 13 Nous), coordinator is an SMLIGHT SLZB-MR5U over Ethernet (`ember` adapter), HA OS.

My previous coordinator (an SLZB-MR6U) had the same instability — crash-looping, `TABLE_FULL` binding errors, chunks of the mesh going unresponsive. I assumed hardware fault and replaced it. Set the new one up **completely fresh** — no backup restore, every device re-paired from scratch. **Same failure class came back anyway.** Two different physical coordinators, same symptoms — that rules out "just bad hardware" for me.

Radio disconnects/restarts with varying reasons (`RESET_SOFTWARE`, `RESET_POWERON`, `ECONNRESET`). Specific devices repeatedly fail to bind with `Status 'TABLE_FULL'`. Occasional sweeps where nearly every router fails a routing-table query at once. Command delivery intermittently fails for a shifting set of devices.

### What I've tried

Cleared a stale `coordinator_backup.json` (helped once, not permanently); moved off a noisy Zigbee channel after an RF scan (reduced routing failures, didn't stop crashes); power-cycled the coordinator (no lasting help); reflashed firmware dev→stable (no help); power-cycled individual problem devices (fixed their presence reporting, binding issue unclear). Partial wins across the board, nothing's been a full fix.

Every device with a confirmed problem today (11 of them) is Aqara — zero of my 13 Nous devices affected. Worst offenders are three Aqara Presence Sensor FP300 mmWave sensors specifically, which have a reputation for being binding-hungry. Doesn't fully explain it though — the routing-table failures hit some non-Aqara routers too.

I'm weighing up 3 options:

-Move Aqara devices to my Aqara M3 Hub**, keep the SLZB for everything else. Free, but splits the network and I'm unsure how solid the M3 Hub's HA integration is (local vs. cloud).

- Replace Aqara devices with IKEA** (Zigbee/Matter-Thread). Cheap (~£250 all-in), but real time, and a big Thread network is unfamiliar territory.

-Replace Aqara devices with other Zigbee brands.** Similar cost, avoids a second protocol, but keeps one large single-coordinator network — which may not fix anything if this is coordinator/RF-related rather than Aqara-specific.

- Has Aqara flakiness followed anyone across two different coordinators like this? What actually fixed it?

- Anyone running an Aqara M3 Hub with HA who can speak to how local/reliable that integration is?

- Anyone beaten FP300-caused `TABLE_FULL` without replacing the sensor?

Cheers in advance

Hey all, really struggling with getting audio to work on iOS (Safari) with my Frigate setup. Currently using: Frigate 0.17, Aqara G5 Pro camera, Advanced Camera Card in Home Assistant and CoreML detector (Apple Silicon).

My Frigate config (excerpt):

go2rtc:

streams:

aqara_g5_pro:

- rtsp://702:666@192.168.1.96:8554/ch1#backchannel=0

- "ffmpeg:aqara_g5_pro#audio=aac#async"

aqara_g5_pro_sub:

- rtsp://702:666@192.168.1.96:8554/ch2

- "ffmpeg:aqara_g5_pro_sub#audio=aac#async"

I've tried:

- Originally had both AAC and Opus (`#audio=aac#audio=opus`), removed Opus since iOS doesn't support it

- Using `preset-record-generic-audio-aac` for recording output args

- Checked the go2rtc stream directly at `http://<ip>:1984/stream.html?src=aqara_g5_pro` — still no audio on iOS

- Audio detection is enabled in Frigate and working server-side

1. Does the Aqara G5 Pro even output AAC natively over RTSP, or is go2rtc having to transcode it?

2. Is there anything specific needed in go2rtc or Advanced Camera Card config to make WebRTC audio work on iOS Safari?

3. Anyone got audio working on iOS with a similar setup?

Any help appreciated — been going in circles on this one!

Thanks!