Changing from Next Alarm to Alarm Relay with Elk

[Linwood]

In the hope it might be useful to others a brief recap of my transition.
 
I changed to VoIP at home, which meant I had to investigate the impact on my alarm.  Testing showed it would not work reliably.  I use an Uplink 2500 as well as POTS, and still wanted a secondary path, so I asked Next Alarm if they could monitor over IP.
 
Next Alarm will monitor only if you buy their ABN adapter.  The Elk M1G with the M1XEP has built in IP communications, and I was not keen on adding yet another device, so I looked at alternatives.
 
Geoarm and Alarm Relay appeared to be ready alternatives, Geoarm refused to do the elk, Alarm Relay said "no problem".
 
Alarm Relay's monthly cost ended up being almost  the same as Next Alarm, Alarm Relay was $20.95 and Next Alarm was $22.45, both are for basic fire+burg monitoring and Uplink fee, both with yearly payment.  A significant difference is Alarm Relay will not refund unused months if you change, Next Alarm will (not sure in first year, but they refunded me when I cancelled).
 
Up front fees are $50 for the two communicators, plus $25 for "Boldnet" which is a web based setup (there is no recurring fee), and $1 for email alerts (I think this is per year so the $20.95 is perhaps a tiny bit higher).
 
I ordered the service Thursday evening about 8:30pm eastern with a human.  They gave me a 2pm appointment the next day for conversion. 
 
I put in a ticket for cancellation of Next Alarm just afterwards.  I was pleased to find they did so and confirmed about 11am on Friday (next morning, basically about 1 business hour later).  They promised a refund in the email without my pushing.  Very polite and efficient.
 
Alarm Relay did a test against the uplink to make sure it was released, and called  me about 2 hours before to warn it was not.   I called Next Alarm, got a human immediately, described the problem -- while I was on the phone he checked, and released it.  No hassle at all, very quick.  I confirmed to Alarm Relay by email, got a call a few minutes later confirming we were good to go.
 
Alarm relay called right on schedule.  The tech started in the mode of telling me each keystroke, quickly adjusted to accommodate the fact I wasn't brain dead, and it took probably 5 real time minutes to make the changes.  I wasted another 10 minutes with questions on precise reporting and how they respond, which he answered patiently (though I could tell he wasn't used to getting quizzed).  He seemed to know what he was doing.
 
At his behest we then did a test of the burglary portion, reset that, then did a test of the backup communicator (the uplink) and the fire at the same time (I was pleased to see he insisted on separate fire zone test).  As each test went he red off the zones being violated and restored.  We then restored the IP and he confirmed he saw it again.  Total elapsed time was about 25 minutes, at least half of which was me asking questions.
 
Only slight hiccup is he thought I would get my web credentials the same day, I didn't, contacted them Monday and they said "end of next business day", and they did indeed come.
 
Differences: 
 
- Alarm Relay doesn't do open/close (disarm/arm) by default, there's an extra fee (haven't inquired yet how much), Next Alarm logged them on the web automatically
 
- Alarm Relay has a LOT more information online, both contact and account information and also detail communicator logs.  Next Alarm for example you couldn't tell on a periodic test which communicator was involved, you can on Alarm Relay (and see that both are working, separately). Even though there's a lot more info, it's not obvious it matters, I had no complaints about Next Alarm's info for 2 years.
 
- Alarm Relay will monitor for lack of communication (as opposed to an explicit trouble report communicated), Next Alarm will not (or at least would not with POTS/Uplink).  I have tried with Alarm Relay to see that they can see the loss; I haven't tested to see if they do indeed call yet.
 
- Alarm Relay says they will contact me with trouble reports; Next Alarm just lets you notify yourself with email.  I haven't tried to see how quick Alarm Relay does so yet. 
 
I'm used to having vendors let me down, but in this case I must say both responded impressively.  Next Alarm quickly confirmed lack of M1EXP support, gave me no grief about leaving, and proactively offered the refund.  Alarm Relay got me hooked up with pretty incredible speed (up and monitored in less than 24 hours from subscription).  
 
I'll test further with them and if I find anything interesting will update this later.

 

[etwards]

Thanks for the recap. 
 
I got up and running with AR today as well. I signed up for internet monitoring via the M1EXP initially and I plan to migrate to the Uplink 4500EZ in the next few weeks (cellular as primary and internet as backup). It took less than 30 minutes total for my setup and I am very much a novice. My technical support contact, Brian, was very patient walking me through the various settings and then the testing. I'm very pleased so far other than an issue with the install related to output 1 siren not working. 
 
I hope the 4500EZ install goes this smoothly!     

 

[Linwood]

They told me the IP monitoring should be primary "because it's faster". Not sure if true or not, but I had some issues with Uplink failover to POTS, so I wanted IP primary anyway.
 
We tested IP signal loss and the Upink did communicate.
 
FWIW.
 
Good Luck.

 

[etwards]

Yeah I got that answer from my tech as well.  "IP communication is so unbelievably fast" I think was his exact words. They definitely seem to be pushing this service. I don't think its sales related because I was told by an AR sales person that the additional cellular charge is a pass through (no markup) cost that they offer to their customers. She said they simply tack on their $8 monitoring fee to their cellular fee. I feel like the consensus on this forum is that TCP/IP is too unstable and unreliable. Honeywell says this much in their literature to "professional installers" but that could be part of a sales pitch to move their cellular communicators.  It is hard for me, a novice at this, to know which way to go. Thanks for the insight...

 

[Linwood]

Perhaps others will chime in, but from a lot of reading I think there's also a lot of confusion, as IP monitoring has different flavors: 
 
- Devices that convert POTS connections to internet signalling (like the ABN from NextAlarm)
- Devices that think they are going over POTS but are going over VoIP ATA's (e.g. OOMA, Vonage, etc.) 
- Devices like the M1XEP that are doing native communication in a standardized IP protocol
 
To some extent I think these are getting confused in many posts and probably by support staff.  Only the latter, to me, is IP monitoring.  And the second one is truly living on the edge in terms of reliability.  
 
in addition, people's internet connections and how they treat them must vary hugely.  I was reading a post recently about someone who turned off their router every night and wondered why strange things happened to their VoIP calls. You have people with satellite connections who don't understand why they have huge latency. You have people with old, slow routers (e.g. the venerable WRT54F) and fast gaming consoles and video plugged in, then wonder why they behave badly.
 
But I don't discount all the cautions, that's why I have the Uplink.  And I've tested, and will test again, that the failover works. 

 

[SteveInNorCal]

Thanks for the excellent review and comparison, Linwood. That is very helpful. This clinched AlarmRelay for me on several counts.
 

 

[Linwood]

I have a bit more information.  Last night we had a power failure, and for reasons I don't quite understand yet, a few hours later the M1XEP failed to communicate for 6 minutes.
 
During that 6 minutes, I got a wakeup call from Alarm Relay notifying me of a failure to communicate.
 
So they absolutely do monitor the IP communications and call to report issues.  And you absolutely (if you have a backup communicator) may want to ask them not to call for IP troubles in the middle of the night.   :blink:
 
Another recommendation that I think is probably good anytime - I put the system in test and generated all sorts of unusual conditions and troubles, to see what they would do.  A couple were problematic, but were fixed by coding on their end.   For example, I have a P212S secondary power supply. I pulled (only) its AC plug, and it sent a failure 15 minutes later exactly as it should -- but what it sent was unknown and they would have interpreted it as an alarm.  Interestingly unplugging an expansion module (which I thought may be more obscure) came through as trouble not alarm.
 
Anyway... good response, no problems reaching them, each signal showed up on Boldnet immediately (be very sure you buy that -- it's worth the one time cost), and the person I verified with afterwards understood exactly what I was doing and made sense.  So far so good.
 
To SteveInNorCall - I did not mean to imply that NextAlarm was bad, by the way.  They treated me well for 2 years, I only moved on because i wanted IP monitoring from the M1XEP.   There are some warning issues with them raised by others, but I have no personal knowledge of those.  They performed well during, and treated me well when I left.

 

[Del91574]

The reason why AR is pushing the IP communications route is because of UL....they're not required to have and maintain as many line cards for their CS receivers, which equates to a cost savings for them.
 
Next's ABN is no different than an ATA...the only difference is it's masking the CS ID of the panel and telephone number (if they both exist). It's no different than a dialer capture cellular (albeit less reliablie based on the comms routes) What that means is they can "technically" takeover any panel without touching programming as long as the format is one supported by the (proprietary in their case) ABN.

 

[tadr]

I have a bit more information.  Last night we had a power failure, and for reasons I don't quite understand yet, a few hours later the M1XEP failed to communicate for 6 minutes.
 
During that 6 minutes, I got a wakeup call from Alarm Relay notifying me of a failure to communicate.
 
So they absolutely do monitor the IP communications and call to report issues.  And you absolutely (if you have a backup communicator) may want to ask them not to call for IP troubles in the middle of the night.   :blink:

 
This has NOT been my experience with AlarmRelay.  It is my understanding that they do not monitor a "heartbeat" from the Elk M1XEP.  I bet dollars to donuts that you didn't actually get the call until the end of the 6 minute period, at which point the Elk sent an ethernet trouble to AlarmRelay when it came back online.  As far as I know, AlarmRelay has no way to know when the XEP loses connection, just when it comes back online.  This is a huge downfall, in my opinion.

 

[Linwood]

This has NOT been my experience with AlarmRelay.  It is my understanding that they do not monitor a "heartbeat" from the Elk M1XEP.  I bet dollars to donuts that you didn't actually get the call until the end of the 6 minute period, at which point the Elk sent an ethernet trouble to AlarmRelay when it came back online.  As far as I know, AlarmRelay has no way to know when the XEP loses connection, just when it comes back online.  This is a huge downfall, in my opinion.

 
I think you are mistaken.
 
First, ethernet trouble isn't a separate reporting code, I think.  I assume it would be reported as Failed to Communicate?   I have that disabled, it is not reported.  Now IF it was reported, I could see it buffering up maybe.  But that's not set.
 
I have done two tests since the initial power failure.  In both cases I pulled the ethernet cable.  Within a minute or two, it showed up at Alarm Relay.  I can see it arriving in their BoldNet service (which is very nice - real time and quite detailed).
 
The display distinguishes between communicators, so I can tell the message is not logged from the cellular, it is being logged because the heartbeat is lost. 
 
After 10 minutes each time I plugged it back in, and within 30 seconds or so, I can see a restore event in the Alarm Relay log.
 
Perhaps more importantly, I have access to the log of the event where they called me -- they called me before it was restored.  Unless they faked their time stamps, they had called me and talked to me before they got the restore signal.  The alarm on their end came in at 5:01, they called home (I was too slow) at 5:02, they called my cell at 5:03 (not quite sure why I missed that one), and called my wife's cell which I answered at 5:03.  They logged it as a false alarm at 5:08, and their system shows the communications restoral came at 5:09.
 
I'm sorry -- perhaps what you describe is what they did before.  But it doesn't seem like what they do now.  I have three separate events (two on purpose) that show them detecting the heartbeat failure.  The one not on purpose is still a bit of a mystery as I don't see network issues right then, but what they logged and how they reacted is completely consistent.

 

[Linwood]

I bet dollars to donuts 

 
Incidentally, you need a new intro... I think the average price of a single donut is now over a dollar.   

And "Donuts to dollars" just doesn't sound right.  

 

[tadr]

I think you are mistaken.
 
First, ethernet trouble isn't a separate reporting code, I think.  I assume it would be reported as Failed to Communicate?   I have that disabled, it is not reported.  Now IF it was reported, I could see it buffering up maybe.  But that's not set.
 
I have done two tests since the initial power failure.  In both cases I pulled the ethernet cable.  Within a minute or two, it showed up at Alarm Relay.  I can see it arriving in their BoldNet service (which is very nice - real time and quite detailed).
 
The display distinguishes between communicators, so I can tell the message is not logged from the cellular, it is being logged because the heartbeat is lost. 
 
After 10 minutes each time I plugged it back in, and within 30 seconds or so, I can see a restore event in the Alarm Relay log.
 
Perhaps more importantly, I have access to the log of the event where they called me -- they called me before it was restored.  Unless they faked their time stamps, they had called me and talked to me before they got the restore signal.  The alarm on their end came in at 5:01, they called home (I was too slow) at 5:02, they called my cell at 5:03 (not quite sure why I missed that one), and called my wife's cell which I answered at 5:03.  They logged it as a false alarm at 5:08, and their system shows the communications restoral came at 5:09.
 
I'm sorry -- perhaps what you describe is what they did before.  But it doesn't seem like what they do now.  I have three separate events (two on purpose) that show them detecting the heartbeat failure.  The one not on purpose is still a bit of a mystery as I don't see network issues right then, but what they logged and how they reacted is completely consistent.

 
Interesting.  I really hope you are correct.  Do you mind taking a screen cap of the elk settings you are using?  I know mine does not work this way.  Ethernet trouble was the incorrect terminology - they were only calling on Restore before with my configuration.

 

[Linwood]

Interesting.  I really hope you are correct.  Do you mind taking a screen cap of the elk settings you are using?  I know mine does not work this way.  Ethernet trouble was the incorrect terminology - they were only calling on Restore before with my configuration.

 
Not at all, I assume it's this portion.   But I suspect whether they monitor for heartbeat or not is more about their setup than the M1XEP setup.
 
My comment on ethernet trouble related to the fact that the M1XEP itself detects and logs ethernet trouble (and specifically calls that).  It logs it into the log, but I don't see that it has a communicator setup for that, so my presumption (based on no information) is that it is communicated as a fail to communicate (or maybe it's not communicated at all).  But in my case I have Fail to Communicate disabled anyway, so I think it's moot.  But i think it's all moot regardless, I think they are seeing the absence of the heartbeat.

 

[tadr]

Not at all, I assume it's this portion.   But I suspect whether they monitor for heartbeat or not is more about their setup than the M1XEP setup.
 
My comment on ethernet trouble related to the fact that the M1XEP itself detects and logs ethernet trouble (and specifically calls that).  It logs it into the log, but I don't see that it has a communicator setup for that, so my presumption (based on no information) is that it is communicated as a fail to communicate (or maybe it's not communicated at all).  But in my case I have Fail to Communicate disabled anyway, so I think it's moot.  But i think it's all moot regardless, I think they are seeing the absence of the heartbeat.

 
I am almost certain that I asked them about that heartbeat setting when I set mine up 3-4 years ago and they said they couldn't do that.  I will be calling them tonight