Firmware problem with Aqara - Presence Multi-Sensor FP300

Devices
21

Hey Ken,

  1. I am still on 5841. I am reading in the Aqara community that 6542 seems to have resolved this issue so I need to get it installed. Was a great device when it worked properly.
  2. I did try reinstalling the firmware a few times with no difference.
  3. My problem started when I updated the firmware to 5841 which I did not do intentionally. I switched to Matter to play around and of course when I went back to Zigbee the process installed the latest firmware.
  4. I use Zigbee. I am not that impressed with Matter or Thread at this time.

I will install the update later today and see what happens.

22

Coming back to this thread with a significant update. I just finished migrating to my Homey Pro 2026 and was about to reinstall my 4 FP300s when I came across new information that actually diagnoses what’s been going on - and the fix appears to land on the Homey Aqara app side.

@TedTolboom - tagging you because this is squarely in your court and I’d value your read.

Quick recap of where I left this thread: 4 FP300s on Homey Pro 2023, paired via your Aqara app in Zigbee mode, ran flawlessly for 4 months, then in late May all units started exhibiting stuck-state behavior (presence and PIR motion latching on for minutes to many hours). I’ve already reflashed all 4 to Zigbee firmware 0.0.0_6542 via Bluetooth, factory reset, re-paired, re-ran AI Spatial Learning, rebuilt the Zigbee mesh, confirmed no environmental correlation, and verified the bug persists across Homey firmware 13.2.0 and 13.2.1. Worked an email thread with Aqara support that ultimately went nowhere - they confirmed they can only investigate via an Aqara hub, which I don’t own.

The new finding (June 8 2026):

A developer named andreas_roedl, who maintains the SmartThings Edge driver for the FP300, posted a technical breakdown on the Aqara forum (thread 299625, post #10). His diagnosis: firmware 6542 is actually more standards-compliant than 5841 was, but it no longer reliably emits autonomous Zigbee attribute reports for the FP300’s manufacturer-specific presence and PIR motion attributes unless reporting is explicitly configured by the integration.

Manual reads still work. Refresh still works. Temperature, humidity, lux still work. But presence/motion gets stuck because the integration is waiting for autonomous reports that never come after the firmware change.

The fix he applied to his SmartThings driver, which made his FP300 “extremely reliable, no issues anymore”:

  • Bind manuSpecificLumi (cluster 0xFCC0) to the coordinator
  • Manufacturer code: 0x115F
  • Configure reporting for:
    • Attribute 0x0142 (presence)
    • Attribute 0x014D (PIR motion)
  • Type: Uint8 (0x20)
  • Min interval: 0, Max interval: 300, Reportable change: 1

The same fix is in progress for Zigbee2MQTT as PR #12383 (open, not yet merged). ZHA needs a quirk update too. Cross-platform users (Home Assistant + ZHA, Hubitat, and SmartThings before andreas_roedl’s fix) are all reporting the same stuck-state behavior, which aligns with the diagnosis.

References:

Two questions, @TedTolboom:

  1. Is the Homey Aqara app currently binding manuSpecificLumi and configuring reporting for 0x0142 and 0x014D, or is that something that would need to be added?

  2. If it’s the latter, do you have a rough timeline? I’m trying to decide whether to delay reinstalling the FP300s on my 2026 hub or push ahead and live with the bug temporarily.

Happy to provide logs, device IDs, or whatever else would help. Thank you for the work you’ve put into the Aqara app - it’s been solid for me until this firmware change blindsided everyone.

23

Quick follow-up with a new symptom that I think strengthens the case for the explicit reporting fix.

I’ve now reinstalled my FP300s on the 2026 hub. Three observations from the first few days:

1. One unit (kids’ bathroom) has been stable since pairing - no stuck states, no dropouts. Working as it should.

2. One unit has had occasional motion-channel hangs, which I’ve worked around by switching to mmWave-only.

3. Two units (master bath and lavatory) repeatedly fall into a “connected but unresponsive” state every ~24 hours. The device still shows as connected in Homey, but no attribute updates come through - no motion, no presence, no temperature changes. The only thing that restores them is tapping “Try to Repair” in device settings. That immediately brings them back, and they then work normally until the next ~24-hour cycle when it happens again.

The “Try to Repair” pattern is what I think is interesting. Since that function re-runs the device interview and re-applies the driver’s setup logic, the fact that it instantly restores reporting - and that the failure recurs on a roughly 24-hour interval - is consistent with @TedTolboom andreas_roedl’s diagnosis: whatever reporting setup happens at interview time temporarily holds, then silently degrades. The explicit manuSpecificLumi binding and reporting configuration (cluster 0xFCC0, attributes 0x0142 and 0x014D) would address this directly.

This also explains why my fleet behavior is inconsistent on the same hub, same firmware, same driver - the units that happen to land in a working reporting state after pairing stay good, while others end up in a state that quietly fails over time. Same root cause, different surface symptoms.

Let me know if device IDs, logs, or anything else would help.

24

Long shot, but does it make a difference when you swap the “master bath” and “kids’ bathroom” sensors?

(I was thinking of possible interference of some kind)

25

Thanks Peter - that’s a fair test and worth doing. My instinct is the cause is driver-side reporting given the “connected but unresponsive” and “Try to Repair fixes it” pattern, but ruling out an environmental factor would strengthen that conclusion either way.

I’ll swap the kids’ bathroom and master bath units physically without re-pairing (so the test isn’t confounded by a fresh interview) and report back after a couple of days. Good suggestion.

26

YW, Ken.

Adding a few routers (mains powered zigbee devices) around the flaky sensors can’t hurt.

Zigbee 3.0 is a standard, but some (particular devices of) brands just don’t mix @ Homey, like, Ikea lights and Aqara sensors.
When an Aqara sensor starts to use an Ikea light as router, it stops sending updates AND it never looks for an alternative router again.
The interview, or re-adding the device solves it, until it, again, starts to use such Ikea light.
Unfortunately there’s no setting to “blacklist” certain routers for certain sensors, neither does it blacklist incompatible routers itself.

Checking & adjusting the 2.4GHz wifi & zigbee channel might help as well
https://community.homey.app/t/advanced-zigbee-troubleshooting-on-homey/115930.

The “24h limit” is also challenging me; Maybe there’s a nearby device running in daily cycles, causing temporary interference. Think of Bluetooth devices, microwave ovens

27

Lots of new information from your suggestions, @Peter_Kawa - thanks.

On the IKEA routing question, this is the big one. Checked Developer Tools and found:

  • All four FP300s are currently routing through IKEA TRETAKT smart plugs.
  • The kids’ bathroom unit (the only one working flawlessly so far) was originally direct-connected to the hub but has now shifted onto an IKEA TRETAKT route. Still behaving so far, but may simply not have hit the failure window yet.
  • The two units that drop out every ~24 hours (master bath and lavatory) are both on IKEA TRETAKT routes.
  • I have one IKEA bulb but it’s on the opposite side of the house and isn’t in any of the FP300 routes.

This fits your described pattern almost too well: sensor pairs through an IKEA router, works for a while, silently stops sending updates, never tries to find an alternative. “Try to Repair” forces a re-interview, which restores it briefly.

My plan:

  1. I have two SONOFF S31 Lite ZB plugs available. I’ll place one near each of the bad FP300s and re-pair those two units with the IKEA TRETAKTs temporarily powered off so they’re forced to pick the SONOFFs.
  2. Order more SONOFF Gen 3 plugs to give the other two FP300s the same treatment and build out a non-IKEA backbone for the Aqara sensors going forward.
  3. Keep watching the kids’ bathroom unit - if it eventually starts failing after its move to the IKEA route, that confirms the pattern.

On the Wi-Fi/Zigbee channel question:

Zigbee is on channel 25 and my main Deco mesh sits in the 2.4 GHz channel 1-4 range on auto-channel, so that’s clear of the usual overlap. One correction worth making though - I have a separate small TP-Link nano AP serving only my water softener, and it’s pinned to Wi-Fi channel 11 (20 MHz, 11bgn mixed). That’s a less-ideal neighbor for Zigbee 25 due to side-lobe energy, but the AP is low-power, mostly idle (one device, water softener check-ins only), and physically separated from the FP300 locations. So probably not a major contributor, but worth flagging for completeness.

On the 24-hour cycle timing:

A couple of the dropouts seemed to happen around 7 PM. Nothing specific is firing on my hub at exactly that time, so could be coincidence or could be environmental. I’ll pay closer attention now that I’m watching for it. The only Bluetooth in the area is from 7 SwitchBot Blind Tilts, but they’re idle until their scheduled open/close (7 AM and around sunset ~8 PM), so they shouldn’t be transmitting during a 7 PM dropout.

Will report back after the SONOFF re-route work and a few days of observation. Thanks again - this thread is helping me think through a lot.

28

Hi Ken,

Thank you.
Regarding Ikea Tretakt plugs, I didn’t encounter issues with an Ikea TRADFRI plug + Aqara sensors @ Homey zigbee. But, the Tretakt is a #1 candidate to run some tests and checks for sure.

Athom tried to get Ikea + Aqara around the table to address this mismatch over a year ago, but I’m afraid it’s just never gonna happen:

29

I follow this thread with great interest. I have more or less the same issue that you describe using zigbee with FP300 (six of them). No Aqara Hub involved, they are directly connected to Homey. They work fine for about 24h before they stop reporting on all indicators/sensors (motion, presence, lux, hum etc.). As you, I have a wide range of Zigbee routers in my network. But I do not have one single Ikea bulb, just a few plugs and some signal repeaters (those that follow with Ikea Fyrtur). Also several Elko and one Aqara router. My zigbee network is overall stable when it comes to all other devices than the FP300.

Due to the 24h cycle dropout on zigbee, I have moved all six Fp300 over to Matter directly connected in Homey. There they report consistently way beyond 24h. However with Matter I experience plenty of false positives (i.e. the fp300 randomly refuses to turn off presence alarm hours after people have left the room, affects all six to some extent). No fans or obvious things involved. A bit like choosing between being thrown to the lions or tigers at the moment. Maybe a slight difference in end result, but anyway fatal at the end of the day (rather literally so for zigbee) :\

30

Update on my end, plus a direct question for @TedTolboom.

@Trond_Nordfjaern - thanks for that data point. Your experience essentially rules out IKEA routing as the root cause on its own, since you’re seeing the same 24-hour dropout without any significant IKEA infrastructure in the path. Consistent with what I’m now seeing too.

Where I am 6 days in:

  • Removed all IKEA TRETAKT plugs, replaced with ThirdReality Gen 3 as mains-powered routers
  • Reinstalled all 4 FP300s with clean routes through the new plugs
  • Days 1-3: all 4 units clean, no dropouts, no stuck states
  • Day 4: motion channel stuck on 2 of 4 units, resolved by “Try to Repair” (which re-runs the interview and re-applies reporting)
  • Days 5-6: clean again on all units since the repair

So the routing fix helped substantially (went from every-24-hour dropouts to one incident in 6 days on two units), but the underlying bug is still present. The pattern matches andreas_roedl’s diagnosis exactly: whatever reporting config gets set up at interview time eventually degrades, and re-running the interview temporarily restores it.

@TedTolboom - direct question: is the explicit manuSpecificLumi binding and reporting configuration fix (cluster 0xFCC0, attributes 0x0142 and 0x014D, per andreas_roedl’s June 8 diagnosis on the Aqara forum) on your roadmap for the Homey Aqara app? If it’s something you’re able to work on, do you have a rough timeline? If it’s not something you can address, is there someone else in the Homey app development chain who should?

Happy to provide device IDs, logs, or anything else that would help. This is affecting multiple users on multiple platforms and the SmartThings and Z2M fixes are both public references for the same change.

31

If you still want to use TRETAKT plugs in Homey: they also pair to a Hue bridge, so you can add them to Hue and then integrate the Hue bridge in Homey, so you can still control them. I have a TRETAKT in my Hue system for some powered light and it works great (also way cheaper than the Hue smart plug), also works in Homey

32

Two updates.

First, situation on my end is getting worse. Since my last post, 2 of my FP300s escalated from motion-only stuck states to complete no-detection (no motion, no presence). “Try to Repair” still resolves it, but they drop again within ~24 hours. So the pattern is not just holding — it’s degrading.

Second, and more importantly for @TedTolboom :the Z2M fix (PR #12383) referenced in my earlier post has been merged and released. The fix binds manuSpecificLumi and configures reporting for attributes 0x0142 (presence) and 0x014D (PIR motion) — exactly what andreas_roedl diagnosed. A Z2M user pre-tested it with 3 FP300s and confirmed it worked; production release followed.

So the state of the fix across platforms:

- SmartThings Edge driver: fixed (andreas_roedl)

- Zigbee2MQTT: released via PR #12383 (drauziooppenheimer)

- ZHA: needs quirk update, status unclear

- Homey Aqara app: no update yet

The Homey app is now the outlier among the platforms actively maintaining Aqara integrations. Ted, any chance you could look at porting the same fix? The reference implementations are public and the diagnosis is well-documented.

Happy to test a beta version if that helps.

33

I’m also having problems with my newly bought FP300 sensors in Homey. I installed them using zigbee, and after some time (possibly 24h as mentioned before) they stop working. Yesterday they suddenly started working again, and dropped out again after some time.

I’m a bit confused about where the problem is now, is it simply the homey app for Aqara that has a bug? Or the firmware on the devices? or …?

I want to know if i can be hopefull in getting a fix (soon), or if i should start investigating different devices.

It would be a shame because i really like the functionality and when they work they seem to work very well.

34
35

I suspect that is the reason why they started working magically yesterday, but today they are not working again. Ive done a repair so they are working again, i will let you know if it stays that way.

36

I had exactly the same issues described in this thread. It worked perfectly for about two months, then something changed and the sensor started getting stuck in the “motion detected” state, detecting presence when nobody was there, not turning off presence when someone left the room and sometimes becoming completely unresponsive. Using the “repair” option would fix it only temporarily.

Eventually I had enough and switched to the Matter connection, hoping it would solve the issue. It did. I have had zero problems since.

Matter exposes only “presence” (which I assume combines the microwave and PIR sensors into a single presence entity), along with temperature, humidity, and lux. It does not provide distance settings, AI learning, detection sensitivity, choosing preferred detection method (mwave vs. PIR or both) or other advanced options. For my use case, I only need presence and lux to control lights on/off/dimming and blinds so I am perfectly happy and won’t be going back to Zigbee connection.

37

I can report that my sensors keep working for almost 3 days in a row now. However, the temperature, humidity and luminance is not reporting as configured. I have it set up on the default values of 3600s, but two of my sensors have 22h ago since their last report, and the third has 2 days ago. So it seems either something is still wrong there, or i have misconfigured it in some way.

38

Hi . I have the homey Pro 2026 model and I installed the fp300 sensor. I have had nothing but problems with it, exactly what previous people have reported. I tried switching to Matter and it was worse than on Zigbee. I have swapped back to Zigbee but still not working. Motion and Presence alarms not updating but luminance is updating, at least most of the time. When is this going to get fixed.

39

I can confirm that I have the 1.16.3 version of the app and it is still not working for me. Please fix the issue. I have just bought the Homey Pro 2026 model and a fp300 sensor and so far not to impressed.

40

Maybe it’s a distance issue? My FP300 is in the same room as my Google Streamer 4K, which acts as a Thread border router and helps the FP300 communicate with Homey (which is on the other side of the house). Small battery powered sensors are highly dependent on the strength of their respective mesh networks. I also have a bunch of Zigbee smart plugs (mains powered) distributed throughout the house, used solely as Zigbee mesh repeaters to improve network coverage for my Zigbee devices.