The blaring sound of a siren has never sounded so sweet.
But then again, I’ve also never spent weeks trying to set up a strobe siren before.
As anyone who manages a surveillance system knows, nothing is ever as easy as you want it to be.
I anticipated some road bumps but this installation really put my creative problem solving skills to the test!
Maybe it’s my own fault.
I can never just “install a strobe siren.”
Instead, I have to install a strobe siren based on two triggers, an intrusion system being armed and when AI detects suspicious activity.
Pretty cool though, right?
I thought so.
Before I spill the beans on how I got this to work, I’m going to walk you through all of the issues I encountered so you understand the why behind each of the tools I used and extra steps I added in.
This is just how I thought of getting around the issue, but I would love to hear how you would have done it.
I wanted to install a strobe siren but I didn’t want my neighbors to hate me so the standard motion activated settings were not going to work.
In an ideal world, the siren would only go off when suspicious activity was occurring so intruders and hooligans would be deterred.
But how does one program a device to know the difference between a vandal and a delivery driver?
My idea was to only trigger the siren (well the really loud one anyway) when my intrusion system (burglar alarm) is armed and when video analytics, specifically Axis Object Analytics, identifies something I deem suspicious.
Simple enough, right?
Here is everything I used to configure this solution:
Think about it, there are thousands of non-suspicious actions that take place on the street every day. Deliveries, cars, pedestrian etc.
Since I don’t want the siren going off all day, every day, I can’t configure it to just be motion activated.
I needed to find a way to establish appropriate and inappropriate triggers.
The most obvious answer was to sync it with the burglary alarm. It’s not the complete solution I was envisioning but it was a good start in the right direction.
When I asked the Milestone support team how to do that, they recommended that I get the Milestone Custom Development Actions plugin.
(As a side note, I didn’t even know this plugin existed before this conversation and it totally blew my mind.)
This plugin adds additional actions to the already powerful rules engine. One of those new actions is to allow a rule to “activate” another rule.
ie. When the burglary alarm is armed, it would trigger a rule that turned on video analytics to turn on the strobe siren.
If you’re thinking “Of course, so simple! Great ide—”
I’m going to stop you right there. It was too good to be true.
There is a limitation within the Custom Dev Actions plugin that says:
In other words, the rule that was supposed to trigger the Axis D4100-E comes from the Axis Optimizer and Axis Optimizer qualifies as a “custom development action” and is therefore forbidden.
So now…how do I get the strobe to fire only when the intrusion system is armed since I can not use the Axis Optimizer, what can I use instead?
Since I couldn’t use The Milestone Custom Development Actions to trigger the rule within the Axis D4100e, I turned to User-Defined Events (UDE).
A User-Defined Event (UDE) is an event that I create and can call on as a user or programmatically as a rule.
While it may take a few more rules than I originally thought, it seemed like it could work.
(spoiler: it did)
Here’s what the workflow ended up looking like:
The first thing that sets this series of actions in motion is the intrusion alarm is armed. I integrated the intrusion alarm using an input into Milestone.
Once the intrusion alarm is armed, the Milestone Custom Development Actions plugin turns on a “trigger rule”.
This rule remains off by default but once on, it is waiting for a signal from Axis video analytics that it detects suspicious activity.
I can’t share the exact screenshot of my rules with you but it looks something like this:
Perform an action on Input Activated
From Input 2
Activate UDE Trigger Rule
Perform stop action on Input Deactivated
From Input 2
Deactivate UDE Trigger Rule
The Axis Object Analytics is running in the Axis camera. If it detects a human crossing a line or loitering or doing some sort of action that I deem as suspicious then it fires the “trigger rule”
The “trigger rule” is simple and only has the Axis object analytics event which looks something like this:
Perform an action on Axis Object Analytics Event
From Camera 1
Create log entry: ‘$RuleName$’
And on ste Management Server 1 trigger user-defined event UDE1
This “trigger rule” fires the user-defined event aka UDE1.
UDE1 then fires the “siren rule” which ultimately sets off the siren.
Can I get a WEE OOOO WEEE OOOO
That’s the sound of victory, my friends!
If you liked this tutorial and want more helpful tips and tricks for managing your video security system, subscribe for our monthly The NOT Boring Newsletter!
It’s the newsletter security professionals use to work smarter. We promise you’ll learn stuff and enjoy a few blissful moments of productive procrastination.
Your go-to XProtect eXPerts. We learn the technical stuff that will save you time and make it less boring.
Your go-to XProtect eXPerts. We learn the technical stuff that will save you time and make it less boring.
Learn how to set up a smart strobe siren system that uses Axis Object Analytics with Milestone XProtect, minimizing false…
Learn how to use your VMS dashboard to identify issues, prevent downtime, and extend your system's lifespan with proactive maintenance…
The Boring Lab's Official Dad Joke Generator — Perfect for those who love to delight their friends, families, and colleagues…
Subscribe to get a monthly dose of security & surveillance industry news and insights, Milestone VMS time-saving tricks, tips for hacking your way out of boring work sent directly to your inbox!
