The marketing department clearly felt that calling them a room occupation sensor didn’t sounds as good, even if it was more accurate.
Presence on 99% of HA platforms, is used for total home presence via geofencing etc, not room presence.
1 Like
I understand, and disagree that things must stay stuck to the past. But I don’t want to derail this thread so I’ll stop at that. Thanks for the answer and the driver.
1 Like
I’m not sure how you arrived at this opinion, home presence detection is very much a current and highly useful tool.
Adding room “presence” into the mix, just muddies the waters.
2 Likes
And yet it is clearly the direction the technology is moving.
As you pointed out, it’s a marketing name given to a more advanced motion sensor.
At its core, it’s still just a motion sensor that has much higher resolution than a standard PIR sensor.
2 Likes
I received my FP300 yesterday and switched it over to Zigbee via the Aqara app. I then decided to try pairing it to my Aqara M3 hub to explore all of its capabilities. I must say, so far so good. Pretty small sensor, and has worked without fail thus far. I have a Home Assistant Yellow hub running as well, which is linked to the Aqara M3 hub via Matter. The new FP300 showed up immediately in HA as shown below.
I was pleased to see that all of the sensor values and battery level were brought in via the Aqara M3 Matter bridge. The hold time was nice to see as well. I did change the hold time in the Aqara app and the value was changed in HA as well. So far, so good.
I used the Home Assistant Device Bridge (HADB) integration to bring in the FP300’s “Occupancy” sensor into my HE C8 Pro hub as a “Motion” sensor. I added it to an existing Room Lighting automation that was currently failing due to the existing Aqara FP2 sensor being partially blocked by the Christmas tree. 
Since adding the FP300, this RL automation has once again worked flawlessly.
I am impressed and very pleased with this purchase. Once the Hubitat Zigbee drivers are worked out, I will probably pair it directly with my C8-Pro hub to see how well a direct integration works. For now, HADB is being used for my Aqara FP2 sensors and the new FP300 sensor. Performance is great, so no need to change anything today.
7 Likes
You make a purchase sound very enticing. I must resist the urge to buy, especially since the FP1Es have been working flawlessly and I haven’t yet invented a use case to require an FP300 
1 Like
I think the discussion on motion and presence is a red herring for most of us. If my heart is beating in the room for a mmWave detector 8' away there is motion.... If the IR pattern shifts for a PIR sensor 15' away there is motion. One detects one type of motion the other a different.
The difference matters to us as we interpret those reports. Hopefully the combined device reports those conditions in a way that we can trigger conditional action.
Right now, it seems like the driver needs help interpreting the inputs to fully realize the data from the device.
Could be mistaken,
Bill
Agreed, the sensors are relying on motion detection to know there is someone in a room. Doesn’t really matter what form that takes.
Calling them "presence sensors" is just marketing BS, just like the TV OEM’s calling LCD TVs, LED TV’s just because they changed the backlight technology from CFL to LED - they didnt magically stop being LCD TV's.
3 Likes
I'm guessing that the opportunity for a "battery powered" combined PIR and mmWave "presence" device may be that the mmWave is idle until triggered by a PIR signal. Makes sense to leave the mmWave idle until it sees a trigger. I don't have any sources on that, but just an educated guess.
Bill
3 Likes
Amazon has made that easy for you. The FP300 is sold out currently. 
3 Likes
Just added two FP300s to an Aqara M3 as Zigbee. Imported into HE via the HE Generic Matter Bridge. Sorry to share on the driver page, but some of the conversation here involved the overall performance of the FP300, so I thought I would share.
I placed one FP300 right next to an FP1E. My comparison observations after 1-2 hours of testing:
-- FP1E has batter range and angle coverage
-- FP1E has faster response times
-- FP1E detects and keeps presence at the boundary (configured range)
-- FP300 keeps presence at the boundary, but requires closer proximity to detect presence
Other observations about the FP300:
-- mmWave only and PIR/mmWave combo do not affect response times or behavior. I incorrectly thought that PIR/mmWave would detect faster than mmWave only. I confirmed that mmWave only does not hold detection longer than the combo mode (not really expecting a difference).
-- The "current location" on the detection range page appears/disappears intermittently, even while present in a sweet spot
-- The range selection zones are pretty cool, but unnecessary for my use cases ... so no testing
-- Temperature and humidity appear to be accurate in my two locations
-- Disabled illuminance, so no testing
And one ancillary comment about mmWave: The FP1E is more consistent, speedier (detect/absent), and robust (breathing detections) than any mmWave sensor that I have tried. I currently have 12 Linptech and about 10 others of various types. However, the FP300 behaves pretty well, so great for wireless locations. I'll buy more for sure.
7 Likes
Thank you for the comparison — this is very helpful information. For me, the biggest advantage of the FP300 is that it’s battery-powered, meaning it can be placed anywhere in the room without visible cables or power requirements… which is always a big win for WAF. 
It would also be very useful if someone could compare the FP300’s performance in Zigbee mode when it’s connected to an Aqara hub and brought into Hubitat via Matter or HADB, versus its performance when it’s paired directly to Hubitat as a Zigbee device.
Last night, the FP300 was successfully tested for mmWave presence detection with a sleeping person located approximately 2.5 meters (~8 feet) away. The presence state remained stable and continuous throughout the test, confirming reliable detection even with minimal movement.
The settings that I used in this driver were :
- Presence Detection Mode : "Both mmWave+PIR"
- PIR Detection Interval : 60 seconds (shouldn't matter IMO)
- Absence Delay Timer : 30 seconds (bigger values should be even better for detecting sleep)
- AI Adaptive Sensitivity : enabled
- AI Interference Identification : disabled
- Motion Sensitivity : low (here I have some doubts whether low/mid/high arent inverted?)
It’s very important to mount the mmWave sensor securely in a fixed position and avoid changing its location or beam angle after the initial installation. Any shift in alignment can affect the accuracy of its detection.
It’s also crucial to calibrate the FP300 after configuring all parameters and preferences. Make sure the room is empty, then click “Start Spatial Learning” so the sensor can accurately map the environment without any people present.
3 Likes
On another note — I’ve removed the word “Presence” from the thread title so we can stay focused on the primary objective: ensuring the FP300 works reliably when paired directly to Hubitat via Zigbee.
There are two major challenges with the FP300 driver at this stage:
- Handling the large number of configuration parameters :
The FP300 exposes a very extensive set of configuration options. I still need to add around 10 additional advanced settings related to illuminance, temperature, and humidity calibration.
The current limitation:
- When the Save button is clicked on the Preferences page, all settings are re-sent to the device.
- Other ecosystems (Aqara Home, Z2M/ZHA, SmartThings, Tuya, etc.) only send the updated parameter, not the whole set.
- Sending a flood of Zigbee commands — especially ones that may trigger internal recalibration — could cause unstable behavior. I’ve observed this exact problem with some Tuya mmWave sensors, and it’s very likely the same risk applies to Aqara.
The fix will require significant refactoring:
- Store the current values and data types for each parameter internally (in a state variable).
- Only transmit parameters that were actually changed by the user.
- Capability handling across multiple supported device types
This driver supports 13 different Aqara motion/illuminance/mmWave devices, and that will remain the case — I am not going to maintain 13 separate Aqara drivers.
Until FP300 support was added, none of the other 12 devices had true temperature or humidity sensors, so there was no need for standard TemperatureMeasurement or RelativeHumidityMeasurement capabilities.
Now that those capabilities are included, all devices appear in Hubitat apps as T/H sensors
…even though only FP300 actually provides T/H readings. This is obviously not ideal.
The solution could be :
- Create a child device specifically for FP300 temperature & humidity
- Remove T/H capabilities from the main/parent driver
- Use Hubitat’s Generic Component Temperature Humidity Sensor for that child device
Would be great if Hubitat allowed dynamic capabilities in drivers… but since that won’t happen, this is the cleanest path forward.
If anyone has alternative suggestions or improved approaches, I’d greatly appreciate your input!
4 Likes
Thank you for some of the background on the driver. I helped me place it more effectively in my space and get it into a situation that may work for me. PIR range seems to be as far as 25' in optimal situations, but 15' is more likely to be a good bet. mmWave Seems to be at the edge around 12'. I've had some conflicting responses that may or may not be operator error.
Bill
"Aqara P1 Motion Sensor" driver version 2.0.0 2025/11/15 11:58 PM (dev. branch) :
- BREAKING CHANGE: Added child device support for FP300 temperature & humidity; FP300 T/H readings now appear in a separate child device using Generic Component Temperature Humidity Sensor;
- BREAKING CHANGE: removed TemperatureMeasurement and relativeHumidityMeasurement capabilities from the parent driver;
- BREAKING CHANGE: added deviceTemperature attribute for non-FP300 devices internal temperature;
- added advancedOptions preference toggle;
- added separate tempOffset and humidityOffset for FP300;
- added experimental trackTargetDistance() command for FP300
- MAJOR CHANGE: Intelligent Parameter Change Detection :
- implemented for FP300 and illuminance reporting
- store parameters in the state.params [n:name, t:type, v:value, l:local]
- only sends changed values to prevent Zigbee flooding and potential device instability
- other minor improvements
Tested overnight on two hubs with a dozen Aqara motion and mmWave sensors of different models — everything appears to be working smoothly so far.
4 Likes
Before I continue adding the remaining advanced FP300 parameters, there is another important improvement needed in the driver: confirming whether configuration commands are actually received and accepted by the device.
Unlike the DC-powered Aqara mmWave sensors (FP1, FP1E, FP2), the FP300 is a battery-powered Zigbee sleepy device. To preserve battery life, its radio is off most of the time and only wakes when certain events occur — motion detected by PIR/mmWave, changes in temperature/humidity/illuminance, etc. As a result, when Hubitat sends Zigbee commands to a sleepy device, the device may or may not be listening at that moment. This is not unique to Aqara — many battery-powered sensors from different manufacturers behave the same way.
Most other Zigbee ecosystems (Aqara, Tuya, Sonoff…) account for this internally and use various mechanisms to ensure that settings and commands reach sleepy devices reliably. Hubitat does not provide a built-in solution for this — so the driver has to implement its own mechanism. I already use such a system in a few of my other drivers (for example the 'Tuya Temperature/Humidity/Illuminance LCD Display with Clock' driver ), but it has not yet been added here.
The plan is to introduce a status attribute that will report success or display a warning after preferences are saved or a command is issued. If the driver does not receive confirmation back from the device, the status will prompt the user to wake it up and try again. There is also the option to implement automatic retries: whenever the device sends an event and briefly wakes up its radio, the driver can immediately resend the pending configuration commands in the hope they will be accepted on the second attempt. This approach works well with Sonoff and Tuya sensors, and I am optimistic it will work with Aqara too.
For now, to ensure FP300 preferences and commands are successfully applied, please follow the guidance provided in the driver’s Preferences tab:
8 Likes
I have noticed the same requirement in the Aqara App with my FP300 paired to the M3 Hub. When changing certain parameters, it prompts the user to press the button on the FP300 to wake it up to establish a real-time connection to it. I am glad they chose to prioritize battery life over ease of making these very infrequent setup changes.
3 Likes
I got mine up and running directly paired to Hubitat via Zigbee today, and it’s working great! Thanks for your hard work! 
My only suggestion is to not use child devices, it makes swapping devices needlessly painful IME.
3 Likes
I agree. IMHO, a sensor like the FP300 deserves its own dedicated driver. That allows it to expose the proper list of capabilities and user preferences, without any confusion/compromises.
I agree with @kkossev that dynamic capabilities would be the best solution. I appreciate his work and understand that developers will sometimes have different opinions/philosophies on code design. I respect @kkossev’s decision/direction.
4 Likes
