Elk M1G, VoIP, Nextalarm, & Comm error

[voip]

BEWARE of next alarms flaws and failures. I admit that something is better than nothing, but the reason that many are not getting the Kissoff signal is because only the alarm reciever at the monitoring station is allowed to produce it. Next alarm forwards the alarm to a subcontracted central station and was originally causing the kissoff itself. This was preventing some alarms from retransmitting when the reciever didn't get the alarm.

Also, with voip and alarms using contact ID there are huge problems because the alarm panels send the tones to short. With voip digits have to be a little longer in duration because they tend to have the beginning of the tone chopped off.

Programming the pannel for 4+2 at 20 pps on the first line and programing line 2 as a back up using 4+2 at 10pps should solve your problems.

The way that Next Alarm is dodging the liability issues is buy selling to the public and blaming it on the installer.

Good luck, and remember to test you system regulary.

 

[dscline]

the reason that many are not getting the Kissoff signal is because only the alarm reciever at the monitoring station is allowed to produce it. Next alarm forwards the alarm to a subcontracted central station ...

So what you're saying is, the call is actually going in to NextAlarm, being answered by NextAlarm's equipment, then being forwarded to a central station? I knew they sub-contracted out the central station, but I ASSUMED that my calls were going directly to whatever central station that was.

I guess that would explain how they are providing features that other companies don't (like the emailing, online logging, and the broadband adapter). But if only only the central station is allowed to generate the kissoff signal, then that sounds like there's some kind of three-way call being initiated when we call in to them? The call goes in to NextAlarm, a three-way is initiated that brings on the central station, the central station gets the data and sends the kiss-off, while NextAlarm "listens in" to get the data it needs for for the web logging, etc.?

That does actually make some sense... I had wondered why switching SIA made their extended features no longer work... if the monitoring station could understand SIA, why didn't that data get reflected in the web interface? I guess the answer is: because NextAlarm's equipment only understands Contact ID. So while the Central station understands the call, NextAlarm doesn't get anything out of it while it's listening in?

Hopefully much of this kludgeyness will get resolved if/when they become alarm over IP capable. I would imagine, then, that NextAlarm would take the report via the internet, and then forward the data (either via IP or phone) to the central station?

 

[larryc]

Hi all. I was searching Google and came across this thread. While I realize it is a number of months old, I was hoping someone has solved the problems described in it.

I am experiencing the exact same problems described earlier in this thread, although I am not using an Elk panel. I first hooked my panel up to a POTs line and dialed over it to NextAlarm. My problem is that most of the time (but not always) my panel is able to send the information, but it is not getting the kiss-off signal correctly from NetAlarm, so it ends up redialing NextAlarm multiple times. NextAlarm shows the signal received 14 times, but my panel eventually displays "Comm Error" after it has given up. If I monitor the line while it is dialing, I can hear an initial handshake of two tones(low-high), then a burst of DTMF tones, then a longer tone (I assume this is the kiss-off), then I hear the DTMF tones again (I assume this is the panel trying to resend).

As I noted, most of the time this happens as I described. Occasionally, my panel will correctly interpret the kiss-off signal. I have tried raising this issue with NextAlarm, but they say they are stumped and the problem may lie in my panel. The alarm system is only one year old and my installer claims the problem is on NextAlarm's side.

Recently, I decided to see if I could work around this problem by trying to use NextAlarm's internet monitoring. I programmed a Linksys PAP2 (the same as their ABN) and connected my panel to it. Unfortunately, this worked even worse than the POTS line. In this setup, my panel is connecting to NextAlarm, getting the initial handshake and sending the DTMF data, but NextAlarm is not registering the data and is not sending a kiss-off. No activity shows up on my NextAlarm user activity page.
I also raised this issue with NextAlarm; they said it may be due to the firmware in my PAP2; they would research it and let me know.

So, I am a bit frustrated that this is so difficult to solve, but I am at least heartened to find this forum and see that others have had similar problems. If anyone could provide some tips, I would greatly appreciate it. I know I could switch my panel to 4+2, but then I would lose the online monitoring benefits of NextAlarm and I am reluctant to do that.

Thanks,
Larry

 

[Dan_NA]

Hi,

VOIP, some of the things you are saying are just not correct, with regards to the kissoff and tone lengths. There are indeed many problems with transmitting Contact ID alarm signals over VoIP, which is exactly why we developed ABN. Regarding your second point, the equipment that handles ABN and E-Notify is in fact located at each of our central stations.

I think there may be two issues being discussed here. Some people are having problems with ABN, and others trying to get their Elk panels communicating directly over their VoIP lines. We definitely do not recommend the latter. Alarms over VoIP are not reliable, and it's a big problem, but we have a solution in ABN. We are also in the middle of negotiations for the equipment to support Elk's own IP monitoring solution.

Larryc sent me a PM and I think his issue is now resolved as far as is possible for the moment. Basically, the latest Linksys PAP2/PAP2T firmware will *not* work for ABN, despite what we thought. We'll have a solution for this soon in the form of new firmware you can enter into your adapters. This isn't an issue for adapters sold as "ABN adapter" from online retailers, this is only an issue if you have your own PAP2/PAP2T and are provisioning it for use with ABN.


There's a lot going on in this thread, and I hope I've covered most or all of it. If anyone has any more questions, please feel free to ask

Dan
NextAlarm.com

 

[electron]

That's a lot of great information, thanks for taking the time to post this!

 

[IVB]

Ditto, glad to have a company rep on here addressing questions & concerns. (esp since I have a contract with said company )

 

[dscline]

...trying to get their Elk panels communicating directly over their VoIP lines. We definitely do not recommend the latter. Alarms over VoIP are not reliable, and it's a big problem, but we have a solution in ABN. We are also in the middle of negotiations for the equipment to support Elk's own IP monitoring solution.

I understand the ABN is NextAlarm's "suggested" connection method for VoIP users. However, asking an Elk user to invest in an ABN to use your service is like is like asking someone who has only a DVD player to buy a VCR so they can rent from from your tape only rental store. Personally, I'd rather deal with the limitations of SIA until someone offers true internet monitoring, than invest money into a stop-gap dead-end solution. I'm not deliberately trying to slam the ABN, but for someone who already has an elk ethernet interface, such a purchase just isn't attractive.

On a different note, I'm quite excited to hear that there is activity towards supporting the ethernet module.

 

[spongebobusa]

Hi,

VOIP, some of the things you are saying are just not correct, with regards to the kissoff and tone lengths. There are indeed many problems with transmitting Contact ID alarm signals over VoIP, which is exactly why we developed ABN. Regarding your second point, the equipment that handles ABN and E-Notify is in fact located at each of our central stations.

I think there may be two issues being discussed here. Some people are having problems with ABN, and others trying to get their Elk panels communicating directly over their VoIP lines. We definitely do not recommend the latter. Alarms over VoIP are not reliable, and it's a big problem, but we have a solution in ABN. We are also in the middle of negotiations for the equipment to support Elk's own IP monitoring solution.

Larryc sent me a PM and I think his issue is now resolved as far as is possible for the moment. Basically, the latest Linksys PAP2/PAP2T firmware will *not* work for ABN, despite what we thought. We'll have a solution for this soon in the form of new firmware you can enter into your adapters. This isn't an issue for adapters sold as "ABN adapter" from online retailers, this is only an issue if you have your own PAP2/PAP2T and are provisioning it for use with ABN.


There's a lot going on in this thread, and I hope I've covered most or all of it. If anyone has any more questions, please feel free to ask

Dan
NextAlarm.com

Hi, any update on this?

Thx and happy holiday,
Spongebob

 

[Dan_NA]

Update on Elk IP support? We have the receiver (actually it's just software), and we're in the process of putting it together, configuring it, and testing it. We have a booth showcasing our new services at CES next week, so things are busy right now, but I would expect to see Elk IP support announced shortly after that.

Dan

 

[Digger]

Thank you Thank you Thank You! Solves a major problem for me. Any idea on pricing? As promised I will sign up once its up and running.

 

[rfdesq]

Dan:

Update on Two-Way listen in? Thanks.

 

[Dan_NA]

It will be the same price as our other services. $14.95 per month or $11.95 per month if prepaid annually. There's no reason to charge any additional fees for it, it doesn't cost us any more than receiving signals any other way.

Two-way voice I don't have an update on, but it will be soon. We have several interesting voice-related features coming soon that I can't speak about specifically, but will be announced at CES.

 

[Digger]

works for me............

 

[BraveSirRobbin]

We have several interesting voice-related features coming soon that I can't speak about specifically, but will be announced at CES.

What section/booth are you in? I should be attending. Perhaps an exclusive CocoonTech interview could be had!?! :blink:

 

[dscline]

Now THAT is exciting! Really looking forward to switching to IP monitoring. :blink: