Elk and multiple Areas

mikefamig

Senior Member
This topic is a spin off from my ongoing problem in another message thread but I think it is simpler to start a new thread to talk about the topic of using Areas by itself. My application justifies two areas ,1 house and 1 garage that I would often arm separately but it is not absolutely necessary to use two areas.
 
Has anyone had any complaints or problems setting up areas with the Elk system? Are there pitfalls to avoid? Installer skills aside is the use of areas considered dependable and rock solid? Is it troublesome? Should I feel confident building separate areas or just keep it simple and use 1 area.
 
Mike.
 
 
 
I just setup an installation using (2) Areas, and once I get time to run the cabling (including trenching) out to my detatched workshop, I'll be adding a secondary Area to my system as well.
 
The only issue I had was addressing some of the arming functionality that the client wanted. In this case, they have a MIL suite, which has no one utilizing the space currently. Having said that, they wanted to arm both areas by default via the standard Away/Stay keys. However, if someone was staying there (e.g. weekend visit) they wanted to be able to easily arm only Area 1 as well - thus not effecting the visitors. When I was writing the rules for this I ran into some issues, but ultimately they were my fault (programming) and the issue has since been resolved.
 
I actually use areas for arm away & stay.
In away mode I have closets and drawers become active which provides me with yet another level of protection. Obviously, in stay mode they're not put into alarm service. It is accomplished automatically via rules - which will account for any variable I can think of as well. It is also very useful when trying out a new maid service. I have rules that are activated whenever the maid's code was used to disarm that will send me a text message anytime something is opened, such as a drawer in the master BR.
 
I'm running 3 areas at my house and also have multiple accounts that have 4 or more areas. Once you realize the limitations of the siren/speaker layout and the workarounds it's really not a big deal. I've come close to maxing out the input/outputs on an M1 but haven't come close to others I know of that require multiple M1's to be integrated as a single system.
 
The complexity starts showing up when you are using a single area and driving integration with multiple other areas into the single area and expecting the system to act as one large beast vs. a control panel with multiple partitions. It's doable but you need to consider how you want the big picture to operate as a single system vs. multiple smaller independent systems.
 
I'm looking for experiences with technical glitches and bugs but I'm glad to not hear any. I'll divide my system back into areas again tomorrow and see if it goes back to having problems.
 
Am I correct that it is just a matter of adding a second area and then assigning a keypad and zones to it?
 
Mike.
 
mikefamig said:
Am I correct that it is just a matter of adding a second area and then assigning a keypad and zones to it?
You don't need to assign a keypad. You can cycle through areas on area 1's keypad if you want.
 
mikefamig said:
Am I correct that it is just a matter of adding a second area and then assigning a keypad and zones to it?
For the most part, yes, until you get granular with siren/bell activation and announcements. In literally almost every multi-area install I've put in, the voice announcements for other areas in the main area were not needed or a concern and alarm sounding was done via relays and external sirens instead of speakers and the main board outputs.....lots of LED indications in the field and use of F-key and illumination events for the main partition to keep it user friendly.
 
And yes, as 321 stated, you can use a single keypad and view/operate multiple partitions as true partitions, but it becomes less user friendly unless you use rules, F-keys and automation events, otherwise it's typically an area that is driven from another event and really doesn't have fine control, it'll only do as you program it to do via rules.
 
In this case there is already a keypad in each of the two areas. I considered not putting one in the garage but am glad I did because of the convenience and the built-in thermometer being able to see the temperature in the garage is nice.
 
For sound I have the same out1 going to both areas. I did use an M1TWA so I can selectively mute one or the other.
 
There has been a new development with getting the system all up and running again. As I said earlier I have only one area at this point and only hardwired zones. It ran well that way for a few days and yesterday it automatically rebooted itself.  Following Elk's instructions I tested the resistance of the data bus at the control and it is 63.5 ohms which is good. They then had me re-install the M1 firmware 5.3.0 and so far so good.
 
I think it's interesting that after the new install of the 5.3.0 firmware which I had already installed, the "system settings" display on the keypad has changed. When I go the the "system settings" menu the keypad now displays "system settings .2"  I do not recall the ".2" being there before. It's the same version number but it appears that the firmware has changed. Can someone explain this?
 
Mike.
 
I use two areas myself.  One for the attached garage and house and the other for the garage attic and crawlspace access.  Since the crawlspace and garage attic can be accessed from the outside of the house, I wanted these areas to be armed even when a person is at home.  Works great, although I do use a single keypad for both and changing between the two areas is a bit of a pain.  Fortunately, it is rare that I need to go into the crawlspace or garage attic.
 
I could see where putting a detached garage on it's own area would be helpful, especially if the garage is used infrequently.  If it is used a lot, then I would definitely recommend getting a separate keypad for the 2nd area.  It will make arming and disarming it much easier.
 
OK I added a second area to my system. All of the areas in both zones are defined as entry/exit 1.
 
When I arm area 2 the system chimes that a zone in area 1 is violated (which it is) and Elk tech support tells me that this is normal but it makes no sense to me. Doesn't that defeat the purpose of having separate areas in the first place? Why would a person want to know the state of zones in area 1 when he is in area 2? I thought that the reason for defining areas was to prevent this sort of thing.
 
Suppose you have two separate business offices in a building and split them up into separate areas. One office closes up and arms the system and hears that a window is open the the business next door. Why? How do I avoid this?
 
Mike.
 
Are you using a single keypad to manage both areas?
 
I've only used (2) Areas once before and I had a dedicated keypad for Area 2. It does not chime or provide any information about Area 1. However, I did install a TWA to separate audible messages from the installed speakers (one at each keypad).
 
drvnbysound said:
Are you using a single keypad to manage both areas?
 
I've only used (2) Areas once before and I had a dedicated keypad for Area 2. It does not chime or provide any information about Area 1. However, I did install a TWA to separate audible messages from the installed speakers (one at each keypad).
I have two keypads. There is a m1kp2 in area1 and a m1kp in area2. I also have a m1twa and it is presently set to output to both areas. Channel 1 is connected to a speaker in area1 and channel two connected to a speaker in area2.
 
Muting the chime is not a solution to my problem. I want to hear chimes in both areas. If I am working in the detached garage and the front door of the house opens I'd like to know and if I am in the house and someone enters the garage I'd also like to be alerted. I may have cause to mute outputs by rules in some circumstances but not altogether.
 
As I said earlier, I arm area2 and at the end of the exit countdown the system chimes that a zone in area1 is violated. I'm not making this up....and Elk support says that it is supposed to do this. I just want to know why it is supposed to do this and how do I change it if at all possible.
 
Mike.
 
When you mention the chime feature are you referring to the Tone, Voice, or both?
 
The reason I ask is that I believe the tone comes from the KP speaker, whereas the Voice is coming from the TWA (in your case). I don't understand why Area 1 would make any announcement about it's zone status upon Area 2 exit delay completion.
 
drvnbysound said:
When you mention the chime feature are you referring to the Tone, Voice, or both?
 
The reason I ask is that I believe the tone comes from the KP speaker, whereas the Voice is coming from the TWA (in your case). I don't understand why Area 1 would make any announcement about it's zone status upon Area 2 exit delay completion.
 
I am talking about voice chime. It clearly announces a violated zone in area 1 upon the end of the exit delay when arming area two and I also "don't understand why Area 1 would make any announcement about it's zone status upon Area 2 exit delay completion". This is exactly my point.
 
Forget about the tones from the keypad, we are talking about voice chimes from out1.
 
Mike.
 
This sytem ran for days with no problems and zero data bus errors for three days. As soon as I re=attached and enrolled the 2way wireless adapter I began getting databus errors and the chime error returned.
 
I disconnected and un enrolled the wireless an hour ago and there are zero databus errors so far. I have also armed area 2 a few times with no errant chime.
 
I'm thinking now that it is either the cat5e/rj-45 connecting the wireless adapter to the control or the wireless adapter itself causing the trouble. I'll post an update tonight after it has run for a few hours.
 
Mike.
 
Back
Top