ELK, NextAlarm and no landline

Tracfone sells 60 minutes, good for 3 months, for $19.99. I have one at home, will have to check if it's GSM based, but that would be about $6/month. That said, doesn't the system check in on a regular basis with the monitoring center? Wouldn't that use minutes?

Yes, you set that up as to what frequency you want. They system reporting takes less than one minute regardless of what type of report it is (at least I have never seen a 2 minute call from the system). I have mine set to do a once a month check-in.
 
No, NextAlarm does NOT support monitoring the XEP directly via IP using Osbourne-Hoffman. NextAlarm has claimed that they will support the XEP via Surgard "in the very near future" (but they said that about OH years ago also).


No, it is not "required" from a technical perspective. Lots of people use Vonage or other VOIPs without issue, although there are some with issues, so YMMV depending upon VOIP provider and local infrastructure. NextAlarm policy is that everyone with VIOP should be using their ABN instead of standard VOIP (but they do not enforce this).


I have heard multiple similar comments from multiple people, but cannot find anything to support the claim that the ABN simply captures and then forwards. From everything I have read, the NextAlarm ABN is simply a tweaked/locked router/VOIP box configured to communicate directly with their monitoring center (possibly an Asterisk server) via IP. Has anybody on CT with an ABN tested what happens when the ABN is disconnected from the internet and the Elk tries to report? Any capture and forward device (ABN or whatever) would make me nervous since it gives a false sense of security. This brings up one of my favorite requests: that the Elk M1 should log when it has to resort to your backup (i.e. cellular) communication method so that you are aware of communications failures. Otherwise you could be virtually relying on your "backup" method as your sole means of reporting and would never be aware.
https://nextalarm.com/abn.jsp

To get a log input (assuming a cell backup) would depend on the unit that is installed. If using an Uplink on the M1, no issue, done via rules and an ascii string that the unit sends to the M1. The easiest way to flop it then would be to have an output fault an input to drop it into the log. Same would apply to a Telgard. I'd have to doublecheck a DSC 3060's triggers.

The ABN's, the last time I had a chance to bench one, only capture alarm data, not account or dialer information and faked the handshakes and kissoffs, even if the ABN did not successfully transmit it's signal.
 
IP is viable IF there is appropriate safeguards and policies attached to the account. The problem with IP in most situations is the end-user does not typically have enterprise grade service or hardware installed, which makes a difference for reliability. The IP DACT's need to have a heartbeat supervision and there needs to be an appropriate response on loss of supervision. The cellular issue is not a major sticking point because most manufacturers don't rush to market with a product like that due to UL and other standards that must be met, same reason why a lot of equipment takes time to be updated/upgraded in the alarm world, not because they're being archaic, but because the equipment must work reliably all the time, they can't go with a flavor of the week technology.
Agreed on the robustness of the equipment, although most consumer routers these days are pretty darn reliable. The main thing is to have UPS or some sort of power backup for ALL the components - cable or dsl modem, router and XEP. If any part of the network connectivity goes down then bye bye monitoring.

Alarm Relay DOES use a heartbeat that is configurable and as I learned they DO call on loss of supervision. I know because they do still have a few issues to work out with Elk on dropouts.

But if the absolute knowns are Elk w/XEP and no landline then I think Alarm Relay IP is a very good option to consider.
 
Just a thought...

The last 10 years or so I lived in pretty established communities that lost power for maybe 30 minutes every couple years... but now I'm still in suburbia, but in an outskirt... Weird that I've lost power now twice in 6 months for more than 8 hours. My first observation - AT&T becomes unusable. I have an awesome signal (there's no electrical interference anywhere around me!) but I can't make a call and data times out... because of over-saturation on the networks. It seems when people don't have power they have nothing left to do but bitch on Facebook about not having power via their cell phones. AT&T is the only GSM carrier here - T-Mobile is non-existent on the west coast.

While I don't have links, I have read similar about the kissoff from the ABN before the transmission has taken place - for that I won't trust one. I'm going alarmrelay with native IP communications with the cellular backup.

This is such a tough topic - for the last 10 years I've literally kept a phone line for the alarm and Tivo - but thanks to government regulation and other BS, the costs keep going up - to the point where it's not worth paying $40/month for a phone line I use 57/minutes/month on. I'd rather pay for the cellular backup as an add-a-line.

Quite frankly, I feel like there are no good options today short of great battery backups on your broadband connection combined with cellular backup.
 
Update: I am up and running with Alarm Relay directly from M1G over IP. Customer service was very good, seemed like a pretty small shop. They sales rep knew what I was talking, she asked if I had the M1XEP. $142.40 for the year.

A tech called me after acct setup to configure the Elk. He has a playbook where we went thru and setup the M1XEP Central Station info, and the Communicator RCs. We did some zone tests, and it works perfectly.

As for this comment "The IP DACT's need to have a heartbeat supervision and there needs to be an appropriate response on loss of supervision" They did have me check the 'Supervise the Connection' box in Central Station Tab, with a Hearbeat Interval of 180 secs. He said after 2 communication failures, they call, and they did so this morning. I have SBC DSL fronting a LAN of normal consumer grade hardware. Im now wondering if now I'll have recurring communication failures.

now if I can just get a refund for the prepaid year of NextAlarm!
 
I bet they will let you switch out to a phone based system.

Hopefully you won't need it because this loss of heartbeat one day into setup is just bad luck, but I kind of suspect you will have this periodically. I have roadrunner at home and business grade dsl at the office, and periodically things stop working for seconds, or maybe a minute, and then work again for no appearant reason. No biggy for me but if it means you get a phone call (especially if that call comes at 3am), you will not be happy.
 
Most central stations support the Surgard receivers. The M1XEP Ethernet Module supports the Surgard IP protocol. The basic Surgard protocol is going to be the new SIA IP alarm communication standard in the near future.
 
If you are using cellular for monitoring, keep in mind that NextAlarm has the panel report every time you arm or disarm the panel. They don't do nightly tests like some do. Assuming you leave and return once a day and use the alarm at night that is at least 4 minutes a day (or 2 hours a month) it will be higher if you leave more often.

The ABN that Next Alarm uses has a heartbeat, and NextAlarm will send you an e-mail if the heartbeat is missing for a period of time that you set, typically 5 minutes. In addition, if the alarm panel attempts to get to NextAlarm but it can't because of Internet problems, it will will report a communications error just like if the panel used a phone line and the phone line was down.

So with Internet monitoring, the connection between the ABN and NextAlarm is supervised, in a sense. If you use a analog phone line or cellular phone connection and that connection goes down, you'll never know it unless it occurs at the instant the panel is attempting to communicate, like when you turn the alarm on or off.

It is also true that some panels can monitor the phone line voltage and report if the line is cut, but a phone line cut and not working are two different things.

So, Internet monitoring is really no worse then monitoring via a analog phone line, and its probably much better.

BUT if you use Internet monitoring, make sure your modem and router and switches all have battery backups, or if the power goes out...
 
If you are using cellular for monitoring, keep in mind that NextAlarm has the panel report every time you arm or disarm the panel. They don't do nightly tests like some do. Assuming you leave and return once a day and use the alarm at night that is at least 4 minutes a day (or 2 hours a month) it will be higher if you leave more often.

The ABN that Next Alarm uses has a heartbeat, and NextAlarm will send you an e-mail if the heartbeat is missing for a period of time that you set, typically 5 minutes. In addition, if the alarm panel attempts to get to NextAlarm but it can't because of Internet problems, it will will report a communications error just like if the panel used a phone line and the phone line was down.

So with Internet monitoring, the connection between the ABN and NextAlarm is supervised, in a sense. If you use a analog phone line or cellular phone connection and that connection goes down, you'll never know it unless it occurs at the instant the panel is attempting to communicate, like when you turn the alarm on or off.

It is also true that some panels can monitor the phone line voltage and report if the line is cut, but a phone line cut and not working are two different things.

So, Internet monitoring is really no worse then monitoring via a analog phone line, and its probably much better.

BUT if you use Internet monitoring, make sure your modem and router and switches all have battery backups, or if the power goes out...

Exactly. The only thing that I would say differently is that you can program a communication test for whenever you want (daily etc) with cellular or any other means for that matter.
 
The ABN that Next Alarm uses has a heartbeat, and NextAlarm will send you an e-mail if the heartbeat is missing for a period of time that you set, typically 5 minutes. In addition, if the alarm panel attempts to get to NextAlarm but it can't because of Internet problems, it will will report a communications error just like if the panel used a phone line and the phone line was down.

So with Internet monitoring, the connection between the ABN and NextAlarm is supervised, in a sense. If you use a analog phone line or cellular phone connection and that connection goes down, you'll never know it unless it occurs at the instant the panel is attempting to communicate, like when you turn the alarm on or off.


So, Internet monitoring is really no worse then monitoring via a analog phone line, and its probably much better.

BUT if you use Internet monitoring, make sure your modem and router and switches all have battery backups, or if the power goes out...


The problem I have with the ABN is that it fakes the kissoff and handshake, so the panel never actually knows if it communicates with a receiver correctly. Factor in any latency on the network, etc..... you have an unreliable device, irregardless if there's a heartbeat, because all that does is let them know the ABN is connected to the TCP/IP network. Basicially I think it's a flawed system compared to a true IP communicator, the XEP or any other manufacturer, because there is no feedback to the panel, and I've yet to hear Nextalarm spell out the actual facts.
 
If you are using cellular for monitoring, keep in mind that NextAlarm has the panel report every time you arm or disarm the panel. They don't do nightly tests like some do. Assuming you leave and return once a day and use the alarm at night that is at least 4 minutes a day (or 2 hours a month) it will be higher if you leave more often.

The ABN that Next Alarm uses has a heartbeat, and NextAlarm will send you an e-mail if the heartbeat is missing for a period of time that you set, typically 5 minutes. In addition, if the alarm panel attempts to get to NextAlarm but it can't because of Internet problems, it will will report a communications error just like if the panel used a phone line and the phone line was down.

So with Internet monitoring, the connection between the ABN and NextAlarm is supervised, in a sense. If you use a analog phone line or cellular phone connection and that connection goes down, you'll never know it unless it occurs at the instant the panel is attempting to communicate, like when you turn the alarm on or off.

It is also true that some panels can monitor the phone line voltage and report if the line is cut, but a phone line cut and not working are two different things.

So, Internet monitoring is really no worse then monitoring via a analog phone line, and its probably much better.

BUT if you use Internet monitoring, make sure your modem and router and switches all have battery backups, or if the power goes out...


I don't know Next alarms policy, but an Elk system only calls in when you tell it to call in. So if you are doing the programming, you can set whatevery you want. Personally, I think every arm/disarm is a bit overkill. If you do cellular and have it on a shared minute plan with unlimited nights, just set up a 2 am checkin and it won't use any minutes. Or do a prepaid plan through tmobile. . .$100 for a thousand minutes used within one year. That averages about $8/mo and gives you about 2 or 3 minutes every day for checkins.

If next alarm refuses to allow anything less than every arm/disarm, there are plenty of other companies that will do whatever you want.
 
The problem I have with the ABN is that it fakes the kissoff and handshake, so the panel never actually knows if it communicates with a receiver correctly. Factor in any latency on the network, etc..... you have an unreliable device, irregardless if there's a heartbeat, because all that does is let them know the ABN is connected to the TCP/IP network. Basicially I think it's a flawed system compared to a true IP communicator, the XEP or any other manufacturer, because there is no feedback to the panel, and I've yet to hear Nextalarm spell out the actual facts.


Next Alarm's ABN is basically no different (or very little difference) than any other mfg's dial capture device for cell or internet. DSC, Honeywell, I think DMP and others have dial capture devices for Cell or TCP/IP that would have the same behavior as the Next Alarm ABN. Others are being developed now as they are very popular with larger installation companies to get around VOIP problems. Basically just grabbing the contact ID and forwarding it over GSM or Internet. I now that DSC and Honeywell's are UL Listed for Residential use and DSC's is UL Listed for Supplemental use in Commercial Burg (not fire). There is no real cost savings using an ABN over a TCP/IP communication device that talks to the panel of the data buss as they cost just slighty more than an ABN.

These types of devices are a step up from a normal DACT. They are not a true multiplex system in my opinion but if thats what you want dont use them.

As far as no feedback to the panel that is possible just not sure if anyone has done it yet.

Regarding latency if there is a problem getting such a small data package from point A to B in less time than it takes to dial out they there is a serious problem. I ran a test on the 7845i when I worked at UL and the maximum time it took to report an alarm etc was about 11 seconds. That was with a degraded internet connection.

I cant get from my front door to my car before my cellphone gets the text message my alarm is set using the ABN. That includes delays with AT&T you would not see at a CS.
 
The dialer capture cell units have provisions for connection to the host panel for supervision and programming options that allow full supervision of the cell's actual status as well as FTC's and other system events. The ABN does not have any provisions for such a connection to the host panel, so it's an apple/orange argument.

A heartbeat is one thing, but faking out the panel and not providing any feedback on a FTC or other system event so the panel and end users know is an entirely different thing.

The ABN is used for panels that don't have the ability to support a TCP/IP connection directly.
 
The dialer capture cell units have provisions for connection to the host panel for supervision and programming options that allow full supervision of the cell's actual status as well as FTC's and other system events. The ABN does not have any provisions for such a connection to the host panel, so it's an apple/orange argument.

A heartbeat is one thing, but faking out the panel and not providing any feedback on a FTC or other system event so the panel and end users know is an entirely different thing.

The ABN is used for panels that don't have the ability to support a TCP/IP connection directly.

The only supervision some models have is for AC power and battery failure which is very basic. Most can not notify the central station if they have a loss of communication with the host panel as the account information resides in the panel (the premise would know in most cases).

With the ABN if the circuit between the panel and ABN is lost you get a telco fault because the panel supervises it. If the panel can not communicate to the CS through the ABN you can get a Comm Failure at the panel but I would agree it may not be for all scenerios (I have had some Comm Failures on systems using the ABN a few times a year but I never tested every possibily). Both UL and NFPA do not require supervision of the DACT of a panel to the ABN if they are within the same enclosure (and a few other situations). Some mfg's of cell reporting hardware can not be installed within the panel enclosure, are not supervised for the connection to the panel, and would have to have the interconnection run in conduit and if I remember correctly there is a limit to the length allowed by the NFPA.

With many cell reporting systems you would not know if your path to the CS is active the way they are set up but you do with an ABN. Polling is not always from the premise to the central station via cell (although it can be) because of the cost. It is basically similar to a DACT and you dont know if your connection to the CS is good until you test or use it. A true multiplex system polls from the premise to the central station and would alert both the premise and the CS of a loss of communication path within 200 seconds. TCP/IP is currently the cost effective way to do that. It can be done via cellular however even that uses TCP/IP indirectly in most if not all cases. The cost for the constant (every 90 seconds or so) polling packet via cell can add up. The best situation would be to have redundant means of communication as any means of communication can be easily compromised.

Unfortunately I can not explain it to well because of a NDA I have with a mfg in regards to the design of the hardware and its capabilities and limitations. I would imagine there is another Cocooner who can elaborate more to explain it to you as your experience seems to be from a user standpoint and there are other considerations for each type of technology from a design and compliance standpoint. Most celluar systems are UL Listed as Supplemental Use for Commercial Applications as they can not meet the full commercial requirements (there are some that meet the full Commercial requirements but they are much more expensive). Those limitations can be the fact that there is no constant supervision of the communication path.
 
My understanding with the ABN is that like DEL mentions above - it fakes out the communication and the kissoff so the Panel wouldn't know to try a backup method should the primary fail. At least in using native TCP/IP, the panel knows if communication succeeded or not; and upon failure can use the backup method. That right there means everything to me. Also, I don't want to worry about minutes - so I prefer the AlarmRelay method where the $12 covers the cell service - so I don't care if it checks in every 10 minutes as long as i'm not taking the hit personally.
 
Back
Top