Sur-Gard UDP data format

Anyone have any details on the DSC Sur-Gard IP data format supported by the ELK M1XEP?
 
I found the SIA DC-09 specs, but after dumping UDP events from my M1, it's clearly not using the SIA format.
 
I want to write a receiver to handle events that Alarm Relay doesn't want to receive. I don't mind trying to reverse-engineer the protocol, but it'd obviously be easier not to.

The protocol and specs are out there if you look hard enough. It's not a secret.
 
It'd be honestly a lot easier and faster to just pick up a cheap line card and software head end then port to whatever you need. Alarmsoft comes to mind.

Gonna be hard to hook up a card to a cloud server.

Software is out there already. Same with the protocol and documentation of them. How you pass the data to it is easy enough. Line card is the easiest, but other ways to skin the cat.
 
Didn't see a mention of a cloud server in the OP...but another downfall of the cloud. Can't do everything a VM or physical machine can.


 

What's your goal.  To sniff the XEP<>CS channel and look for additional indications?  Since you don't know the protocol, how do you know that there are items in the protocol that AlarmRelay doesn't handle?  Are you capturing PCAP's of the XEP<>CS?  Using wireshark?
 
I don't understand the cloud server point.  Your 'sniffing' machine/tool is cloud hosted?
 
FWIW: I'll be configuring an XEP for AlarmRelay within a week or two.  I'd be curious what the protocol looks like also...

$$ CASH BOUNTY $$
 
Nextalarm would let me send them open/close events and let me set up email triggers on those (or even the absence of them). The M1 can do that stuff with rules, but it mostly sucks due to the way email works with the rules. So I want to do it from Linux using a scripting language.
 
Alarm Relay won't let me send them open/close events. I can't even send them dialer tests more than once a month without paying extra. WTF? Also, they don't seem to be monitoring heartbeats. I've taken my Internet down for days at a time and they've never reached out to me. I'm not sure I could recommend them.
 
I want to write my own central station receiver so the M1 will pass those events to my own code... I'd send burglary and other real alarm events to Alarm Relay and other stuff to my own receiver.
 
If there is software or code or specifications out there for Sur-Gard UDP, I can't find it. I'd pay $10 in Bitcoin or Paypal to anyone who can find it.
 
I can find the M1 serial protocol which is available via the M1XEP and it's not what I'm after. That's my last resort solution for this.

3d0g:
  Why not allow the normal M1XEP -> AR communications send what it can, and then you handle the rest with rules and your scripting language?  If you don't like the Elk email support, move that to your script.  Open/Close events are not normal in a residential environment and of course AR would want to classify you as a business and charge more.
 
  Plus, I'd never want to put my own code in the middle of the main alarm reporting channel.  Leave that alone and add the extras on the side.  Writing reliable protocol handler code is not that simple.
 
  If Nextalarm works better, why not move to them?
 
  I'm hoping your $10 bounty is a joke. ^_^
 
  Just my $0.02

I'm not putting my own code in the middle. I agree that would not be advisable. You can define multiple central stations to report to and define which events get reported to each. You can also define backups.
 
The $10 bounty is for anyone who can show me where this code is. Someone earlier on in this thread said it's out there. What's funny about that? If it's out there, show me and get an easy ten bucks. I'm not asking anyone to develop anything.

OK.  I missed the fact that you can have multiple IP reporting 'communicators' on the XEP.. Still would seem easier to connect via the well documented XEP protocol and build whatever you need in your script.  is there something that not possible with the Serial/XEP protocol?  Shouldn't be, because that's the up-stream connection to the M1G panel.
 
DSC has a 'test' IP address where you can point the XEP to and the events are logged to a webpage.  How about pointing the XEP to there, and then capture PCAP's of the protocol.  It can't be that difficult.  And it would help with your script writing.  (to better understand the protocol).
 
 
Just thought of something else...  I read that the DSC protocol is encyypted.  That's going to hamper you efforts a bit.

Ooh, thanks!
 
The encryption is optional and Alarm Relay is not using encryption. It looks like DSC's test site does not use it either. Thank you for the pointer, I had not seen that before! This will make it easy to man-in-the-middle and see what is going on without impacting my primary communicator.
 
It's possible to do what I want with the Serial/XEP protocol, but I prefer using UDP for this purpose. It should be a lot simpler (aside from the documentation part). The reports are short and sweet and I won't have to maintain a TCP connection with the XEP or deal with ElkRP connections.