Elk M1 Error

[Monk]

OK, so here is a copy paste of what my alarm company's log shows. My Elk called out, reported a module failure - restore - but the weird thing is, my zone one is NOT wired to an expansion module. It goes to the Elk itself.

Nov 25, 2009 09:59:05 PMExpansion Module Failure Restored Front Door (Zone 1)
Nov 25, 2009 09:59:04 PMExpansion Module Failure Front Door (Zone 1)


This occured after successfully arming the alarm, within a minute or so. Any ideas?

edit - the actual elk log below
13,Wed 11/25/2009,21:57,,1161 = EXPANSION MODULE RESTORE,Keypad 1
14,Wed 11/25/2009,21:57,,1141 = EXPANSION MODULE TROUBLE,Keypad 1
15,Wed 11/25/2009,21:56,1,1173 = AREA ARMED,"No Code" (User 203)

 

[pipeman]

The inputs and outputs on all keypads are seen as expansion 13, zones 193 thru 208.
Probably has something to do with that.

Check for loose wires maybe? Are the In and Out (blue & brown, I think) capped off?

 

[Spanky]

Look in keypad menu 8, under data bus errors and see if you can watch the count increase. If it is increasing every few seconds, you could have a data bus problem.

Check the log and see if the keypad has had a trouble before and what type of trouble the log states. The keypad processor may have reset.

 

[Monk]

Thanks guys - I didn't realize this was a keypad error until just now - the Nextalarm log threw me off. Should have looked at the Elk log first.

No - my unused wires are not taped, Im sure. will look @ that.
Will check the bus error count too.

 

[WayneW]

The NextAlarm log can be very misleading. I deliberately removed an XSP and received this from NextAlarm:
Expansion Module Failure: Overhead Garage Door
which happens to be my first "real" zone that gets reports to NextAlarm.

My Elk log shows:
1141 = EXPANSION MODULE TROUBLE Serial Exp 2

Spanky, is this a limitation of CID or does NextAlarm have some decoding issues?

 

[Spanky]

Wayne,
I bet your overhead garage door was zone 2. Nextalarm is getting confused with the expander number and the zone number, probably. I would think you could set up Nextalarm zone/troubles to work correctly.

 

[WayneW]

I bet your overhead garage door was zone 2. Nextalarm is getting confused with the expander number and the zone number, probably. I would think you could set up Nextalarm zone/troubles to work correctly.

Yes, my door was Zone 2. Unfortunately, ZoneAlarm gives NO control over the setup for system troubles. If fact, I have no idea how NextAlarm communicates a smoke sensor trouble compared to a water trouble compared to a power trouble. Digging into this is still on my to-do list, but I think the problems are on NextAlarm's side.

 

[WayneW]

warning... re-activating my old thread here, since the Elk forum is a ghost town.

NextAlarm doesn't seem to be handling system trouble reports totally correct.

my Elk log:
Thu 11/25/2010 13:42 -- Output Expander 2 Communications Restored
Thu 11/25/2010 13:41 -- Output Expander 2 Lost Communications
These are logged as events 1141 and 1161.

NextAlarm.com log:
Nov 25, 2010 01:43:06 PM Expansion Module Failure Restored Overhead Garage Door (Zone 2)
Nov 25, 2010 01:42:15 PM Expansion Module Failure Overhead Garage Door (Zone 2)
emails I received:
Expansion Module Failure: Overhead Garage Door E-Notify sent at 1:42 PM on Thu, Nov 25
Expansion Module Failure Restored: Overhead Garage Door E-Notify sent at 1:43 PM on Thu, Nov 25

The error was with expander #2, but NextAlarm is treating it as if it was ZONE #2. There is no reason for the garage door (aka zone #2) to be mentioned in the NextAlarm log or emails.

NextAlarm responded to my issue and stated that since the packet they receive mentions "zone 2", that is what they report to me. Does the Contact ID info sent REALLY specify ZONE 2? Or is NextAlarm ASSUMING that the #2 means a zone number instead of an expander module number? So is this an Elk issue, a NextAlarm issue, or a weakness in the CID protocol?

I don't see anyplace that I have any control over this, did I miss something?

 

[Del91574]

Without getting to the big argument of if you're using their ABN and it's inherent issues to communicate or using the digital communicator on the M1, here's a summary:

It's an issue with Nextalarm and their template they have setup for monitoring. I have multiple M1's and EZ8's out there and when there's a problem that pops up, the event code that is sent is correct with additional information following the CID event code. What Nextalarm's receiver's are summing in their automation software is taking the extended information that is following the event code (ZZZ below) and automatically seeing it as a burglary zone being transmitted rather than extended information being sent by the control, which comes down to their template they are using or their automation software...basically what I deem (being in the trade) sloppiness combined with possible untrained operators that aren't seeing the whole picture properly because of small errors with the template(s) and automation software combined....which leads to what you're seeing.

the CID format sent to the CS is this:

CCCC Q EEE GG ZZZ

CCCC=customer's acct. #

Q= qualifier (either an E=new event and R=restore)

GG=partition #, and system messages show a "00"

EEE=CID event code

ZZZ=zone or CID # reporting the alarm or user # in open/close. System status messages contain 0's in the ZZZ location.

Your panel is sending (I'm typing generically) a 1234 E 333 01 002 to them (account 1234, new event, expansion failure, part. 01, module 002) and the appropriate restorals that follow.

The best thing I've done with those extra wires (when unused) is to cut them off and use the chicklets that Elk sends along to cap them off permanently rather than tape (unprofessional and not permanent IMHO).

 

[SpecialJ]

OK, so here is a copy paste of what my alarm company's log shows. My Elk called out, reported a module failure - restore - but the weird thing is, my zone one is NOT wired to an expansion module. It goes to the Elk itself.

Nov 25, 2009 09:59:05 PMExpansion Module Failure Restored Front Door (Zone 1)
Nov 25, 2009 09:59:04 PMExpansion Module Failure Front Door (Zone 1)


This occured after successfully arming the alarm, within a minute or so. Any ideas?

edit - the actual elk log below
13,Wed 11/25/2009,21:57,,1161 = EXPANSION MODULE RESTORE,Keypad 1
14,Wed 11/25/2009,21:57,,1141 = EXPANSION MODULE TROUBLE,Keypad 1
15,Wed 11/25/2009,21:56,1,1173 = AREA ARMED,"No Code" (User 203)

 

[SpecialJ]

Hello CocoonTech!

 

[Del91574]

Read my post above, it'll show why you're getting what you're getting vs. the actual event compared to the log.

 

[WayneW]

I pinged NextAlarm and I requested that they research this issue.

As we certainly appreciate and understand your concern however the issue was addressed in December and there is still no other way for the event to be noted on your actual web interface thus the e-notification and alarm history will still reflect the definition you have currently have listed for Zone 2 (in respect to the recent Expansion Module Fail event).

Your panel is sending in an actual event for a Zone 2 - this will generate a match to what ever you have listed as Zone 2 along with the actual Contact ID of the event, in this case "Expansion Module" then the added information you input for Zone 2.

This is a Factory embedded it appears and nothing we do on our side.

We can suggest that if you have Multiple Expansion Modules that will report (Factory Default) an actual Zone Number coresponding to the Expansion Module such as Module 1 - Module 2 etc.. that you do not use any zone that is Factory embedded to report a condition of each Module.

For example if you have 3 Modules it appears the panels logic is to ID each one in sequential order 1,2,3 etc. so the zones that are associated with each Module would NOT be used as an actual Alarm reporting zone instead use an open zone for those current zones such as changing Zone 2 Burglary Alarm to one of your open zones.

That answer doesn't make sense to me. Is there a way to see/intercept the actual Contact ID data? Spanky, can you advise?

Anybody know anything similar to NextAlarm that accurately handles trouble reports?

 

[Del91574]

Are you using the digital communicator or their ABN?

You got the typical canned response by them. The issue is with their template and automation software, which would require time and effort on their part to correct, which in their response is they don't want to modify the template for their monitoring accounts and simply want the raw data that is transmitted in CID to pass straight through to their software irregardless of the actual additional data that is sent along with it.

The CID data is sent in the format I listed, that's straight from Ademco's mouth and all panels that use CID format will send the same information in that format, with the only difference being the extended data being sent with the CID data, which Nextalarm is summing as a burglary zone rather than extended data to the initial CID event code.

Truly, given their response it's them telling you to pound sand and "we're not going to customize anything for your application" right or wrong.

I'd recommend asking another central station about their templating of the account and automation software setup, but if you're looking for an end-user DIY solution, I can only think of Alarm Relay as the only other CS that'll deal with an end user.

 

[WayneW]

Are you using the digital communicator or their ABN?

Neither (if I understand correctly). I am using a VOIP line (presumably no ABN needed since all the "normal" messages work fine) and/or an Uplink AnyNet (with an Elk XSP, so it is CID) cellular.