Elk M1 and AlarmRelay Monitoring Via M1XEP

U

ultrajones

Active Member
I recently signed up for AlarmRelay monitoring though my Elk M1XEP module. I have received several calls from AlarmRelay stating my Alarm has lost COM, but I don't know what that means. In my logs, I show several Elk M1 ETHERNET TROUBLE events. However, those events are nowhere near the times when the alarm company has called me. I have the latest Elk M1 firmware installed. Anyone have any ideas what is going on here?

Regards,
Ultrajones
 
It could be that Alarm Relay is trying to ping you every so often to verify the connection. If this is the case, maybe your router is not set up to allow ping acknowledge.
 
UL and NFPA (under other technologies) require the central station to know within 200 seconds if there is a loss of communication (if I remember correctly). If I am correct they are probably polling every 90 seconds or so (in case they miss once) and if they miss twice in a row they would generate the trouble.

Alarm Relay should be able to help you with this. The central station should log the interruption and restoral times as required by UL and NFPA.

I have had this with NextAlarm maybe once every year or two with the ABN.
 
After updating the firmware on both the Elk M1 and M1XEP (as required for the AlarmRelay monitoring) I started to get a lot of messages like this written to my logs:

05/26/2011 21:41 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, May 26, 2011 at 9:41:00 PM
05/26/2011 21:42 1 100 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, May 26, 2011 at 9:42:00 PM

What is interesting about this error is it only written to the logs when the restore occurs. I had my home network isolated from the Internet for over 1.5 hours and my Elk M1 reported an Ethernet trouble and restore when the connection was actually restored. AlarmRelay didn't call me until after I reconnected the network!

I get at least 1 call a day from AlarmRelay reporting various communications errors (many of which they cannot even explain). I even had a troubleshooting session with the AlarmRelay tech. He had to escalate the issue as he wasn’t able to explain the cause of the communication errors. He did state they only had a handful of customers using the Elk M1EXP.

I am starting to regret my decision to use AlarmRelay with the Elk M1XEP.
 
I have the same problem, with the disconnects and restores. I know it is not my internet connection, I have a high speed fios line that I can VPN in to my office and leave up for days. I ented up adding a rules that triggers an annoucmenet so i could get an idea of how many disconnects there were each day.

Anyone have any luck getting info out of alarmrelay.
 
personalt said:
I have the same problem, with the disconnects and restores. I know it is not my internet connection, I have a high speed fios line that I can VPN in to my office and leave up for days. I ented up adding a rules that triggers an annoucmenet so i could get an idea of how many disconnects there were each day.

Anyone have any luck getting info out of alarmrelay.
Click to expand...

I have completely lost connection to AlarmRelay since early this afternoon. I see the Elk M1EXP sending the UDP packet, but I am no longer seeing a reply from AlarmRelay. I just noticed the IP address they had me configured for alarm reporting is also their primary SMTP server.

$ dig @127.0.0.1 ptr -x 70.167.0.226

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 ptr -x 70.167.0.226
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;226.0.167.70.in-addr.arpa. IN PTR

;; ANSWER SECTION:
226.0.167.70.in-addr.arpa. 86400 IN PTR smtp.watchlight.com.

$ telnet 70.167.0.226 25
Trying 70.167.0.226...
Connected to smtp.watchlight.com (70.167.0.226).
Escape character is '^]'.
220 smtp.watchlight.com ESMTP (ea27d660d6f61bffc9209e9862ed8e31)

I see the UDP packets leaving my network, but their system is no longer acknowledging them.

Anyone else experiencing an issue with their Elk M1EXP connection with AlarmRelay?
 
I've been with AlarmRelay for 5 months and on ethernet monitoring for 3. Just now I started to have "ethernet trouble" daily. If it is true that AlarmRelay pings the m1xep, what ports do I need to forward to the m1xep in my router? I always thought the m1xep does the periodic pinging.

I can access the virtual keypad from outside so I know that port is forwarded properly to the m1xep.

As secondary reporting I have a Hai C3 with a t-mobile prepaid sim.
 
Have you called Alarmrelay to ask them what the check-in schedule is and if they have been getting them. Ethernet trouble is not a very specific trouble code.

Also, your backup of the C3 and alarmrelay may not be a good combo. Another person posted that alarmrelay was failing to communicate using the c3/tmobile. He switched to watchlight monitoring and at last report was working fine. I have used c3/att and watchlight for about 14 months now without a single failure and it is my only comm.

While I have an xep unit and could do IP reporting if I wanted, I use the C3 unit only. I don't see any point as it is far more reliable than internet and much simpler. No worries about routers, modems, ISP outages, wire damage, power failures, ip address changes, and so forth. Furthermore it is cheap. Watchlight is like $9/mo and the prepaid card costs about $8/mo.
 
Lou Apo said:
Also, your backup of the C3 and alarmrelay may not be a good combo. Another person posted that alarmrelay was failing to communicate using the c3/tmobile. He switched to watchlight monitoring and at last report was working fine. I have used c3/att and watchlight for about 14 months now without a single failure and it is my only comm.
Click to expand...

I thought AlarmRelay and Watchlight were the same company, at least in some aspect?
They have the same address:
http://www.watchlight.com/company-profile/
http://www.alarmrelay.com/contact-us/

I noticed in ultrajones post that his logs of testing with AlarmRelay enumerated to watchlight.com?
 
Lou Apo said:
Have you called Alarmrelay to ask them what the check-in schedule is and if they have been getting them. Ethernet trouble is not a very specific trouble code.

------------------------------------
This is an important point. The CS does NOT ping the IP alarm transmitter. It is actually the IP alarm transmitter (in this case the XEP) that must be set to PING the CS receiver for supervisory. Then it's up to the CS to set an expected supervisory check-in schedule. It is the responsibility of the CS to determine if/when the IP transmitter has missed sufficient times to warrant a failure. Like Lou has said, you need to ask the CS what their check-in schedule is expecting. They should also have a limit set on the number of missed pings before a trouble is created. And the time interval for the IP alarm transmitter supervisory pings needs to be set according to what the CS recommends and is willing to accept. ---------------------------------
Click to expand...
 
Root cause: AlarmRelay (aka Watchlight) made some changes to their Internet system and forgot to allow UDP port 3601. The issue was resolved as of 06/23/2011 11:57 EDT.

The Elk M1XEP will send up to 4 UDP packets to the central station IP address at the start of the heartbeat internal. Their system sends a UDP acknowledgment from 3601 to the UDP source port. When things are working correctly, the Elk M1 sends 1 UDP packet and the AlaryRelay system sends 1 UDP reply.

I noticed the following issues with Elk M1XEP and AlarmRelay monitoring:

  1. I switched to Internet monitoring because they stated they would notify me if my system no longer responded to a heartbeat interval. This is not the case. Alarm relay does not call you if your Internet connection drops and your system no longer reports. They will only call you once the connection is restored. Don’t believe me? Simply disconnection your Internet for a few hours. You won’t get called until you plug it back in :)
  2. Though this entire outage, the Elk M1EXP indicated an Ethernet failure/restoral over and over again. There should have only been one failure and one restoral as their system *never* replied to any of the UDP heartbeat packets.

Note: I was capturing packets for the duration of the outage and never saw a response until the issue was resolved at 06/23/2011 11:57 AM EDT. However, the Elk M1 indicated over and over again that an Ethernet restoral occurred.

Code: 
[...]
06/23/2011 09:57 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 9:57:00 AM 
06/23/2011 09:59 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 9:59:00 AM 
06/23/2011 10:12 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 10:12:00 AM 
06/23/2011 10:14 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 10:14:00 AM 
06/23/2011 10:27 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 10:27:00 AM 
06/23/2011 10:29 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 10:29:00 AM 
06/23/2011 10:42 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 10:42:00 AM 
06/23/2011 10:44 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 10:44:00 AM 
06/23/2011 10:57 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 10:57:00 AM 
06/23/2011 10:59 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 10:59:00 AM 
06/23/2011 11:12 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 11:12:00 AM 
06/23/2011 11:14 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 11:14:00 AM 
06/23/2011 11:27 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 11:27:00 AM 
06/23/2011 11:29 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 11:29:00 AM 
06/23/2011 11:42 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 11:42:00 AM 
06/23/2011 11:44 1 100 1383 ETHERNET TROUBLE Ethernet trouble was reported on Thursday, June 23, 2011 at 11:44:00 AM 
06/23/2011 11:57 1 009 1384 ETHERNET RESTORE Ethernet restore was reported on Thursday, June 23, 2011 at 11:57:00 AM

Code: 
[...]
11:55:27 AM 6/23/2011  23.6516585  192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 18797, DstPort = 3061, Length = 40         {UDP:21, IPv4:42}
11:55:29 AM 6/23/2011  25.6521102  192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 19054, DstPort = 3061, Length = 40         {UDP:22, IPv4:42}
11:55:31 AM 6/23/2011  27.6525866  192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 19311, DstPort = 3061, Length = 40         {UDP:23, IPv4:42}
11:55:33 AM 6/23/2011  29.6530303  192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 19568, DstPort = 3061, Length = 40         {UDP:24, IPv4:42}
11:57:03 AM 6/23/2011  119.6827439 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 19825, DstPort = 3061, Length = 40         {UDP:43, IPv4:42}
11:57:05 AM 6/23/2011  121.6830359 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 20082, DstPort = 3061, Length = 40         {UDP:59, IPv4:42}
11:57:07 AM 6/23/2011  123.6833677 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 20339, DstPort = 3061, Length = 40         {UDP:70, IPv4:42}
11:57:09 AM 6/23/2011  125.6841194 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 20596, DstPort = 3061, Length = 40         {UDP:72, IPv4:42}
11:57:09 AM 6/23/2011  125.7624946 70.167.0.226        192.168.2.x        UDP       UDP:SrcPort = 3061, DstPort = 20596, Length = 40         {UDP:72, IPv4:42}
11:59:09 AM 6/23/2011  245.7998683 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 20853, DstPort = 3061, Length = 40         {UDP:126, IPv4:42}
11:59:09 AM 6/23/2011  245.8785674 70.167.0.226        192.168.2.x        UDP       UDP:SrcPort = 3061, DstPort = 20853, Length = 40         {UDP:126, IPv4:42}
12:01:09 PM 6/23/2011  365.9052814 192.168.2.x         70.167.0.226       UDP       UDP:SrcPort = 21110, DstPort = 3061, Length = 40         {UDP:140, IPv4:42}
12:01:09 PM 6/23/2011  365.9827174 70.167.0.226        192.168.2.x        UDP       UDP:SrcPort = 3061, DstPort = 21110, Length = 40         {UDP:140, IPv4:42}

Regards,
Ultrajones
 
WayneW said:
I thought AlarmRelay and Watchlight were the same company, at least in some aspect?
They have the same address:
http://www.watchlight.com/company-profile/
http://www.alarmrelay.com/contact-us/

I noticed in ultrajones post that his logs of testing with AlarmRelay enumerated to watchlight.com?
Click to expand...

My Bad. It was Next Alarm that the other poster had trouble with. Sorry for any confusion.

The part about just using the C3 unit by itself still holds, however. It has never failed me and sadly we do accidentally set it off at least a few times per month.

http://www.cocoontech.com/forums/index.php?showtopic=17145&st=0&p=157864&fromsearch=1&#entry157864
 
Alarm Relay and Elk still has not been able to resolve any of the issues I reported.

9/23/2011 12:35:44 AM UltraCID Info New incoming call detected ...
9/23/2011 12:35:45 AM UltraCID Info Incoming call from WATCHLIGHT CORP (619) 442-9595
9/23/2011 12:35:45 AM TTS Speak ():Incoming call from Watchlight Corp
9/23/2011 12:35:46 AM Event Event Trigger "Incoming Call Notification"
9/23/2011 12:35:46 AM UltraSMTP Info E-mail Queue Id 000631 to xxx queued for delivery.
9/23/2011 12:35:47 AM UltraSMTP Info E-mail Queue Id 000631 successfully delivered to xxx.
9/23/2011 12:35:50 AM UltraCID Info Ring of existing call detected ...
9/23/2011 12:35:56 AM UltraCID Info Ring of existing call detected ...
9/23/2011 12:36:02 AM UltraCID Info Ring of existing call detected ...
9/23/2011 12:36:14 AM UltraM1G Info Ethernet trouble was reported on Friday, September 23, 2011 at 12:36:00 AM
9/23/2011 12:36:14 AM UltraM1G Warning The following Elk M1 System troubles have been reported: Ethernet Trouble
9/23/2011 12:36:38 AM UltraM1G Info Ethernet restore was reported on Friday, September 23, 2011 at 12:36:00 AM

Regards,
Ultrajones
 
Thank you for posting that. I was considering moving some of my customers to Alarm Relay reporting but I really dont want to deal with this type of problem.
 
You must log in or register to reply here.

Similar threads

T
Need help connecting an ELK M1 Gold to a Johnson Controls PowerManage monitoring station
Replies
2
Views
641
TriLife
T
T
Connecting to Existing Elk M1G
Replies
5
Views
606
dwalt
D
R
Advice in Designing new Elk System
2 3
Replies
37
Views
3K
rmf
R
J
Help with ideas to cross-communicate between OmniPro II and Elk M1G
Replies
4
Views
203
jcd
J
I
M1XEP power consumptions
Replies
3
Views
558
Ira
I
Back
Top