Zone Planning

[Del91574]

Smokes should be on a loop unless you have so many to even justify multiple fire zones....which in a residence is usually....next to never. Until a house is a multiple of your size, the benefits of separating out the detectors vs. complexity and other items that must be considered (such as reset, if 2/4 wire can be used...reversing relays, etc.).
 
Protective devices should NEVER be set on a 24H zone, they should always be controllable by the panel. I've almost never seen the possibilities of a person getting broken in while the alarm was left disarmed...and if you don't use the alarm when you're home/away, the purpose of it is somewhat moot to justify poor habits by using 24H zones.
 
Powered devices should be on their own zone, period.
 
Doors should be their own zone.

Windows, I generally say by room or if you have many, bank/wall.
 
CO's need to have other considerations if you're going on one or multiple zones....really it's more of a design and panel issue, not to mention the increasing conductor count if you put more than one on a zone.
 
Critical condition monitoring should be it's own zone. Panic buttons also.

 

[tmbrown97]

Regardless of how you program the panel though, I think the point is the same; for instance, if you have a basement in a crappy neighborhood where someone could break in without you noticing it, you might consider making it its own area - or keeping your alarm armed more often, etc. 

 

[Linwood]

I redid my builder installed system a couple years ago, and was pleased to see the hardwired sensors were all home runs, despite the alarm installer combining them into zones.
 
I separated them out, and every sensor is a separate zone.  Every smoke is a separate zone.  The zone expander is really cheap, and having it this way makes any kind of debugging MUCH easier. 
 
I have had two sensors start being flaky, and it was very nice not to have to guess or experiment to see which sensor was involved.  Yes, you can figure a lot of it out debugging.  But if you are doing it yourself, it's just the cost of wire really, and maybe an expander.  Think of it this way -- if it doesn't matter later, not much lost.  If it saves you frustration.... 

 

[Del91574]

If you're doing smokes, especially 4 wire units, there's a lot more to consider, which is why I would not recommend separating the 4 wire fire unless the original install did not wire them correctly (or install power supervision relays). Usually in doing this, you're going to introduce a whole lot more issues than running a single fire zone.

 

[Linwood]

If you're doing smokes, especially 4 wire units, there's a lot more to consider, which is why I would not recommend separating the 4 wire fire unless the original install did not wire them correctly (or install power supervision relays). Usually in doing this, you're going to introduce a whole lot more issues than running a single fire zone.

 
If that's to the OP, I thought it was new construction.
 
If that's for me -- I pulled out all the smokes the installer put in (they were un-monitored 110v devices) and replaced them all with new home runs to the panel, individually supervised.   Getting monitored fire was my main rationale for doing a new system.  

 

[Del91574]

Until you do a fire reset on a 4 wire system with multiple zones......assuming it's wired correctly with power supervision relays
 
Look at all the troubles and zone/CS activity you're going to create. What does that do to the panel and it's normal activity? What does that do to rules, flags, what have you? What is that going to do to the telephone line (or other comms route) and say in POTS, if the CS is intending on contacting you (ECV) in addition to dispatching the FD (no good CS should negate FD dispatch even on ECV, but the municipality should determine what sort of manpower to send).
 
FWIW, the fire reset and silence are items that aren't supposed to be modifiable or changeable in how they function and the panel responds to them....such as put X and Y into a rule but not Z. It's part of why I shudder about people wanting to program a F key or similar for fire reset but not code protect it.

 

[Linwood]

Until you do a fire reset on a 4 wire system with multiple zones......assuming it's wired correctly with power supervision relays

 
Actually we've had to do that once.  Cooking smoke (a lot of it, not a fire, but just a surprise with a new device) set off one, then another smoke detector.   I cancelled the alarm on the panel, did a reset -- they re-alarmed after a bit (we were still clearing smoke), did the cancel/reset again and that one stuck.
 
We then called the CS.  They had gotten the cancels in time they were not dispatching, but had received them.
 
I think it is wired correctly, and I think it worked as it was supposed to.  I guess I'm missing the point, I don't mean to argue, but if I've done it poorly I want to redo.   To me it seems like a reset should work regardless if on multiple zones (all reset together of course, regardless).  
 
 

Look at all the troubles and zone/CS activity you're going to create. What does that do to the panel and it's normal activity? What does that do to rules, flags, what have you? What is that going to do to the telephone line (or other comms route) and say in POTS, if the CS is intending on contacting you (ECV) in addition to dispatching the FD (no good CS should negate FD dispatch even on ECV, but the municipality should determine what sort of manpower to send).
 
FWIW, the fire reset and silence are items that aren't supposed to be modifiable or changeable in how they function and the panel responds to them....such as put X and Y into a rule but not Z. It's part of why I shudder about people wanting to program a F key or similar for fire reset but not code protect it.

 
I think that's true in the Elk, at least from reading some of their certification compliance literature.  And I haven't modified them of course.   
 
Yes, if I have a fire and it spreads, one smoke after the other will go off.  If we weren't here and it was real, I assume that the CS would do their call verification thing, and dispatch accordingly.  They could (not sure if they do) even tell the FD "the alarm started in the utility room" or "garage" or whatever.  Might not mean much as it's not a huge house.  But I don't see where it does harm.
 
Again, not trying to be argumentative, but trying to read between the lines is hard.  Assuming they are wired correctly and programmed correctly (or perhaps more precisely not un-programmed incorrectly), is the only risk that you are generating several times as much traffic on the line to the CS?   If your POTS line is also the only ECV line, and your primary reporting line, I can see that as an issue.
 
Is that the only downside of multiple fire zones? 
 
I am absolutely not a security/fire professional, I don't pretend that reading a lot (which I've done) is a substitute, but it does make me tend to have more questions, so I appreciate your patience.

 

[Linwood]

I should add that we also had one false alarm on the burglary side.  We were on vacation, and got a call from NextAlarm.  They were able to tell me that it was a specific exterior door.
 
I knew that door as it had once, maybe a year before, also given a false alarm while we were home (which was intermittent and by the next morning when I looked at it, it was working and I could not see/test anything wrong).  But could not confirm, they did dispatch, and found nothing.   I disarmed the system and bypassed that sensor remotely, and all went well after (well, except for the warning letter from the PD, no fine the first time though).
 
To me it was reassuring to have them tell me which sensor.  Also, when I got home, I knew exactly which to fix.  Because here's the rub -- it was a hard-wired sensor, not wireless, not PIR, original builder installed.  And by the time I got home (without that door ever opening or closing) it was working again.   I still don't quite know what was wrong with it, but removed it from the door and redid it entirely.   If it had been just one of 6 sensors on a loop I would have no idea where to start. 
 
I'm an information glutton -- whenever something is going to go wrong, I want to know as much as I can, have logs from the event.  That's why I like one zone per.  But maybe that's not the best setup for everyone.

 

[Del91574]

Fire alarm is a different beast.

You need to have a power supervision relay installed on each loop or zone at the end of line. If you remove power from your fire zone and it doesn't generate a trouble, then it's wired incorrectly.
 
Now, you have 4-5 zones of 4 wire fire...you perform a fire reset, which removes power from ALL the detectors, so that's going to generate a trouble (assuming proper wiring) on each zone that has a detector installed on it. Now, think about the amount of troubles and additional system actions that need to be performed to clear those basic troubles on a reset (varies by system, but some may require a code + off or whatever reset method they support for EACH zone that is in trouble to clear)

Let's make a slightly more complex system, add a reversing relay to generate a tandem ring for the fire alarm....so now, in addition to the single fire trouble while the power to the detector(s) is reversed to generate the tandem ring, now you're going to generate a trouble (again, assuming proper power supervision, as required by code) at each zone, every time the temp-3 pulse goes, since they're usually sync'ed by the module itself or via an external temp-3 trigger. So now, we're going to be hoping that swinger shutdown isn't enabled on the fire alarm (think about how many events you're generating)
 
So, now you have all that traffic and signaling going into the CS...so while they shouldn't see the account as a runaway, if their automation software is sending all to the account screen or buffer....tell me how much traffic is going through to them in addition to keeping a comms route active.
 
So, let's do some basic math....a temp-3 pulse is 4 seconds in total duration. That would generate 3 pulses per 4 seconds. Let's round that up to a minute long false alarm now.....so you'd end up with 45 individual troubles per minute per zone NOT in alarm. So let's say you have 4 zones of fire.....so you're looking at one zone in fire which latches the zone and shunts the trouble from reporting, but now, on top of that, you're generating 135 troubles on top of that alarm per minute the system is in alarm state (we're doing tandem ring).
 
So now, consider the comms route you're taking or sending this information to, if restoral reports are also being sent (doubling the amount of signals), then let's consider the event log and then the subsequent reset and 4 latching troubles and clearing the fire alarm. Conservatively you're at 140 individual system events (and reports) going to the log (or 280+ easily with restoral reporting)

Let's now take a peek at the panel log and tell me how many events and system transactions are in the log and buffer from a single alarm event.
 
Do you see an issue?  Ok, so you're not doing tandem ring on the smokes, so the number isn't as dramatic, but you're still generating a lot of reporting and traffic that really doesn't benefit you. It's easy enough to determine the detector that started the alarm (latched red LED) and silence the alarm (assuming no tandem ring/reset).
 
It's not that you can't put the detectors on their own zone, but there's a lot of other considerations besides knowing what detector generated the signal. If knowing which detector generated the signal is paramount, there are far better and easier ways to accomplish this that don't affect the panel negatively.

 

[Linwood]

Fire alarm is a different beast.

You need to have a power supervision relay installed on each loop or zone at the end of line. If you remove power from your fire zone and it doesn't generate a trouble, then it's wired incorrectly.
 
Now, you have 4-5 zones of 4 wire fire...you perform a fire reset, which removes power from ALL the detectors, so that's going to generate a trouble (assuming proper wiring) on each zone that has a detector installed on it. Now, think about the amount of troubles and additional system actions that need to be performed to clear those basic troubles on a reset (varies by system, but some may require a code + off or whatever reset method they support for EACH zone that is in trouble to clear)
...
Let's now take a peek at the panel log and tell me how many events and system transactions are in the log and buffer from a single alarm event.

 
Thanks.  I understand what you are describing, it's similar but not quite what I'm seeing in the log.  I'm also waiting to get display access to my new monitoring company (I switched yesterday) so I can see what they received.
 
But as an example, I did a test with canned smoke during the setup with Alarm Relay.  What I see in the M1G log is: 
 
1001 = Fire Alarm, zone 11
1300 = Exception Opening (my ID) when I acknowledged the alarm
1144 = Restore fire zone, zone 11
1144 = Restore fire zone, zone 12
1144 = Restore fire zone, zone 13

1144 = Restore fire zone, zone 14

1144 = Restore fire zone, zone 15

1144 = Restore fire zone, zone 16
 



I do have power supervision relays on each alarm.  I'll arrange to test them individually at some point (want to wait to get web access which I don't have yet at the CS), but I'm very confident they work as I did it myself and tested 2 years ago by cutting a wire to see that it was right.
 
So I'm not seeing the trouble indications, just the restore.  I've seen these before, and frankly didn't associate the "restore" to "Trouble" so much as to "reset smoke".  What's odd is I do not see the panel logging a trouble, which you seem to expect it to.
 
I do not know what was communicated (I should know Monday, as I expect to have access to the CS logs then).  I did have the setup guy watching each event that came in to them, and he didn't comment on anything being odd in receiving these.
 
Perhaps the M1G is masking the trouble indicator as a side effect of it holding the power off for the reset?   (I am not masking anything in rules, in fact I don't think I can mask trouble in rules). 
 
If i find anything interesting in the CS communication when I get that will respond.
 
Thank you for the more detailed insight.   What I'm a bit confused by still is what the concern is from this (in your scenario) huge amount of events?   is the communication time to send them all?   Confusion at the CS?   (They don't react to the restores, I think, and barely react the troubles - at least not dispatch sort of react).  Clogged communicator? 
 
I'm guessing the latter -- how fast is the Uplink 2500,do you know?   I'm doing Uplink + ethernet.  The Ethernet should be very fast, I assume no issue there.  If I really did send 280 events (and it looks like I sent 8), is that a couple seconds or minutes?    I realize POTS depending on protocol could be very slow, but I'm not using POTS.
 
Or is there another concern? 

 

[pete_c]

Here I do stuff adding much resilience.  Mostly just enough for the CS and more for me autonomously. 
 
IE: like I watch my sprinkler system and will get a status from it; but that is not ever sent to the CS. 
 
A doorbell ring creates a multitude of events et al; which I may or may not look at; but that is never sent to the CS.

 

[Del91574]

Based on the log I can tell you're not using a reversing relay, so the extreme number scenario isn't going to come into play.
 
I can't comment as to what you're seeing or not seeing because of the variables in communications programming available on the M1 (restorals, troubles, etc.) Keep in mind, what you're seeing from Next is not accurate...you're only seeing the events as summed by their automation software, not the raw system data. Also, you're only dealing with a tech seeing the data on the automation end of the system, not the raw data....and does that tech know what they are looking at specifically or what is really involved with the panel besides the signals it is sending (my experience is they don't 90% of the time)
 
The only item I can think of is the system is shunting the troubles on the additional fire zones during a reset, which many systems DO NOT do....keep in mind, I don't run multiple forms of fire on the same area and tie 4 wire fire to multiple zones while sharing power and reset methods, it's not how it's done in the professional world. The other zones, which are not in alarm state, should generate a trouble if the supervision relay is wired correctly and the system pulls power from the entire 4 wire fire source. The 1144 event provides confirmation that the other zones are entering the trouble state, but the keypad and panel might be shunting the notification of the actual trouble condition during the reset.
 
As far as the sheer volume of events hitting the CS, the first item to be wary of would be a POTS dialer, but the second is how much traffic is actually hitting the panel and the receiver. In the case of a panel, a lot of times that starts a flag as a system runaway, which may or may not end up having further actions at the CS. The fastest communicator is actually the cell (depending on how the data is ported to the CS) followed by the TCP/IP.
 
I don't like the idea that the CS is not reacting to troubles....that's how a local branch of a national company had a multi-million dollar house burn to the ground; The panel sent fire troubles (or the signals received as fire troubles due to poor templating actions) and then attempted to call the house. No answer, so they never dispatched the FD and only called the call list. Restorals should be used (via templating) to know whether or not the system returned back to normal condition or there is an event that is still latched (or point in alarm).

 

[Linwood]

Based on the log I can tell you're not using a reversing relay, so the extreme number scenario isn't going to come into play.

 
Correct.  I have sounders in each bedroom anyway and didn't see a need.
 

I can't comment as to what you're seeing or not seeing because of the variables in communications programming available on the M1 (restorals, troubles, etc.) Keep in mind, what you're seeing from Next is not accurate...you're only seeing the events as summed by their automation software, not the raw system data. Also, you're only dealing with a tech seeing the data on the automation end of the system, not the raw data....and does that tech know what they are looking at specifically or what is really involved with the panel besides the signals it is sending (my experience is they don't 90% of the time)

 
It was Alarm Relay and it was the setup guy; my impression was he was seeing everything as part of setting up, but not sure.
 
What I posted above was from the M1G's log not the CS log.
 
One problem I have with the M1G is I haven't found a way to see what it's sending to the CS.  Even connecting to the data from the M1XEP (which looks a lot like a log) doesn't appear to include what's communicated.   One thing I need to set up but haven't (I need to tie two switches' monitoring port together) is to see what it's sending on the IP monitoring.  That's easy but tedious and I just haven't.   So I could see for sure if it sent a trouble code.
 
They say they will call me for trouble.  New to them so I don't really know.  Once I get access I'll do some tests of different events and then ask them what they would do to each once I can see what code (if any) they actually get.
 
Again, I thank you for continuing what is obviously a tedious discussion, am learning a lot.

 

[pete_c]

Yup; here relating to the HAI OPII panel I configured what was being sent to the CS.  Knowing that on the other side (CS side) it was just raw data with no names or associations.  There I set up what was what such that the two were in sync.
 
To validate in "test" mode; I manually triggered something on the panel; watched the trigger on the CS side to confirm that I had configured the two sides in the fashion that I wanted. 
 
The CS setup guy just had me validate the steps and confirmed what I saw.  (day, night, emergency, other stuff...).  IE: I get an alert for a low battery on a sub panel and an email from CS regarding said issue type stuff.
 
Go in baby steps; leaving the panel / CS in test mode and do one thing / alert at a time; confirming each while watching the CS stuff via your internet connectivity account.

 

[Del91574]

In my particular case and daily business, I know what is going on on both sides of the fence and what is being sent and received and where the disconnect and summary data and automation software comes in....
 
I've had to deal with AR's "setup" personnel before (and explain to them the report codes and what was and was not possible and how to template an account). I can't knock them too much because they just don't know. Their end, because they deal with DIY and don't really go through the programming, from what I've seen, is they want you to send a point and restore it so they can build their template on the fly rather than go through the programming on panels they don't really know.
 
To see the raw data, really you need to know the comm's format and then decode it (it's doable but why really reinvent the wheel).
 
I'm still amazed they don't call on troubles. Normal SOP for a CS.
 
You should be able to verify what signals they're actually getting and then get the raw data from them, not just what the automation software is getting.
 
Ask them what receiver and config they're running and I can give you an idea of where they can get the data. It also makes a difference if it's a virtual or physical receiver and line cards and if they have a LEP connected (they should as a matter of CYA).
 
There are some formats that send all the data as programmed in the panel (zone text, qualifier, event, account, etc.) but those are pretty few in number.