elk vonage and next alarm troubles

[hgupta1]

When I got home today, the alarm had been going off for about an hour and half, but apparently nextalarm didn't send anybody out or call.

I looked at the vonage records which showed that the alarm repeatedly tried contacting nextalarm. So the alarm was trying to call out. Also, homeseer sent a text message to my cell phone, but I couldn't get it. There did not appear to be a break in.



Is nextalarm not answering the calls?

The Elk log says
18:31 1146=Restore Burglar Zone (when I came home)
17:17 1160=Control over Current Restore
17:16 1140=Contro over Current Trouble
17:11 1157=Communication Fail Restore
17:09 1130=Fail to communicate trouble
17:06 1003=Burglar Alarm Hall Motion (zn 3)
17:06 1146=Restore Burglar Zone Hall Motion (zn 3)
17:06 1003=Burglar Alarm Front Door (zn1)
17:06 1003=Burglar Alarm Hall Motion (zn 3)


What on earth is going on?

 

[AutomatedOutlet]

17:09 1130=Fail to communicate trouble

Nope, doesn't look like nextalarm got the call. Check your outdial settings.

 

[Steve]

It also looks like it may be that bug in other thread. Motion zone, then front door??? Sounds suspicious. Is the motion wireless?

 

[hgupta1]

its not wireless. Everything is hardwired. I am still a little bit freaked out because according to the logs, the alarm was armed at 17:02. I walked out the door immediately after arming. at 17:06 motion was detected inside, and the front door opens. Either the elk screwed up, or someone followed me out. Eitherway next alarm should have called the cops.

How do I check the outdial settings? I think everything should be okay because I tested the system by triggering the alarm a couple of times. Everything worked perfectly. Nextalarm got the signal each time during the test.

 

[dscline]

It looks you are experiencing two separate unrelated issues that I have had. The two alarms in the same minute look suspiciously like the problem I've been having with false alarms. At this point, I don't think it's necessarily tied to wireless sensors, it just so happens that the zones I have that are most likely to be tripped coincidentally are wireless. In my case, I have no way of knowing if these are complete false alarms, or if the first trip is real, and only the subsequent trips within the same timestamp in the log are false. But I do know AT LEAST the subsequent trips in the time stamp are false, because they are secure every time this happens. Based on the postings of others, I tend to believe the initial trip in the log is correct, only the subsequent ones are false. So in your case, I would believe the hall motion, but not the door. Do you have a pet or something else that could have triggered the hall motion?

As far NextAlarm goes... I also had poor reliability over my VoIP line. I ended up switching from their default Contact ID format to SIA. SIA is more reliable over a less robust phone connection (contact ID is too fast). But be forewarned.... many of the web features of NextAlarm go away when you switch away from Contact ID. Their email notices don't work, the detail of the reports go away (you can see that your panel called them, but there's no detail to see why), and many of the remote setup features just get ignored... I had a couple zones set up as "report only", but after I switched to SIA, the next time I had motion in that zone, they called the police. So you have to have to treat them like a more "conventional" monitoring company - call them to put it in test mode, or to change zone setup, etc.

Supposedly they are looking in to Alarm over IP. If you have the M1XEP, be sure to express your interest in that. That will hopefully solve the reporting issues for us.

 

[hgupta1]

Thanks, dscline,

I think you are right about having 2 separate issues.

There was no way that the front door opened. I checked the video and no one came up on the porch or left the porch. Plus I have 3 very large german shepherds (the smallest is 100 pounds) that would have at least tried to run outside if the door opened due to a big breeze. I'm guessing that I might have accidentally armed the house to Exit mode instead of Away mode. I really wish that the Elk logs or the Homeseer logs would show you the arming state (I am using the my.elk script that electron wrote).

If there is a bug in my elk I am going to be very depressed! Its too expensive and too critical of a component to be buggy!

 

[gcimmino]

I can only second the need to have additional logging.

It would be great if we could write rules that would log any string. Yes, I know there are memory limits..

Of course, if we had the ability to email dynamic strings, then you could also "log" via emails as much content as you wanted. Being limited to 16 static email texts doesn't cut it.

If there isn't already, there needs to be an event code to text table in the elk that would allow us to create log messages and/or emails with a rule like:

Wheneven ANY ALARM ANY AREA Turns On
Then Email {owner} priority=high {Area} {Zone} {Alarm} where the Area, Zone and Alarm type would be filled in based on the event. {owner} should be a new, text type custom setting entry so we'd only have to fill in/change the actual email address once.

Just a thought..

 

[dscline]

I can only second the need to have additional logging.

It would be great if we could write rules that would log any string. Yes, I know there are memory limits..

Yes, I wish it was like my router, that has settings to set the amount of detail that gets logged (like basic or extended), and the ability to set up a log server to deal with the memory issue. There are all kinds of things that happen (or should be happening) that I'd like to be able to confirm: how often, if ever, do my wireless sensors miss a supervision check-in (are they on the fringe of reception, or very reliable?), more detail on the time stamps (if they were down to the second, than this "bug" that I seem to be experiencing would be easier to identify... obviously two different doors that are 50 feet apart couldn't easily be tripped the same second), when do rules trip (is my logic wrong? did the x10 signal just not get received? did the elk mess up?) There are so many things that happen that aren't logged (that I've found) that would be so helpful in troubleshooting. Being able to save them to a remote server would solve the memory issue, and make it easy to sort/filter. I bet many people who who buy an Elk probably have at least one computer that runs 24x7. Heck, I can't even find an easy way to get the log data out of the system. I couldn't find a way to export, or even cut/paste from ElkRP. To provide the example I did in my other thread, I had to print then scan the print-out. Of course, I've only had it for a month, so there may be things I just haven't figured out yet. :lol:

 

[gcimmino]

Well, there is some hope for getting the data out of the log. Use the ld (lower case LD) command to retrieve one row from the log table. You'll find the details in the M1 ASCII protocol docs.

You can establish a stunnel to the XEP and then it will pass the commands onto the M1.

 

[FrankMc]

Hi Guys

Is it possible that when an alarm occurs on a zone that it also trips the E/E Zone ( entry/exit) ...??? Wonder if this is happening with other users...?? Strange....

Looks like from the log the alarm did not get through to the monitoring company....

Frank

 

[dscline]

Is it possible that when an alarm occurs on a zone that it also trips the E/E Zone ( entry/exit) ...??? Wonder if this is happening with other users...?? Strange....

Looks like from the log the alarm did not get through to the monitoring company....

Yes, every time this has happened to me, it's been an E/E zone that was falsely tripped. But it doesn't happen EVERY time, and it's not always the same E/E zone that gets tripped. And sometimes it pulls two in with it, and sometimes just one.

 

[Digger]

Mine have been E/E Zones also. Now it really sounds like firmware to me. And maybe just the log is affected.

 

[dscline]

And maybe just the log is affected.

No, it's not just the log. They are also getting reported. The whole reason I'm noticing this is because it's causing alarms to my monitoring station. The zones that are triggering the "cascading" trips are set up with the monitoring station as "log only". However, e/e zones are erroneously and sporadically getting reported too, and when THAT happens, they call the police. Since I've not been home when I've known about it happening, I don't know if the siren is going off too. The trigger zones are set up as silent, so it shouldn't, but I don't know if the siren is getting triggered due to the incorrect trip of the e/e zones.

 

[Digger]

Hmmmm.......... then "Houstan we have a problem" (sorry Jim not you). Elk is closed until July 10th I believe. I to am leaving for a long vacation in a few days. Fortunately I guess I was not able to find a Central Station that accepted the ethernet connection (seems nobody can at the moment that will deal with a DIY).

Only option I can think is can you set it up not to report to the Central Station and just to your cell phone until this is corrected????

 

[dscline]

Hmmmm.......... then "Houstan we have a problem" (sorry Jim not you).  Elk is closed until July 10th I believe.

Spanky did respond to my thread reporting this issue. In fact, the first thing he did was state that the first zone in the report was the real trip, and he asked if the other zones were e/e zones. So it at least appears that they have some knowledge of the issue. He hasn't reappeared though, and the thread I posted on their forums has gone mostly untouched. I HOPE that means they are working on it, though other people in that thread seemed to have reported it in the past and haven't gotten it resolved. Hopefully when they return, they will look in to it some more. Accurately sensing and acting upon the status of zone changes is the most critical function of an alarm system, I certainly hope this has some reasonable level of priority.

Fortunately I guess I was not able to find a Central Station that accepted the ethernet connection (seems nobody can at the moment that will deal with a DIY).

I'm not sure I follow why that is a good thing... just to be clear, I'm not yet monitoring via IP either. The problem exists with my standard (POTS) reporting. Besides, since the error is showing up in the log as well, I don't think it has anything to do with how it's reported.

FWIW, NextAlarm did tell me they were actively looking in to alarm over IP, and another poster (maybe here, maybe another forum, can't remember) said they told him they expected to have it around the end of the summer. I certainly hope so.