What are the standard practices for outdoor sirens?

richardfj

Member
I have four outdoor speakers (Elk-1RT) and four strobes (Elk-SL1) mounted to the outside of my house, connected to my Elk-M1G. The speakers connect through a voice/siren driver (elk-120) and draws power from a secondary 4A power supply.

First - I am planning on powering the strobes through a relay with power from the secondary power supply, activated from one of the main board outputs. Is this the best way to do it?

Second - I saw another post about secondary power supplies and the need to connect the -ve from the secondary power to the -ve on the main board. My thought would be that this is not necessary for the power circuit for the strobes (or the sirens) since those circuits are independent from the main board, is this correct?

Third - I am planning on using the voice/siren option on the elk-120, which gives me 2 voice and 2 siren channels. The siren modes will activate as normal through a trigger from Out2. I'm planning on using the voice channels for a couple of announcements across the speakers. Most importantly, I want to be able to sound a warning if someone steps into my back yard triggered by my non-alarm motion sensors in the back yard. I'm guessing this is fairly straight forward with a couple of rules. However, for the siren I haven't been able to find any documentation for when and what kind of siren I will get from different alarms. The zone definitions do indicate that certain alarms are silent (such as "police alarm no indication 24hr"). Should I assume that those that are not specified as silent sound an audible alarm across both Out 1 and Out 2? If so, is there a table anywhere showing which zone definition generates a pulsing voltage on Out2 and those that generate a constant from Out2?

Last - What is the standard practice for when an outdoor siren should be used? I certainly want the sirens to sound in case of a burglar alarm, but I'm not sure I want the neighborhood to go crazy in the case of a fire alarm, especially if everyone is just going to think it's a burglar alarm anyway. Especially, I would hate the whole neighborhood to get a siren going off if I have a water leak in the house that trips a water alarms. Is there a standard and/or a code requirement? If I wanted to suppress all outside alarm sounds except for specific ones, should I run the outside speakers through a relay and disable in the case of fire/water etc? Does this sound unorthodox to anyone?

Thanks
 
No thoughts? I was at least hoping to get some direction on the third point ... I'd rather not hook up a small speaker to each of the outputs and go through all 40-some-odd zone definitions to see what alarm notification occurs with a trip of each ... I figured that a table exists somewhere out there ...

Third - I am planning on using the voice/siren option on the elk-120, which gives me 2 voice and 2 siren channels. The siren modes will activate as normal through a trigger from Out2. I'm planning on using the voice channels for a couple of announcements across the speakers. Most importantly, I want to be able to sound a warning if someone steps into my back yard triggered by my non-alarm motion sensors in the back yard. I'm guessing this is fairly straight forward with a couple of rules. However, for the siren I haven't been able to find any documentation for when and what kind of siren I will get from different alarms. The zone definitions do indicate that certain alarms are silent (such as "police alarm no indication 24hr"). Should I assume that those that are not specified as silent sound an audible alarm across both Out 1 and Out 2? If so, is there a table anywhere showing which zone definition generates a pulsing voltage on Out2 and those that generate a constant from Out2?
 
As far as the water alarm goes, if you define the zone as "25=Water Alarm", then you are going to sound the siren if the zone triggers. There's no way around this. If you don't want a full on alarm, define your water sensor zones as "13=Aux1 24hr alarm". Then write a rule for what to do when the zone is triggered, i.e. send a text message, display message on keypad, beep, etc.

I don't think there's anything wrong with a full alarm in the event of fire. If there truly is a fire, then you want your neighbors' attention.

No answer to your other questions. Good luck.
 
Richard --

I share many of your questions and am disappointed that there has not been a greater response to your post (and thanks to CORT for the good information).

The ELK documentation, while good overall, is deficient in some important respects. I would like to see an "M1 Implementer's Guide" that takes the installation documentation to the next level, providing more of the how-to's and insights that come only from inside knowledge. The good computer manufacturers of years ago (DEC for example) did this very well. They supplemented the engineering-style straight documentation -- which was simultaneously indispensable and impenetrable -- with Programmer's Guides in a "here's what we meant"-style that you could actually use to get results.

Is this a revenue matter for ELK? ;-)

I have only a few hours a week to devote to HA and these hours (1) are too valuable to waste and (2) are rarely at times when I can afford to experiment with sirens.

Dave
 
Last - What is the standard practice for when an outdoor siren should be used?

I'm thinking that I read somewhere about my community's local requirement that outdoor sirens silence themselves after 5 minutes, regardless of the cause, whether an emergency or a nuisance alarm.
 
1. Sounds good to me; did the same thing.

2. Negatives tied to ensure a common voltage reference.

3. I haven't tested all alarm conditions so I only know of the burglar and fire alarm tones. Other alarms may simply use one of these two choices.

4. Burglar and fire alarms are valid candidates for exterior alerts. Not sure if you can use rules to prevent other alarms from sounding an exterior siren ...
 
4. Burglar and fire alarms are valid candidates for exterior alerts. Not sure if you can use rules to prevent other alarms from sounding an exterior siren ...

If CORT is correct, there is no way to disable outdoor notification for alarm zones. I might just take a Saturday afternoon and log what the output is for each of the different alarm zones ... if I do, I'll post the results. However, regardless of the actual behavior I'm guessing I could set up a rule that triggers a relay to cut the power to outdoor sirens in the case of certain alarms. I guess I could end up getting a short chirp outdoors before the relay cuts the connection, but it would be better than the sirens going off for minutes at a time.

Another alternative would be to use cutoff timers to disable the alarm for eg. water alarms and instead set up a rule to make some sort of indoor notification / email / etc. in case of a trigger. If I use a NC relay I wouldn't really have any risks of not sounding the alarm in the case of a malfunction, so I'm not sure one solution is better than the other.

Either way ... the best solution would be an Elk firmware update that allows me to set alarm notification by zone type. I'm guessing the easiest way would be to allow cutoff timers to be a trigger to disable notification alltogether and then also allow the cutoff timers to differentiate between out1 and out2 ... Dear Elk - Pretty please ;-)
 
Speaking of cutoff timers ... has anyone else had a problem with setting cutoff timers with ELK RP 1.6.26? For some reason I can't pull up the timer values in the software ... it looks like the pic attached ... there is basically no way to see the timer values because the window won't expand to show the values. I've tried everything from changing screen resolution to closing and opening different other windows, but I can't seem to see the cutoff timer values. Anyone else?
 

Attachments

  • Picture1.jpg
    Picture1.jpg
    42.1 KB · Views: 34
Speaking of cutoff timers ... has anyone else had a problem with setting cutoff timers with ELK RP 1.6.26? For some reason I can't pull up the timer values in the software ... it looks like the pic attached ... there is basically no way to see the timer values because the window won't expand to show the values. I've tried everything from changing screen resolution to closing and opening different other windows, but I can't seem to see the cutoff timer values. Anyone else?

Boy, that's odd. I am running the same version of RP and don't have this problem. What version of Windows are you running? If it is Vista, you might check under your control panels, personalization, adjust font size (DPI) to be sure DPI is set to default. RP does some odd things if DPI is set to larger.

You should see something like this:
RPCutoff.jpg
 
... there is basically no way to see the timer values because the window won't expand to show the values. ...

This behaviour also exists in ELK RP 1.6.22. My display settings are set to 1280x1024 at 120dpi. Most Windows XP applications were developed under the assumption that the display will use the default setting of 96 dpi. Many apps do not adjust the dimensions of their UI elements to accomodate 120dpi and so some are cropped, obscured, etc. There's not much you can do about this except reduce the DPI Setting to 96.
 
I might just take a Saturday afternoon and log what the output is for each of the different alarm zones ...

Well since I am depending on Aux1 for my Basement Water Detection Alarm and Aux2 for my Septic System Backup Alarm, I did some rough-and-ready experimenting and am somewhere between puzzled and unhappy with the results.

What I want is this:
- Activate an Aux alarm when any associated zone trips
- Never sound Out 2 but handle the alarm entirely through automation rules
- Maintain the alarmed state indefinitely until manually reset, even if the zone is secured
- Reset the alarm with * (asterisk key) like everything else
- Ensure that "alarm inactive" is reflected in automation rules when the reset occurs

What I found is this (preliminary, may have errors):
APPARENTLY, for Aux1 and Aux2 --
- Alarms cannot be reset with * (asterisk key)
- Seems that if Cutoff Timer=0 the alarm will clear immediately once the zone is secure. But otherwise...
- Cutoff Timer setting does not seem to make a difference; rules that depend on "Alarm Active" just keep going and going
- Securing the zone does not reset the alarm
- Bypassing the zone does not reset the alarm
- Based on the above, it is not clear exactly *how* these alarms can be reset. I had to power down the M1 after each test.

If you want alarm memory after a zone has tripped and reset, naturally you need to be able to acknowledge the alarm. I do not see yet how to do this.

Needs more work. Or documentation from Elk.
 
So Lagerhead's experience is beyond what I can document at this point ... but that seems odd ... rather annoying I would imagine

I did go back to the manual and realized that page 33 of the manual contains a description of which alarm types generates what outputs (I have absolutely no idea how I managed to miss that the other day ... I can swear I read that section looking for the info). HOWEVER, the section states that a WATER alarm "is not preassigned to any outputs" (as is, CO, emergency, freeze, gas, heat, aux1 and aux2 ... YET, when I hooked up a water sensor the other day and tried the sensor in a glass of water ... it definitely sounded an alarm (at least across Out1). For those alarm types, it specifically states that "the RP software rules function must be used to assign outputs" ... well .. that's definitely not accurate ... hmmm

Btw ... for Burgular, Fire, medical and police, it states that Out1 and Out2 are ALWAYS activated. In other words, without a relay, for those alarm types there is no way of excluding an outside alarm notification ... which I guess seems like a very reasonable setup ... if it actually worked that way

I guess after I go back to do a little verification, this is probably worth a help desk tic
 
This behaviour also exists in ELK RP 1.6.22. My display settings are set to 1280x1024 at 120dpi. Most Windows XP applications were developed under the assumption that the display will use the default setting of 96 dpi. Many apps do not adjust the dimensions of their UI elements to accomodate 120dpi and so some are cropped, obscured, etc. There's not much you can do about this except reduce the DPI Setting to 96.

and btw ... I tried this and it worked ... thank you.
 
HOWEVER, the section states that a WATER alarm "is not preassigned to any outputs" (as is, CO, emergency, freeze, gas, heat, aux1 and aux2 ... YET, when I hooked up a water sensor the other day and tried the sensor in a glass of water ... it definitely sounded an alarm (at least across Out1).

Agreed. This was why I (reluctantly) adopted Aux1 for my water detectors, and avoided the Water alarm type.

Dave
 
Back
Top