I have been experimenting with the new Unifi Protect drivers and find the events a bit surprising. In general I am getting the AI detection events before the motion events.
I imagine this is due to the motion configuration for the camera.
The trigger threshold has a minimum of 1 second. What is interesting is that the AI detection is faster than that. Is anybody aware of any further settings that may impact the motion alert sensitivity? I am currently testing one G6 Turret, one G6 Bullet, and two G5 PTZ cameras.
The smart detections also appear to be more stable.
In this example, two people were walking and didn't stop. As you can see the motion flipped back and forth between active and inactive several times.
One of my cameras only sees a small section of roadway. In this case it sends AI detections for vehicles but never sends a motion event. This is likely due to the 1 second trigger threshold setup in the camera config.
None of this is a real issue. I am currently testing the new drivers to see how useful the events are. The only real pain point so far is the missing or lagged motion events. I can't setup a rule that uses "when all motion stopped" as a trigger. I can use the AI events something like this:
It works but is a bit unwieldily.
Overall the system is working nicely. The local wildlife is a bit more wild than I realized (downtown Vegas). Before recently adding the Unifi cameras I had Ring cameras that only recorded events on the property. This was intentional so that they didn't trigger lots of false alarms. The Unifi cameras are now recording 24/7 and the mix of onsite and offsite data storage is nice.
Would it help if the driver had an added preference to do "motion: active" for any motion or any Smart Detect event from the camera? (Right now, you have to pick one or the other, or some single or combination of Smart Detections for the latter.) This is the "Generate 'motion active' event for..." preference on the camera device on your hub.
As for the motion events themselves, I'm not sure why yours is doing that, but the driver is just reporting the events as they come in in real time from the UniFi Protect API. It's likely there are some settings you can adjust in Protect that will change how this works, but I've also noticed motion going active and inactive fairly quickly. Personally, I set the above preference to "Smart Detection: person," as that's really all I care about, and then I can use the device as effectively an outdoor motion sensor -- but one that's a bit smarter than PIR sensors that are sensitive to sunlight and other oddities. (This seems like the most likely use case, say, turning on/off a light.) Of course, your needs may differ.
It is definitely a threshold in Protect. I was curious if anyone had found other settings that might impact the sensitivity. If it was or became a real issue I would hit up the Unifi forums. I wanted to see how others were using it in HE.
For testing I have one light that I'm turning on when any of the four cameras detect motion. Motion events are multi-select and custom attributes are single-select. This is why I have the odd trigger and conditional in the above sample.
I've thought about mapping the smart detection to virtual motion sensors. Your suggestion about detections triggering motion events would also work. In any case it isn't a serious issue. As with all new things it takes time to figure out the best use cases. Before the new integration was added I had motion events turned off on the cameras. I was only monitoring the AI events. I turned them back on to see if it would make my rule triggers easier.
So I had a bit of fun and created a simple app to monitor the cameras in realtime. It is listening to the event web socket.
Motion turns red when the driver reports active motion. Event changes based on event type (Person: red, Vehicle: orange, Animal: green). Any turns red on any motion or event.
It is interesting to see them like this. I have found that motion is not very reliable. I see a lot of motion events that don't get reported. When there is a motion event it will typically stay active slightly longer than the smart detection. It also tends to go through several active/inactive cycles per event. Combining the two gives the most consistent detections.
Should the driver combine the events? I'm not sure. It would make some rules easier. At the same time it would reduce the flexibility. Regardless, it was a fun experiment and helped me with my Swift programming. 
To be clear, this would be a preference, not mandatory behavior. I think the reason I never thought to do it was that Smart Detections, at least the ones I cared about, always corresponded with motion -- person, animal, etc., which sort of makes sense considering that they don't come out of nowhere. Of course, there's still the question of why they aren't coming through as "motion" on your camera, even though you have that setting enabled in Protect. Maybe it depends on the model, some combination of settings, or how quick the event is -- but I think our settings are pretty similar.
If there's an actual use case for this, I could look into adding an option.
It would be an interesting option, but not sure it is worth the effort. The Swift app I wrote illustrates the events nicely. The realtime visual display makes it easy to follow the timing.
The detections are, interesting, to say the least. The camera that gets the most traffic is a G6 Bullet. When a car goes by I always get a smart detection but sometimes won't get a motion detection. Then when there is a motion detection it often will toggle between active and inactive a couple of times.
Another Unifi anomaly I see is that the cameras often do not trigger an event for a fast moving standup scooter or bicycle. It seems the AI just can't decide what it is. This isn't a problem in my case as I'm not interested in the ones moving fast, it is the loiterers that I'm on the lookout for.
I've added counters for total and person triggers.
The counters are based on the Any detections so the counters don't get inflated by the erroneous motion events.
1 Like
