Force Arm on EOL-Supervised Security Alert zone

As a relatively new owner of an Elk M1G system, I continue to discover features and behavior of the system that don't appear to be documented.

I noticed that when a zone with wiring type "3" (EOL Supervised with Security Alert on SHORT) or type "4" (EOL Supervised 4 State wiring with Security Alert on OPEN or SHORT) is programmed to be Force Armable, the Security Alert does not work.

For example, I have a motion detector with a tamper circuit wired as type 4 on a zone. In the disarmed state, when motion is detected, the alarm circuit opens and the keypad displays zone not ready. When I remove the cover of the detector or otherwise create a tamper condition, the tamper circuit opens and the keypad beeps with the Security Alert alarm. The event "1350 = Security (Day) Alert" is also logged. (In the armed state, either condition of course will create a burglary alarm.) This all works fine and as expected of this zone type.

However, because this particular motion detector covers an exit/entrance area with a keypad, I have set the zone to be definition 05 - Burglar Interior Follower and Force Armable. This would allow me to pass through this area and arm away while the motion detector sees me, and re-enter this area to disarm without causing a false alarm. Now when the zone is set to force armable, the Security Alert feature does not function when the tamper circuit is tripped; the keypad only displays the zone trouble, and no security alert event is recorded in the log. Furthermore, because this zone is now reporting "trouble" rather than not ready, the system will refuse to arm even though the zone is programmed to be "force armable." (Here I concur with the system not allowing any zone reporting trouble to be overlooked. But why doesn't the Security Alert function?) The manual doesn't seem to document this behavior or effect of force arm on an EOL Supervised Security Alert zone, and I wonder if anyone else is experiencing this too.

Separately, I also notice that when I un-check "Force armable" for a zone in ElkRP (v 2.0.8) and send the change to the control (v 5.2.4), the change does not seem to register, and I must reboot the whole system for the removal of force arm to take effect. Anyone notice this as well?

That zone wiring type is really an uncommon application IMHO, even after me doing the last 8 weeks doing security for an AFB and the DOD security.

If I'm understanding what you're attempting to accomplish:

You're going to need to modify your wiring of the PIR to a NO circuit with the tamper in series and a jumper wire connecting the pole of the relay and the resistor being a jumper from the other side of the tamper back to the PIR's relay. It's unclear how you have your EOLR and tamper wired to the zone by your post.

What is going to happen is the panel is going to respond to a short as an alarm, an open (tamper) as an trouble, and doing it this way allows the panel to see each state based on the tamper being a NC circut and the PIR as a NO circuit, basically for all intents and purposes, it's like wiring a fire alarm circuit. A tamper condition will remove the EOLR from the circuit and the PIR's relay will provide the short. Can't have your cake and eat it also by using 2 NC circuits in series, you need a way to provide both alarm states, open and short.

A type 3 wire application would be difficult to implement a tamper loop into, unless the tamper is a NO circuit, which is uncommon.

If your PIR does not have both poles for the relay, then you're stuck with traditional NC/EOL wiring and unable to really use that wiring configuration with your particular setup if you want to monitor the tamper on the same circuit with no additional wiring.

Without me opening a new panel and PIR to test the exact response, that should get you on track.

I still suspect electing the "Force Armable" option on a zone wired with EOL supervision for multi-state detection is doing something funny to the Security Alert reporting.

Currently the way I have the motion detector wired is as follows:

There are 4 terminals involved:
Z1 & Z2 - the alarm contacts - normally closed when zone is secure
T1 & T2 - the tamper contacts - normally closed when device is secure
(There are no options to wire normally open for either circuit.)

M1G Zone+ to Z1
2.2k resistor#1 between Z1 and Z2
2.2k resistor#2 between Z2 and T1
M1G Zone- to T2
(As per the 4-state zone wiring diagram on page 9 of the M1G install manual.)

WIthout setting Force Armable for this zone, everything works fine:
When nothing is violated, the zone reports ready (~7.3 volts).
When the alarm circuit becomes not secure (Z1 & Z2 relay opens), the zone reports not ready (~9.5 volts).
When the tamper becomes not secure (T1 & T2 relay opens), the zone reports Security Alert (13.8 volts).

As soon as I change the zone programming to Force Armable, Security Alert no longer reports when the tamper becomes not secure.

The only work-around that I can think of is to put the alarm and tamper on their own separate zones.
The alarm zone would then be wired as:
M1G Zone1+ to 2.2k resistor#1 to Z1
M1G Zone- to Z2
Type "0" EOL supervised, and Force Armable.

The tamper zone would be wired as:
M1G Zone2+ to 2.2k resistor#2 to T1
M1G Zone- to T2
Type "4" EOL supervised with Security Alert on OPEN or SHORT, and NOT Force Armable.

But this separation defeats the purpose of having multi-state detection on one zone, in addition to using another zone and running an additional conductor.

Perhaps you should contact Elk tech support directly with this issue. If this is the way a Type 4 circuit misbehaves when it is set to Interior Follower and Force Armable, maybe it can be corrected with a firmware update. If not, it seems to me the limitations of a Type 4 circuit need to be explained more thoroughly on page 9 in the manual. For example, if a PIR requires an additional wire pair for the tamper circuit in order to behave correctly, then it would be nice to know BEFORE doing the prewire.

Just realized I had an older revision PDF when I was referencing the wiring. This is a standard DEOL circuit. The force arming is the problem.


Is the PIR truly able to be tampered with, IE:commercial or high security application? What make/model is it?

If you're dead set on running a tamper loop, you really wouldn't need to run more cable to the detector, just use the common negative for your two zones.

I am having exactly the same experience.  I was on 5.2.2.  In my system, it would Force Arm even when the sensor was in the Trouble state.
 
Frankly I'm surprised more security people don't use this wiring setup.  It only takes a few seconds more to wire it this way and Elk provides plenty of 2.2K resistors.  I know the NC switches detect most wiring anomalies, but the 4 state wiring option detects all possible failures.  Maybe its because the control does such a poor job of dealing with it.
 
I haven't finished my research, but when I pulled the cover on my motion, the Elk reported the zone as Violated and raised a Security (DAY) alert.  Once the alert was silenced (*) and acknowledged (code) the Elk started reporting the zone as Trouble, but it didn't send a zone change report out the RS-232 port.  Very frustrating.
 
Did you ever send this to Elk?  I have upgraded to 5.3, and the problem seems to persist (though I haven't finished retesting every case).
 
--Bob

Not to argue, but the panel is doing exactly what it's programmed to do, force arm, which is bypassing ANY system zone fault programmed with that attribute. The trouble should be annunciated, and in the case of force arming, you are essentially acknowledging the trouble condition (annunciated at the keypad) and arming the system.
 
4 state supervision is nice, but it complicates the location of the EOLR and series cabling.
 
The DAY alert is the same as a TROUBLE as far as the system is concerned, the condition of the loop does not change, no matter how much you wish it to, the only item that changes is the system modifies the nomenclature because you silenced and acknowledged the condition (from alert to an active trouble condition).

Not what you want to hear, but not a fault of the system or the panel not performing as intended or designed. As far as handling, not to sound crass, but I deal with more complex access control panels with DEOLR's and they perform the same way unless you specifically designate a different system action based on the initial event and subsequent change in alarm point indication from unacknowledged to acknowledged, otherwise the loop state is exactly the same, nothing changed besides an end user action.

Well I only mentioned the force arm bypassing a troubled sensor because sixspeedmanual said his system was *not* force arm bypassing the troubled zone.  I really don't care which it does as long as the panel shows the true state of the sensor.
 
These four issues appear to be true Elk Panel Bugs:
 
Changing a supervised zone from Force Armable to Not Force Armable does not take effect until you reboot the control.  Changing Zone Type also had other stange effects until rebooting the control.
 
Elk does not issue a Security (DAY) Alert if a Force Armable zone goes into the Trouble state.  Even though it is force armable, I want to know right away if my sensor has trouble.
 
Elk reports the zone Violated instead of Trouble until the Security (DAY) Alert is acknowledged
 
Elk doesn't send a proper Zone Change (zc) report over the serial interface after the alert is acknowledged and the zone moves into the Trouble state.
 
(the last two and maybe three could be due to not rebooting the control after having made zone definition changes)  --Bob

I can't say I've mirrored your experiences, all zone changes and attributes have always been correct after system changes and not required after system changes.
 
The DAY alert IS the trouble condition, which the system is reporting as it actually happens. Once it's acknowledged, it turns from an ALERT to a TROUBLE, meaning the state did not change, only acknowledgement by an end user. It can be argued that the FA attribute should not allow arming while an ALERT/TROUBLE condition is present, the issue is always going to arise (in the real world) that arming a system with one or more trouble is going to be necessary, and the system will protest and annunciate the trouble when arming the system, and in the case of DEOL zones, if the ALERT condition (if clear) IS going to generate an alarm if it either opens or shorts. FA is always going to shunt zone states, it's the nature of FA in general and not unique to Elk.
 
In your example, the zone never changes state! The only thing that is modified is the ALERT is changed via nomenclature to TROUBLE because it's acknowledged but the condition is latched in and unrestored. The ALERT is sent over whatever reporting method, so in honesty, the nomenclature to TROUBLE would be a redundant signal reporting the same thing (less the acknowledgement by an informed party via entering a code) a restoral of the ALERT/TROUBLE condition IS reported and in the case of monitoring, if the report code is enabled, it will also be reported dynamically.
 
The feature works on the M1 just like a FACP with signal silence and acknowledge, which is a standard that remains constant in the industry....not a bug IMHO, just does not work how you want it to in your particular application.

Yeah the whole reboot required thing is very odd.
 
I have also experienced STAY mode ENTRY/EXIT alarms recently (after changing 5 motion detectors to 4-state wiring).  Last night, I shut off my stereo which automatically unbypasses two glassbreak sensors and it caused the alarm to go into ENTRY/EXIT timeout.  Strange.  I also had an office glassbreak go into alarm after motion in a nearby playroom.  I powered cycled all my glassbreak sensors so if it happens again I can use the clap-test alarm memory feature to see if it really did go into alarm or just the control is acting out because of the new 4-state wiring stuff.
 
I think you misunderstand my trouble troubles.  I am using the RS-232 interface to link my Elk to my CQC Home Automation System.  The Elk is supposed to send a Zone Change message whenever the zone changes status.  When the zone goes into trouble, the RS-232 sends a Violated ZC message.  Then the user acknowledges the ALERT, the zone becomes in Trouble but the ZC message is not sent and my HA system gets out of sync with the Elk.
 
The other thing which is bothering me is the threshold voltages for the 4-state zones:
Diagnostic table from Rev J of the M1 Installation Manual Pg9:

• Short 0 - 3.9V   Trouble
• 2.2K  4.0 - 7.3V   Ready
• 4.4K 7.4 - 11V   Not Ready
• Open 11.1 - 13.8V   Trouble

The 3-state Zone wiring has

• Short 0 - 3.9V Not Ready
• 2.2K 4.0 - 8.8V Ready
• Open 8.9V - 13.8V Not Ready

My calculations suggest 2.2K will produce 6.9V.  Evidence from ElkRP real-time status show most of my sensors at 7.3V.  Fine for the 3-state zone, but right on the edge for 4-state zones.  It seems that 1.5K would be a better choice.  For the Not Ready state 4.4K should produce 9.2.  My real-time readings are 9.5 which is nicely in the middle of the range.
 
Hmmm, I can't decide whether to change resistors or just abandon the whole 4-state wiring experiment.
 
--Bob

I'm not misunderstanding your troubles (or system troubles) pun not intended. The issue you are having is your 3rd party device or connection. Tell CQC to fix their driver and interface. The issue is not with the M1 or how it's reporting or not reporting. The zone violation is not cleared after the acknowledgement.
 
I would investigate your devices and wiring, it sounds like the relays/switches on your devices have a significant resistance....in the case of GE/ex-Sentrol designed devices, the relays have up to 35 ohms of resistance when in their normal state. It sounds more like you have voltage drop in the field devices. I would take a DEOLR and wire to the panel to see if the voltages fall within spec first.
 
I would not change the resistor values, you are asking for trouble. If anything, obtain a tighter tolerance resistor.

CQC just reports what the Elk tells it. I'm not fully following the discussion, but if the Elk changes the status of a zone, it is supposed to report it, end of story. That's not a problem with CQC if the Elk is not reporting changes.
 
CQC, at least the latest V2 driver, basically looks at it like this:
 
1. Zone is secure, it reports secure.
2. Zone is not secure and its area is not in alarm, the zone is reported as not ready
3. Zone is not secure and its area is in alarm state, it's reported as violated
 
So, If the alarm state of the Elk changes, then the zone status of any non-secure zone will also change. The Elk really only reports normal or violated for zones. CQC makes up the separate not-ready vs. violated statuses by combining the status of the zone and the alarm state of the containing area.
 
Not sure if that's relevant to this discussion, but just to make it clear what's going on on our end. If that's not what you are seeing, then there may be an issue with the driver. I'll take a look at it as well. The V2 driver is an almost full rewrite of the driver, so it's always possible that there's a wee issue there.

Dean,
Based on what Rbroders is reporting it sounds like a bug in the driver is not seeing the state from what the M1 is sending across. More specifically, there is more than the 3 states being reported to the driver, of which there are only 2 states your driver sees, secure and violated, with the system arm state affecting whether or not the zone is in alarm or not. That is how it appears your driver sees the information.
 
On a 4 state zone, your driver should see 3 states; secure, violated and trouble, which the poster is stating comes across as ZC violated to CQC but not changing state otherwise. Again, the alarm conditional is the same as above.
 
My guess is you have a conditional within your software that is only based off 3 state wiring and not 4 state and are missing the data with the CQC driver. The Elk most definately reports the trouble as I have tested such with a XSP and also via some 3rd party hardware to communicate to a CS.
 

Hi Dean, didn't know you troll this forum as well!  Actually, I am using the Dev version of the V1 driver which I pretty much own having made significant code changes to it.  I think you are considering the ZoneAlarm events and I am more interested in simple Zone Status (PhysZone for V1 drivers) which should be Normal, Trouble, Violated, Bypassed, or Unknown.
 
It seemed the Elk was not sending the ZC message in some cases, but it didn't reproduce in my last test.
 
Elk has some serious problems with 4-state wiring though and I'm going to have to undo my wiring changes and send a support request to Elk to see if they can fix it.
 
I think the interesting thing to note DELInstallations is that the diagnostic table of expected voltages for 2.2K resistance is different for 3-state wiring and 4-state wiring.  That really doesn't make sense.
 
Last night I proved the 4-state wiring is seriously screwed up:
With the system armed in STAY mode, Z38 Play Room Motion a Burglar Interior zone with 4-state wiring was triggered (by me walking through the room).
This caused Z125 Karen Office GBK a Burglar Entry/Exit 2 zone with NC wiring to also trigger which set off the alarm.
The proof in this case is that the Karen Office GBK device has an indicator which shows that is has never triggered.
 
I don't know what kind of internal Elk firmware bug causes one 4-state zone triggering to sometimes drive another zone to trigger, but it makes 4-state wiring pretty useless...
 
--Bob

Hi Dean, didn't know you troll this forum as well!  Actually, I am using the Dev version of the V1 driver which I pretty much own having made significant code changes to it.  I think you are considering the ZoneAlarm events and I am more interested in simple Zone Status (PhysZone for V1 drivers) which should be Normal, Trouble, Violated, Bypassed, or Unknown.
 
It seemed the Elk was not sending the ZC message in some cases, but it didn't reproduce in my last test.
 
Elk has some serious problems with 4-state wiring though and I'm going to have to undo my wiring changes and send a support request to Elk to see if they can fix it.
 
I think the interesting thing to note DELInstallations is that the diagnostic table of expected voltages for 2.2K resistance is different for 3-state wiring and 4-state wiring.  That really doesn't make sense.
 
Last night I proved the 4-state wiring is seriously screwed up:
With the system armed in STAY mode, Z38 Play Room Motion a Burglar Interior zone with 4-state wiring was triggered (by me walking through the room).
This caused Z125 Karen Office GBK a Burglar Entry/Exit 2 zone with NC wiring to also trigger which set off the alarm.
The proof in this case is that the Karen Office GBK device has an indicator which shows that is has never triggered.
 
I don't know what kind of internal Elk firmware bug causes one 4-state zone triggering to sometimes drive another zone to trigger, but it makes 4-state wiring pretty useless...
 
--Bob