Exacq Unbreaks Avigilon Integration
For nearly 4 years, Exacq had broken and effectively blocked use with Avigilon cameras, as IPVM reported in January 2014.
Just the Avigilon motion detection was blocked, or Avigilon cameras in general?
VMD. There was no issue connecting to Avigilon cameras with Exacq, but you were limited to continuous recording. Now the VMD and I/O works.
Didn't VMD anyway work if you just changed the onvifnvcpi.json file, as you pointed out in 2014?
At the time, yes, but it wasn't officially supported and would be overwritten every time you updated. I think support got a little spotty at one point, as well.
That makes sense because it's ONVIF motion detection, not some propreitery version.
So if VMD worked for other ONVIF cameras on Exacq, and assuming Avigilon's implementation was correct, there's no reason it wouldn't work.
Therefore Exacq had to explicitly mark Avigilon cameras as not supporting ONVIF VMD so that the VMS would not even try.
So really Exacq didn't just break Avigilon VMD, but actually had to break their ONVIF VMD in a way that made it not work for Avigilon.
Nope. ONVIF events are not standardized, even something as simple as VMD. Manufacturers can use different XML strings for events as they see fit.
So in order to integrate various manufacturers, you need to know where their event stream is. It's not much in the way of coding requirements, but it still has to be integrated for each manufacturer.
That's what the onvifnvcpi.json file contains, the manufacturer name, the event (motion), the location of the event stream (RuleEngine/MotionDetection/), the specific motion event name (MotionActive), and whether it's off or on (1/0), shown here:
Nope. ONVIF events are not standardized, even something as simple as VMD. Manufacturers can use different XML strings for events as they see fit.
Are you sure about that? The strings are not arbitrary manfacturer creations, IMHO, and in any case they are dynamically discoverable at run time. The Analytic test tool expects:
So in order to integrate various manufacturers, you need to know where their event stream is. It's not much in the way of coding requirements, but it still has to be integrated for each manufacturer.
I agree that Exacq did it this way, and therefore needs the Avigilon entry in the file; but I don't think it was necessary based on the ONVIF docs I have seen.
They unfortunately are arbitrary strings.
In that onvifnvcpi.json file you can find the strings for multiple manufacturers, here's a sampling:
- VideoSource/MotionAlarm/
- VideoSource/MotionDetection
- VideoAnalytics/Motion/
- VideoAnalytics/MotionDetection/
- RuleEngine/MotionDetection/ThresholdCrossed/
- RuleEngine/CellMotionDetector/Motion/
Some use 1 for on and 0 for off, some use "true" and "false", etc., etc.
They unfortunately are arbitrary strings.
Agreed they are different. Though they look somewhat more alike than arbitrary, consider for instance stream URLS. Maybe it's a holdover from early ONVIF implementations?
Regardless my point was that whatever data definition the device used it could be dynamically retrieved at run time via SOAP calls etc, obviating the need for the motion parts of the file. Perhaps it was easier for Exacq to manage it the way they did it.
Now the new Analytic test tool expects RuleEngine/MotionRegionDetector/Motion and event.
8.8 has been the best feature release in years in my opinion. Exacq nailed it on this one.
Is it possible to use current Avigilon models with the latest versions of Exacq still or is it limited to specific models. They only have a couple listed.
We've had an Avigilon camera added to Exacq for months, if not more than a year, with no issues. It only works with the camera's VMD, not analytics, but is otherwise fine.
Archived video from today, with motion highlighted blue in the timeline.
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.