Elk M1G, VoIP, Nextalarm, & Comm error

[dscline]

I just installed an M1G this weekend, and signed up for NextAlarm service. Based on the reports of others, and the fact that I'm able to use an uncompressed (g711) format with my VoIP provider (VoicePulse), I had hoped that I'd be able to connect via phone until some options open up for internet monitoring (I also got the ethernet adapter).

The set-up procedure for Nextalarm has you trigger an alarm, then check their internet based activity log to confirm that the communication was successful. The alarm did register. In fact, it registered 14 times. But I'm getting a "commun error" (or something to that effect) on the keypad. Since it appeared to report the alarm multiple times, is it a fair assumption that although Nextalarm is getting the alarm fine, for whatever reason the M1 is not reading the kissoff (and therefore trying again)? Any suggestions on resolving this? I did notice that there was some noise while using the phone control feature of the M1, which made me wonder if I had some cabling issues, but regular phone calls (which have to route through the M1) sound fine. Is poor sound quality for the phone interface normal?

Thanks!

 

[Spanky]

Turn on the Butt Set mode in user menu 8, 4, 3 and listen for the communication kissoff through the Output 1 speaker to see if everything sounds OK.

The M1 is not receiving the kissoff properly and trying multiple times to get through to the central station.

 

[dscline]

Thanks for the reply, I will do that. What should it sound like? Should I also be able to get that through the test communications option?

 

[Spanky]

You will hear a 2300 Hertz, 1 second tone from the Central station which tells the M1 to start sending data. Contact ID: sends a sequence of Touchtone tones as the data. The Central station then sends another 2300 Hertz tone to Kissoff the M1 and acknowledge the data. The 2300 Hertz Kissoff tone is probably not being received.

One of the problems seen is the inability to reproduce long single tones like the 2300 Hertz tone without messing it up. Guess they never asked the Security Industry before making the VOIP specs. However, Vonage seems to work fine.

 

[jwilson56]

Just a note.... from what I have read and verified by a friend that works for an alarm company..... many security services do not work with VoIP phone services. As for my knowledge, since I do not have an Elk this might not be the area of your problem. I just thought I would toss this tibit of information out there.

John

 

[hgupta1]

Good question.. I had actually just hooked up vonage, elk, and next alarm this weekend as well. I also saw the communication error once, but I wasn't too concerned about it since Next alarm still recieved the message.

I get the occasional telephone trouble / telephone restore messages. Is this due to vonage?

 

[dscline]

from what I have read and verified by a friend that works for an alarm company..... many security services do not work with VoIP phone services.

Yes, many security companies don't like VoIP, both from a perspective of the possibility of the signal getting screwed up due to the compression and latency used on VoIP lines, and because of the concern over the fact that your link to the central station is dependent on the reliability of your internet provider (and internal equipment like modems, routers, and having back-up power for them). I initially figured the signalling might have been getting screwed up on my VoIP line, but Spanky's last response has me a bit perplexed... since the kissoff is the same signal as that used to tell the panel to START sending data, how is it reliably getting the first signal, but never getting the last one? I'll do some testing tonight with Butt Set mode on... maybe that'll shed some light.

Thanks for all the input!

 

[Spanky]

If Vonage looses connection to its server, it drops the telephone line voltage to the M1. The M1 senses the voltage drop and displays a telephone communication failure or telephone line fault.

Your Tele Comm message may be from a connection problem to the VOIP server. The message will remain on the M1 until it gets a good communication to the central station or you power down and back up the M1.

 

[dscline]

I also saw the communication error once, but I wasn't too concerned about it since Next alarm still recieved the message.

I get the occasional telephone trouble / telephone restore messages. Is this due to vonage?

I've not gotten the telephone trouble error yet, so it at least seems to get a good dial tone. When you say you got the comm error once... I assume that means it went away? My understanding is that error will continue rotating through the keypad display until it's able to get a "good" call through, which I haven't yet been able to get happen. At least not from the panel's perspective... NextAlarm seems to be getting the message fine, the M1 just doesn't seem to realize it.

 

[AutomatedOutlet]

Mine works fine without issue - Elk, vonage, nextalarm.

 

[dscline]

Hmmm, now I'm not sure what to think. I've done several tests, and some times the "fail to commun" error would go away, but some times it would come back. Listening in to the calls don't sound like what Spanky described: I hear it dial, then I hear two really quick beeps, the first one lower in frequency than the second, then a series of quick DTMF tones, followed by a pause, then it keeps repeating the same DTMF series about five times, and gives up.

What do the two quick beeps indicate? I KNOW I picked CID as the protocol when I set up NextAlarm, but what I'm getting is not a single tone that lasts a second (I'd guess the two tones I hear BOTH complete in less than .5 secs). I can't find a way on the NextAlarm site to go back and confirm those settings. I've also confirmed that Contact ID is what is set on my panel. And Nextalarm is successfully getting my signals, even the tests.

 

[Digger]

Once you get this resolved you may want to program your panel to chirp the siren once a kissoff is received. This way if there is ever a problem in the future you will know that the CS did not get the transmission as you leave the house. You can do this by going to rules and tell it whenever the panel recevies the kissoff to chirp the siren (or anything else u want).

 

[Spanky]

The two chirps is the send data, then you should get the same two chirps for the kissoff. It does not sound like you are getting the kissoff chirps. If the M1 receives the kissoff it will not repeat the message again.

 

[dscline]

Just as a follow-up: I've not been able to get Contact ID to work reliably. They get the message, but I never get a kissoff back. Some searching has turned up some posts at broadbandreports.com of VoIP users with similar issues. The "fix" is to switch to a different format. I'm now using SIA, which appears to have solved the issue, but sadly you lose much of NextAlarms functionality when you move away from Contact ID. The email alerts no longer work, you can't tell in the web based alarm history what type of report they received, and somehow sending via Contact ID caused my "log only" zones to no longer be log only. Therefore, I had a dispatched false alarm today. Not end of the world, but important to know if you switch away from Contact ID.

I also asked if they had any timeline for allowing alarm over IP (so I can use my XEP interface instead of the voice line). They said they don't have a timeline, but are actively looking at it. That is at least encouraging. I'm not aware of any DIY friendly monitoring services that yet has this ability, so anyone interested should contact them and let them know there's a market for it.

 

[AutomatedOutlet]

We're using ContactID here and it's been working fine so far.