Force Arm on EOL-Supervised Security Alert zone

[Del91574]

Rbroders,

Again, there is not a bug with the Elk in this case. I'm tired of pointing out all the reasons why when you refuse to listen.
 
For this discussion, I put all the basic DEOLR programming into my bench system and have yet to duplicate anything that could be considered a bug. I believe you are barking up the wrong tree and should start to consider your media and devices connected to the system and put a DMM on them. The multiple zone fault/false issue is a classic indication of a ground fault. You can rule out the device, but you can't rule out your cabling or connections.
 
For voltage values, the table is correct. The voltage drops vary based on 3 different values in addition to a short (0V). Either you have 0, 1.1K, 2.2K or 4.4K worth of resistance on the base 7V the panel is pushing out. The ranges they provide show values that are not a pure "open" or a pure "closed" condition, they show values that can be a high resistance or low resistance fault among other things. I can't explain VD and unequal resistances in a series/parallel circuit to you, that you're going to need to do your own homework on....which would lead a tech to suspect the series/parallel circuits that are connected to your system.
 
If you really want to see, I'll have to expose my demo system to the WWW, but the issues aren't there on it.
 
Let's start breaking out the system and post up a BOM and connected devices to start to see where to start, but the M1 isn't the culprit here.
 
I would suggest you consider ground loops and ground faults, as DEOLR is NOT tolerant of any of these conditions and the voltages you are posting are out of whack with what I am seeing on my bench system, even when you toss a loop resistance of 5-10 ohms (VERY high for a NC loop and cable).

 

[rbroders]

I'm glad it is working on your test system.  My guess is there is a data corruption somewhere (possibly on the RS-485) bus which caused Z125 to trigger when Z38 was triggered.  Likely it would not happen on a bench system with only one or two sensors as the Elk would reject data not pertaining to a legit sensor number.
 
I wonder if *you* understand the basic electrical premise of the Elk system.  The panel doesn't "push out" 7V.  Rather it has a 2.2K Pullup resistor connected to +13.8V.  The 4-state wiring provides either 2.2K or 4.4K of resistance to the panel ground.  The Elk then uses a DAC to digitize the voltage produced by this resistor ladder.  It is extremely unlikely that noise or a ground loop is causing Z125 to go from 19mV to whatever threshold Elk uses for NC zones (7V?).
 
My system has 4 Keypads + 4 Arming Stations, 190 hardwired zones +2 attached to keypads.  I have dozens of smokes, motions, glassbreaks, water, floor pressure, beams, door and lock sensors.  The system has been 100% reliable until I modified 5 motions to use the 4-state wiring.
 
--Bob
 
P.S.  I reproduced the RS-232 ZC problem.  Apparently when a zone goes into trouble this generates a full alarm (no siren only keypad beeping).  The system sends an AS message with alarm state code 'U' (which is not documented).  Star silences the beeping but the alarm isn't acknowledged until you enter a code.  Meanwhile the system is in Alarm, and the zone is Violated for the purpose of the alarm, which makes sense.  However, when you acknowledge the alarm, the zone changes to its true Trouble state, but a ZC message is never sent for this change.  Clearly a bug, but I can work around it by requesting a Zone Status Report when the alarm status changes.

 

[Dean Roddey]

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.

 
It does see Trouble, but doesn't report it as a separate state. It reports that as 'Unknown'. The V2 driver interfaces have to be generic so that they can work across many devices, so it defines standard zone states that it will report, and anything else is reports as Unknown.
 
If it would be more appropriate it could treat trouble as violated as well, for purposes of reporting zone status, and I'm happy to make that change if it would be better.

 

[Del91574]

Bob,
 
Without getting into specifics, I am friends with Wade Moose and my experience with him goes back to when they were refining the Z1100. I am very familar with the engineers that designed the M1 as the next step from the old Z1100E's. Been in the industry for years and also very well versed in the panel, it's lineage and design. Yes, I realize my "error" in simplifying the voltage of the M1....yes, it pushes out the voltage which is put across the supervising resistors to coorelate to the voltage ranges the M1 uses to determine the state of the zone. Forgive my error as simplification.
 
My bench M1 is a fully loaded and maxed out M1 mounted to a test board. Elk offer(ed) at the time a significant discount to any dealer purchasing an M1 as a demo system, so that is when I purchased my home M1 along with my bench unit...back when Elk had 2 M1's and before the EZ8 came to market. I have been literally using and installing Elk's since they first came to market.
 
I have had the bench system up and running on a board for years. I have the test board with multiple toggle switches to generate all valid system conditions for testing purposes (thanks to Flair electronics for the board and annunciator panels). When running a full blown system with automation, it is very prudent for an integrator to have a system that can handle the entire system program you can throw at it for testing purposes. I have every M1 catalog piece mounted on the board and running and 15 KP's (for all intents and purposes, some 212's, KAM's, KPAS, TS07, etc.) running on the panel and can interface with any technology or 3rd party control out there for testing.
 
From dealing with 4 state wiring daily, and troubleshooting it, I'm sure you're aware that a zone that functions properly on a 3 state zone can experience significant issues on a 4 state zone supervision. Ground faults are very common occurances on larger systems, especially when cabling runs outside or to other buildings or is stapled to wood framing.
 
I already told you how the zone works as the system sees it and how it's reported about 6-8 posts ago, * is acknowleging the condition (albeit silencing) however the system requires a code to clear, which is NOT a bug, the M1 does not send what you want it to at a specific point in time for your particular application.
 
The ASCII protocol is sending the alarm status with the message, while the system is not actually in alarm condition, it is a violation state, just like a trouble day/alarm night point on other systems. The zone NEVER changes electrically from a violated state to trouble, so the system can't report a condition that does not exist ! The point NEVER physically changes, only the annunciating text on the keypad. The systems DOES report, correctly, the open or short state of the 4 state wiring. Look at the AZ information....it'll never be a trouble. I think what you want is your specific 4 state change to institute a modified ZT and ZS to trigger your automation software.
 
You are asking the M1 to report a false zone and system state to your 3rd party device, which it won't do. What you want is a specific system operand to drive an ascii message to be sent in your specific case, none of which is a bug or error....so either you tell Elk you want a custom FW to send this in the protocol based on items you specify for your application or you find your own workaround which may or may not perform (again) as you wish. Can't reinvent what isn't there.
 
I've had them write a firmware before (back in the early days and their RF support didn't handle the ITI/GE wireless holdup/billtrap type units).
 
Good day sir.

 

[rbroders]

Well I doubt they'll write a new firmware for me.  Maybe I can explain the bug more clearly so you can understand at least:
 
System is not armed.  Motion detector cover removed, tamper switch opens zone goes to 13.8V Open
 
ZC message is sent: Open, Violated
System goes into SECURITY ALERT alarm, panels beep but no siren
AS message is sent using undocumented Alarm State 'U'
Pressing * on panel silences beep but otherwise does nothing.
Zone Status on Panels shows Violated, ElkRP shows Violated, full ZS report shows Violated as well.
  -- so far, so good, though a bit odd, perhaps --
 
Entering a valid code on the panel Acknowledges the alarm.
AS message is sent indicating no alarm active
Zone Status on Panels now shows Trouble, ElkRP shows Trouble and full ZS report shows Trouble as well.
The logical status of the zone has changed from Violated to Trouble but NO ZC MESSAGE was sent.  This is a bug.  You are supposed to be able to track the state of a zone simply by watching ZC messages go by but you cannot because of this bug.
 
I'm not asking them to send false zone or system states.  I just want them to send ZC messages every time a zone's logical or physical state changes.
 
--Bob
 
P.S. For 4-state zones the physical state of the zone is either Short, EOL, DEOL, or Open, but the protocol can't even send DEOL!
 
P.P.S  I converted Z38 back to NC wiring and I still had a false alarm on Z125 when a different motion detector triggered (Z93 also NC).  Z125's 19mV reading implies only 3ohms for sensor wiring + relay contacts so it seems okay.  As a further test I installed a shunt across the zone.  Now I get a false on Z126 - not preceeded by a motion trigger this time (I don't think).

 

[Dean Roddey]

Sounds like a legitimate goober to me.

 

[rbroders]

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

 
After weeks of debugging it turns out that 4-state wiring has nothing to do with the false alarms I was getting with my system.  I reverted the 4-state wiring and still received false alarms.  Going back to 5.2.10 solved the problem.  There is some nasty bug in 5.3.  I strongly recommend not using Elk Firmware 5.3!
 
--Bob

 

[lathiat]

I had similar issues with the multi-state zone wiring when I was testing a few months ago, so it's not just you OP
 
 
Generally it seems the state of the trouble alert can get lost in multiple cases, most notably if you trigger the zone and the tamper at the same time (when not armed), the m1 will not alert the trouble condition once the zone is secure again.  I also found it would not alert on the condition during startup.  Same as OP, issues with it not being reported on the RS232 bus which I am relying on heavily.
 
 
I've just got the system installed now so I will be testing this again to determine what I plan to do.  Generally I was hoping to avoid running separate tamper zones on everything, but these couple "quirks" in the way it seems to handle it seemed like they were going to be a bit non ideal.
 
I'll report back once I've sussed it again more precisely.