Hubitat staff have mentioned they don’t always get a positive response when they have reached out to other device manufacturers re: integrating.
While it’s true that reverse-engineering a protocol is sometimes an option, and is common with Home Assistant’s open-source approach to integrations, Hubitat staff have said that they understandably prefer to avoid that approach.
I have two of these FP2 sensors. 100% local integration with HE is not a problem (HA + HADB).
But at least in my case these toys are still 100% useless because there are leaving too many ghosts too often. Therefore automations based on FP2 sensors are near 100% useless.
It is what is is.
This is where I think users need to (positively and politely) contact the manufacturer, and demand change.
The users could ask for the manufacturer to work with Hubitat, to have a dialogue between companies. The company doesn't have to endorse Hubitat, just having a contact within the company for things like firmware bugs can be valuable.
In some cases they could ask that the manufacturer send engineering samples to Hubitat. That has been an issue at times over the years, especially in regions outside the USA, with devices we don't commonly have here.
Users could ask the company if they would provide a documented local API if the device or service is cloud based.
There are other things as well, but that is what I understand are some common barriers.
There are a couple of ways you can integrate an Aqara FP2 sensor with Hubitat that are 100% local. Both solutions do require some additional always-on hardware in your house.
As mentioned by a few others, you can pair the FP2 sensor with Home Assistant using the HA HomeKit Device integration. This does NOT require any Apple devices in your home. The FP2 sensor simply shows up in HA, and then one can easily use the Hubitat Home Assistant Device Bridge (HADB) to bring the FP2 devices into Hubitat. This is what I do and it has been working great. Very reliable and very responsive.
If you do have Apple devices in your house, specifically an Apple TV or an Apple HomePod, then you can simply pair the FP2 with Apple Home via HomeKit. This will bring the FP2 sensors into your Apple Home system, where you can then create Apple Home Automations to update the status of Hubitat Virtual devices that you have added to Apple Home via Hubitat's HomeKit integration or via HomeBridge.
As mentioned earlier, there may be a few other options available using SmartThings or an Aqara M3 hub. I have not tried those solutions and thus cannot provide any more information than what has already been suggested.
Note: I also use Home Assistant to bring my pair of Ecobee thermostats into Hubitat using the exact same approach as option #1 above. 100% local and very reliable.
Any cloud dependency isn't worth it for this device IMHO. HA via their HomeKit Device with HADB to bring it back to Hubitat is the way to go. 100% local (you can block the internet connection to the FP2 and it still works). Plus, there are far more additonal integrations and devices to be gained (including nearly every Aqara and Mijia device) for the vast majority of Hubitat users by adding HA and HADB, than there is by adding an M3 hub that only gives you Aqara devices and still has cloud dependency for some of them.
@Stu_The_K The reason HA can join the FP2 as a local device, is the HomeKit Device capability (HomeKit devices join to HA). This was previously named HomeKit Controller (a name that honestly made more sense, becuase that's what it is). This HomeKit Device integration on HA is different from their HomeKit Bridge integration (HA devices can join another HomeKit controller), HomeKit Bridge on HA is similar to how Homebridge and Hubitat's HomeKit integration work.
I don't use any Aqara devices so am unfamiliar with those specifics but generally...
Hubitat uses WiFi as a client and not as an access point. Clients need a common access point to communicate with each other. Access points can also have a router included but do not have to. If not, those APs serve only as LAN access. WiFi smart home devices almost always use the local access point to go to their cloud service so if Hubitat is set up to also be in that cloud service through integration, they can share data. I may have heard of WiFi devices being able to be connect to on the local vLAN but have no first hand experience with that. For me, if the device uses WiFi the common connection is out in the cloud somewhere. Meaning there is more delay and no cloud access means any device integrated through the cloud stops working. This is why when I went to Hubitat, I replaced all the WiFi switches, locks, and bulbs with their z-wave or Zigbee counterparts. I still have cloud dependent Google Hubs and Minis for speech announcements and voice activation. Plus there is the Abode security system integrated with Hubitat through Abode's cloud. Of course if there is trouble with my ISP or Abode's cloud, all that slick integration fails.
While the Zigbee and Z-Wave protocols are excellent for most of our home automation applications, they are not the best fit for power/energy reporting devices and presence/position/distance reporting devices such as the mmWave sensors, due to their low data rates and limited bandwidth. A dozen chatty power plugs and mmWave sensors can easily congest the Z-wave or Zigbee network.
Protocols like Wi-Fi and BLE are better suited for these use cases. Unfortunately, very few WiFi smart device manufacturers provide detailed local API documentation.
Meross MS600 mmWave sensors so far are working very well. They was/are a replacement for the Linptech sensors (these also worked good but was getting frozen every 6-8 weeks, the only "fix" is/was to recycle power but I didn't like this "fix").
I've been curious about these given PIR + mmWave, and a matter interface - Only thing I didn't like was the requirement for power. My big question is around latency, how fast are they to respond?, as some of my early PIR devices would take a good 1000ms to report presence.
What driver do you use for the Meross MS600 to use it in Hubitat?
Also, and I hope this is an obvious "yes", what I want the mm Sensor to do is to not turn on a light when presence is detected but if presence is detected to turn off a light once it is not detected for say 1 minute. I'm guessing that in pseudo code it would look like this:
Trigger: Presence detected
Wait: Presence not detected for 1 min
Action: Turn off light X
If so, which app would be best for that?
If you are wondering why I would want such a use case, I have a family member who forgets to turn off lights constantly. So when this 1st person leaves the room (and there is no one left in it) the light will be shutoff. However, I have another family member who often gets up at night and goes into that room. This 2nd person doesn't want the light to come on to make it easier to see going back to bed and to help fall back asleep faster.
But don't I need a trigger to have presence detected and then not detected for say 2 min? I'm afraid that with just your 2 commands it would be trying to turn off the light every 2 min.
That’s not how that particular trigger works. It will only start the 2 minute ‘stays’ timer when the motion goes to the INACTIVE state.
No need to worry about motion going ACTIVE as you only want to turn off the light when the sensor goes inactive and stays that way for a specific amount of time.