[ST Edge] Aqara FP300 (Zigbee)

Devices & Integrations Community Created Drivers
68

Fixed version:

───────────────────────────────────────────────────
 Driver Id    22ab5410-84cd-46c3-8c76-1e675850e5a7 
 Name         Aqara FP300 Presence Sensor          
 Package Key  aqara-fp300-presence-sensor          
 Version      2026-06-01T23:11:42.60575408         
───────────────────────────────────────────────────

ScreenRecording20260602010735SmartThings-ezgif.com-video-to-webp-converter

This Reddit comment was extremely helpful!

Hi everyone! Just wanted to chime in to say that I faced this exact same issue on what turned out to be a very frustrating afternoon: purchased an FP300, switched to latest zigbee firmware from aqara app, then paired to Z2M network. I noticed the exact same symptoms as OP with occupancy states not auto-reporting and “sticking” until refresh pressed manually (and even that worked only for 5-10 mins after pairing, afterwards that would stop working too). Initially I thought I had a defective unit, did all the usual troubleshooting, but to avail. After digging a bit deeper in the docs and in the Z2M logs, I think I found the root cause.

The clue was that the FP300 was not autonomously reporting the proprietary Lumi presence/PIR attributes, but since manual reads worked (and temp and humidity were actually working as expected), it looked like reports were not configured properly by Z2M for this particular firmware version when setting up the device upon joining.

My workaround is a custom Zigbee2MQTT external converter which binds manuSpecificLumi and manually configures reporting for 0x0142 / 322 (presence) and 0x014d / 333 (PIR detection) which are the two “stuck” readings.

After restarting Z2M and re-pairing/reconfiguring the FP300, it started sending real attributeReport messages and presence has been stable and flawless for the last couple of days.

So for everyone having this issue, my suggestion is to skip all the usual troubleshooting steps (device placement, firmware re-flash, etc), and to check the Z2M logs for attributeReport, cluster manuSpecificLumi, and data containing 322 or 333 to confirm the issue.

@TOMillr