Elk M1G transmitting an "Unknown Event" to CS

[dw886]

Hi-
 
I'm in need of a little help.  My CS called me in the middle of the night last night, and asked if everything was OK.  When I said yes, and sounded surprised, they then asked "is your alarm going off?".  When I said "no", and asked what was up, they said that my panel (Elk M1G) was sending them notifications, but they didn't know what they were. 
 
They told me that it was transmitting "Unknown Events" to them, and that it was happening like once per minute.  I haven't added anything to the Elk system (I haven't touched anything outside of rules in the last 6 months, and I haven't touched any rules in the last 7 days).  Is there some deeper logging internal to the Elk that I can have a look at to understand what is being transmitted, and to try to associate it to a device?
 
They ignored the unknown event for 8 hours, and then started calling me again.  When I gave them a callback to troubleshoot, they told me that they've have to schedule an appointment for a tech to call me...the CS is going to call me back to troubleshoot as well, I just don't want to wait. 
 
Any help to point me in the right direction is appreciated - I'm just looking for a starting place.
 
Thanks!

 

[dw886]

OK, so I realize that I should have added a few more details in here.  Having a 6-month-old in your lap while you're typing is a little distracting. :nutz:
 
I ran through the "logs" that are in ElkRP, but they don't show anything for the past 7 days other than arming / disarming.  If I look at the "Status" button within ElkRP, everything looks normal.  I'm trying to see if I can get a log of everything that is being sent to the CS...
 
Anyone seen anything like this, and if not, is there any advice for how I can trap what is being sent, as well as isolating the cause?
 
Thanks!

 

[thill]

Here is a hunch.  If there's nothing in the event log then it might not be your control that is reporting to the CS. Is your control using the phone line for communicating with the CS?  if so then you could try unplugging from the phone line for just a short while and ask the CS is signals are still coming in.
It wouldn't be the first time someone made a typo while programming another panel and accidentally duplicated an account number (yours) that is already in use.  If this is what happened then the solution is to ask the CS for a new account number and reprogram your control.

 

[dw886]

I'm not using the phone line.  I'm using both IP reporting via an ELK M1XEP, and GSM as a backup.  I actually was thinking along the same lines.  I rebooted the M1XEP (the Ethernet communicator) last night, but left the control as-is.  I called into the CS this morning to see if they were still seeing the events, and the events stopped last night around the same time that I rebooted the M1XEP.
 
If the reboot fixed the issue, I hope that this doesn't start to be a common thing.  My wife didn't really like the middle of the night phone call.  I explained that it was a good thing, and shows that the CS is on top of everything...

 

[vc1234]

I'm not using the phone line.  I'm using both IP reporting via an ELK M1XEP, and GSM as a backup.  I actually was thinking along the same lines.  I rebooted the M1XEP (the Ethernet communicator) last night, but left the control as-is.  I called into the CS this morning to see if they were still seeing the events, and the events stopped last night around the same time that I rebooted the M1XEP.
 
If the reboot fixed the issue, I hope that this doesn't start to be a common thing.  My wife didn't really like the middle of the night phone call.  I explained that it was a good thing, and shows that the CS is on top of everything...

I am monitorng my elk with the following perl script fom my notebook (trying to figure out why my thermostat loses setpoint messages):

use ElkM1::Control;
use POSIX qw(strftime);

my $elkhost = '192.168.0.11';
my $elkport = 2601;
my $elkssl = 1;
my $elkdebug = 0;

$| = 1;
print strftime('%Y-%m-%d %H:%M:%S',localtime),"\r\n";
my $elk = ElkM1::Control->new('host' => $elkhost, 'port' => $elkport, 'use_ssl' => $elkssl, 'debug' => $elkdebug);
my $msg;

print strftime('%Y-%m-%d %H:%M:%S',localtime), " READY:\r\n";
while(1) {
$msg = $elk->readMessage();
$m = $msg ? $msg->toString : "No message";
print strftime('%Y-%m-%d %H:%M:%S',localtime), ' ', $m, "\r\n";
print "---\r\n";
}


 
Presumably, you should see the same events the  monitoring company does.

 

[Del91574]

You're not going to get much information from what is going on with the panel from your end...it's not going to help.
 
You need to know the raw data that the CS is receiving on their end, either via their automation software, or preferably, the receiver.

 

[dw886]

Thanks DEL.  I'm pretty much under the assumption that it was the M1XEP that was sending random notifications to the CS, and it wasn't originating from the panel.  After I rebooted the M1XEP, it hasn't happened since...
 
I have a scheduled call with a tech tomorrow, and I'll see if they can give me any more information.

 

[tadr]

Who's your CS?  Alarm Relay?

 

[dw886]

Yes

 

[Del91574]

the "unknown" event means their CS automation software is getting something that isn't templated, however the data is still going through the receiver, so the raw data would need to be known to determine what sort of event it actually is and then if there's an actual issue on their end (receiving valid data but not templated) of if there is something being transmitted by the XEP that is anomalous to what the m1 is seeing. 

 

[Gearhead]

Could also be a rogue IP reporting device using that duplicates your Account Number and DNIS.  You might see if Alarm Relay can give you the origination address of the alarm message or the MacID of the originating device.

 

[vc1234]

Could also be a rogue IP reporting device using that duplicates your Account Number and DNIS.  You might see if Alarm Relay can give you the origination address of the alarm message or the MacID of the originating device.

Mac address will be lost at the next router that connects the home network to the internet, though.
 
The most reliable way to see what is transmitted to the monitoring service via XEP would be to run a continuous trace with tcpdump/wireshark assuming the perl script above misses some IP packets.

 

[Del91574]

I would look to see what the CS is getting first....

Wouldn't be the first time I've heard of a non templated signal getting flagged. I wouldn't put the XEP as the cause yet and would put the reboot as coincidental right now.

 

[dw886]

So here's an update to this (and a vital piece of information that I missed earlier).  The "Unknown Event" was a communication from the Uplink unit and not the M1XEP (Yes, I currently have a GSM backup in the event that my M1XEP goes down, and should have said this earlier).
 
The CS tech agent said something along the lines of "since your uplink is tied to the bell circuit, it'll only notify us on an alarm event, so we'll have to take a look on our end to see what's wrong in the programming".  That was a red flag to me, since my Uplink is connected via serial cable (and can report anything that would normally go over the M1XEP).
 
At this point, it looks like this happened:

1. M1XEP lost communication with CS
2. Uplink took over, and tried to communicate *something* (probably the communication failure of the M1XEP)
3. CS doesn't have the correct programming for the Uplink, so didn't interpret the event correctly, since they thought that the Uplink was connected through the bell circuit
4. Uplink continued to transmit the same thing, over and over and over again
5. I rebooted the M1XEP, restoring communication with the CS
6. Alerts stopped

The tech agent is going to call Uplink, and go through all of the programming to make sure that it's correct...

 

[Del91574]

Wow....
 
They really screwed the pooch and negated the Uplink and any possible reporting that it could possibly have sent.
 
There's not much to the Uplink, which is what is really scary. Assuming they're porting the TCP/IP data directly from Uplink into the same CS receiver using the same basic account number into the virtual receiver.....well, there's no excuse and I'd be looking at a new CS.
 
It's a check box, literally, to enable the serial communications data to work on the Uplink, then put the account information, either the TCP/IP account information or POTS dialer emulation (if they're running multiple accounts for your CSID). The Uplink only sends what it gets, it's passthru.
 
Wow, it all I can say. I can't describe how bad they messed it up.