I have released v1.0.8 via HPM and my GitHub repo. This version hopefully helps to correct the issue that I inadvertently re-implemented that @kkossev had fixed in his driver months ago. Thank you @kkossev for pointing me in the correct direction!
The root of the issue lies in the way the FP300 sensor reacts to having some of its settings changed. In particular, setting the PresenceDetectionMode (Both, PIR, or mmWave), will cause the sensor to lose its existing mmWave sensor calibration. Even if the value has not been changed, just sending this data to the FP300 causes this issue. I have implemented a solution in v1.0.8 to only send that setting if it is changed. However, if you do change that setting, it is very important that you wait a few minutes, and then perform a Spatial Learning (after waking up the sensor by pressing its button and vacating the room.) This is the only way I have found to get the sensor to properly behave after messing with that setting.
It also appears that the two somewhat mysterious AI learning settings (aiInterferenceIdentification & aiSensitivityAdaptive), which are not found in the Aqara Mobile App for this sensor when paired to an Aqara Hub via Zigbee, also cause the mmWave sensor to lose its calibration if those are written to the FP300. For now, I have commented out those two user preferences. If anyone knows of a valid reason to keep them (i.e. you have evidence that they actually work to solve an issue), please share this information and I will consider adding them back into the driver.
Again, sorry for any inconvenience this has caused anyone today.
Lesson learned for the day - If in doubt, RUN SPATIAL LEARNING with an empty room.
I don't have definitive evidence that they work. The adaptive sensitivity appeared to be on by default on the multisensor version of the driver. While I was on the other driver, I had less false negatives. After switching, I still have issues with one device giving nearly constant PIR false positives. So, I switched that one to mmwave only until I can order another to replace it. I had another one that was showing mmWave as unoccupied when it should not. I turned on the adapative sensitivity and it appeared to be getting better. Too short of a time and not enough instances to state a direct cause/effect.
Would it be possible to re-enable them, and maybe have the same caution note you have for the mmWave/PIR/Both preference? (or put it in an advanced or experimental section?)
Just out of curiosity, how were you determining it was not enabling?
Found an article that said that the interference was useful, but the sensitivity gave false negatives (which is opposite my experience as well) Those features are discussed Waaaay down the page under the Z2M capabilities.
Yes, for sure I will do that. Adding them to an Advanced/Experimental section makes quite a bit of sense, IMHO.
I was running out of time yesterday, and I really wanted to get a release out that would hopefully resolve the issue that I created earlier in the day.
I have released v1.0.9 via HPM and my GitHub repo. This release restores the two AI user preferences and adds them to an Advanced/Experimental section on the Preferences page. I also tweaked the code a little to change two @Field variables into 'state' variables. These two vars are used to ensure the 'motion' attribute displays the proper data based on the PresenceDetectionMode preference. Yesterday, I learned that @Field vars are reset every time the driver code is saved/upgraded. Since I have been doing that quite frequently, I discovered this behavior. Using 'state' variables will avoid any of you having wonky values of the 'motion' attribute, I hope!
Thank you all for your patience and your feedback!
Out of five, I have one that I had to disable the PIR to prevent constant false positives. This happens regardless of AI features on or off (If I have it set to "medium" sensitivity - Constant false positice. If I set it to low, it never triggers PIR).
I have two that will register false negatives with AI on (one of which is the one that the PIR is messed up on).
The other three appear to be more reliable with the AI sensivity on, but the AI interference off. They seem to be working perfectly.
Room size is different for each of the 3 that work well. SMALL bathroom, Open Area kitchen (Large), and small to medium living room. Fan in the kitchen that doesn't seem to affect anything (at least over the past 3 days)
Yep, mine shows PIR active constantly.... like literally. It shows active for 1 or 2 minutes, then inactive for a split second, then back to active. I had to change to mmWave only to deactivate the PIR sensor. But, it is only that one. Found a forum over on the HA side that mentions the latest firmware is to blame.
I’d like to see @ogiewon out the PIR reset delay setting back in - I was playing with it before switching drivers, and unless Dan’s driver restores the defaults for hidden settings, I’d like a way to be able to put it back to the default.
That is assuming The Multi Driver was actually modifying the setting.
@dJOS I agree that the AI settings does something crazy to the sensor. I have 6 of these throughout my house. 5 are connected to an M3 hub where you don't have the option to mess with those settings. I have had zero issues with them. Work perfectly.
I have the one I setup and used for testing for Dan. When I first set it up the AI sensitivity setting was turned so I turned it off and I turned on the AI Interference setting. That snesor would then trigger motion for PIR and then mmwave almost every hour on the hour, stay active for almost exactly 1 minute then go inactive again. This would happen every hour within a couple minute window.
When trying a new version for him I done the whole ritual of taking the sensor out of HE, resetting by pushing the button 10 times, and joining back. Both AI settings were turned off on that join and I didn't touch them. The false positives were gone.
Not saying that is the source of all the issues because I think @tray_e may have a bad sensor but it most definitely can cause its own issues.
