DSC Keybus Protocol

Go To Last Post
59 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to understand this protocol that my DSC 1555 alarm uses between the base and the keypad, but issue is its propriatary of some sorts. There was another thread about it on this forums but it ended prematurely with the guy just checking one bit for stay or away mode.

From what I know about this protcol so far the clock line runs at 1kHz with 50% duty and oddly enough only does so for 41.6ms then it stays high for 5.4ms and starts all over again. The data line seems to transistion on either the falling or rising edge of the clock (or in the middle), which led Kortuk of chiphacker.com to belive that it is NRZ encoding which I'm not sure of yet but here are some OLS dumps of the data and clock lines hopefully with teamwork we can figure this out.

I'm pretty sure the data is the same as whats listed in the PC5401 pdf below just sent via some weird protocol, all I really need help with is figuring out whats a 1 and whats a 0. From there I'm confident I can figure out the rest. Thanks for your time :D

0 is the Data line, 1 is the Clock

DSC OLS Dump
ECP Patent
PC5401 Dev-PDF
Previous AVRFreaks Thread

Last Edited: Sat. Mar 5, 2011 - 12:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a DSC system, but I've never bothered to investigate it. I assumed, since it's a 4 wire connection to all the keypads in parallel, that it used some kind of RS485 multi-drop protocol, or possibly I2C.

I'm not quite sure what I'm looking at in your .ols files - I assume bit 0 is one line and bit 1 is the other, but I can't make sense of the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot to mention 0 is Data and 1 is Clock

From what more I've read in patent 6868493 it appears that the actual MCU on the DSC alarm speaks RS485 then I'm guessing somewhere else it is changed into the propriatary ADEMCO ECP (Expanded Console Protocol)

The OLS files are for the OpenLogic Sniffer client

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The DSC keypads are so cheap, and so simple, that I find it hard to believe they could afford any external circuitry to change to a protocol not supported by the main chip. Of course we don't know what that is, since the chip is masked and proprietary. Maybe plotting out the clock and data on paper will make sense of it.

You have to go a long way down the "idle_test.ols" to find a state where both clock and data are low at the same time, and then it's only present for a couple of samples.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is true, I never thought about the keypad itself having to TX back to the base.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was in a similar situation with a DSC 1580 base central. I have no oscilloscope so I don't know the exact timings but I have figured out the protocol.

Signalling is made with a CLK line (yellow) and DATA line (green). The frequency is 1kHz. Base central acts as a master unit and all panels as slaves.
Before any command is sent by the master, a synchronization occurs where CLK is high for approx. 5-10 ms. After this, CLK is a square wave with 1ms cycle until all data bits has been sent followed by next synchronization.
The tricky part was to realize that data is sent bidirectionally between master and slaves at the same time. On falling CLK flanks, master sends a bit on DATA line and on rising CLK flanks, slave sends a bit.

I don't know the exact timing, but if I read DATA line 400us after CLK flank, it works for me.
I strongly suspect that a slave (panel) just has an open-drain on the DATA line, if nothing is sent it will read back as a logical 1.

Data sent by the master is mostly of the form:
Command (8 bits)
Zero padding (1 bit)
Data (x * 8 bits)
Checksum (8 bits)

Some commands don't have a checksum. It may be to support old panels as it seems that these are mostly followed by another command containing the same data and a checksum.

The checksum is a simple sum of the other bytes.
Slaves respond from the 9:th bit and onward.

For example, to detect which panels are available, master sends 0x11 as command. Each panel respond by sending two zeros at position 9 + ((slot-1) * 2) where slot is the programmed slot for that panel [1-8].

I hope this will be of help, I had no luck in finding any information about this protocol anywhere so I had to do it the hard way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some protocol details found by inspecting data and guessing:

Commands sent from master (first byte):

0x05 - Status update (no checksum, no zone info)
0x27 - Status update (extended version of the above, with checksum)
Second byte:
100EBMAR (LEDs: E=Error, B=Bypass, M=Memory, A=Armed, R=Ready)
Third byte:
text message code (0x01=Enter code, 0x03=Close all sections, 0x11=System armed ...)
Fourth byte:
always 0x01
Fifth byte:
always 0x81
Sixth byte:
Open zones 1-8

0xA5 - Time
(Offset is in bits starting with 0 including 1 bit zero-padding after 8 bit command)
Offset Length Data
9 4 Year digit 3
13 4 Year digit 4
19 4 Month
23 5 Day
28 5 Hour
33 6 Minute

0x11 - Query available keypads (no checksum)
Each keypad in slot 1-8 will respond with two zeros if present.
i.e. the response bits are:
aabbccddd ...
a = Keypad in slot 1 present
b = Keypad in slot 2 present
For example:
11110011 ... (Keypad in slot 3 present)

0x0A - Status in menu mode
0xC3 - no idea
0x16 - no idea
0x1C - emergency button acknowledge?
0x5D - alarm memory?
0xB1 - zone configuration?
0x64 - beep command
second byte:
0x06 - 3 short beeps
0x0a - 4 short beeps
0x0c - long beep

Response commands sent by keypads:

0xBB - Fire emergency button pressed
0xDD - Assistant emergency button pressed
0xEE - Police emergency button pressed

Second byte of the response is the pressed key:
xxxxxxcc (x = key, c = checksum)

Code for verifying checksum of the key:
unsigned int l_Key = p_Packet.m_Bytes[1] >> 2;
unsigned int l_ChkSum = p_Packet.m_Bytes[1] & 0x03;
bool l_bChkSumOk = ((((l_Key >> 4) & 0x03) + ((l_Key >> 2) & 0x03) + (l_Key & 0x03)) & 0x03) == l_ChkSum;

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MrBoard, what you posted until now has been true for me, and I want to share. I got and arduino sketch working to try to decipher the code. It works, but not for all possibilities. Code 0x5 works, and is being sent every second or so. Reading the info goes as follows:

Wait for a long HIGH clk signal. Then read data on every clk rise until message is finished.

I get data that seems really good, but I'm missing details. If somebody has more detail on how to interpret the data, I'll be really happy to know

Code is here:


#define CLK 11
#define DTA 12

String st;
String msg;

long ledActivity;

void setup()
{
  pinMode(CLK,INPUT);
  pinMode(DTA,INPUT);
  pinMode(13,OUTPUT);
  Serial.begin(9600);
  Serial.println("Start");
}

void loop()
{
    // Display led if no activity. Detect activity on bus
    if (millis() - ledActivity > 1000) digitalWrite(13,0); else digitalWrite(13,1);
  
    if (waitCLKchange(1) > 200)
    {
      // Message start detected
      
      st = "";
      msg = "";
      
      while (1)
      {
        // CLK is low. Let's wait until it goes up, max 500 usec.
        if (waitCLKchange(0) > 50) break;
        
        // CLK is high. Read a bit
        delayMicroseconds(100);
        if (digitalRead(DTA)) st += "1"; else st += "0";
        
        // Wait for CLK to drop again
        if (waitCLKchange(1) > 50) break;
      }
      
      // Get command number
      int cmd = getBinaryData(st,0,8);
      
      // Command 5 is status from panel. If we got a status, we got activity. Reset counter for inactvity for the LED
      if (cmd == 5 || cmd == 0x27) ledActivity = millis();
      
      if (cmd == 5)
      {
        int zones = getBinaryData(st,9+8+8+8,8);
        msg += "Zones " + String(zones);
      }
      
      // Interpret the TIME broadcast
      if (cmd == 165)
      {
        int year3 = getBinaryData(st,9,4);
        int year4 = getBinaryData(st,13,4);
        int month = getBinaryData(st,19,4);
        int day = getBinaryData(st,23,5);
        int hour = getBinaryData(st,28,5);
        int minute = getBinaryData(st,33,6);
        msg += "Date: 20" + String(year3) + String(year4) + " " + String(month) + " " + String(day) + " " + String(hour) + ":" + String(minute);
      }
      
      
      // Send findings to USB port
      if (cmd != 0 && st != "00000101010000001000000010000000011000111000000001100011100000000110001111")
      {
        Serial.print(st);
        Serial.print(" ");
        Serial.print(cmd);
        Serial.print(" ");
        Serial.print(msg);
  
        Serial.println("");
      }
    }
    
}


int waitCLKchange(int currentState)
{
  int c = 0;
  while (digitalRead(CLK) == currentState)
  {
    delayMicroseconds(10);
    c++;
    if (c > 1000) break;
  }
  return c;
}


int getBinaryData(String st, int offset, int length)
{
  int buf = 0;
  for(int j=0;j
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can also confirm that my PC1616 DSC panel sends data on the CLK line going UP (HIGH), and that the keypads respond on the CLK line going down.

Here is a sample of data coming from the panel.

00000101 0 10000000 00000011 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 3
00000101 0 10000001 00000010 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 2
00000101 0 10000000 00000011 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 4
00000101 0 10000001 00000010 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 1
00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1 no zone
00000101 0 10000011 00001000 00000000 11000111 00000000 11000111 00000000 11000111 1 arm delay
00000101 0 10000011 00001000 00000000 11000111 00000000 11000111 00000000 11000111 1 arm delay short beeps
00000101 0 10000010 00000101 00000000 11000111 00000000 11000111 00000000 11000111 1 armed

For the life of me, the "normal no zone trespassed" string I've verified many times, but I can't understand why I don't see zeros for the third group of bits.

If someone smarter than me figures it out, I'll be happy to know where I'm wrong.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Amazing freaks have about everything figured out!

 

277,232,917 -1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Here is the circuit I built to connect the arduino to the DSC Keybus:

Then, here is the Arduino code. Completely rewritten to use interrupt on pin 2 (interrupt 0), because otherwise it seems too slow to be able to receive all messages

#define CLK 2
#define DTA 4

String st, old;
unsigned long lastData;

void setup()
{
  pinMode(CLK,INPUT);
  pinMode(DTA,INPUT);
  pinMode(13,OUTPUT);
  Serial.begin(57600);
  Serial.println("Start");
  
  // Interrupt 0 = PIN 2 externe
  attachInterrupt(0,clkCalled,RISING);
}

void loop()
{
  if (millis() - lastData > 500)
    digitalWrite(13,0); 
  else 
    digitalWrite(13,1);
  
  if (waitCLKchange(1) < 2000) return;
  String stc = st;
  st = "";
  
  int cmd = getBinaryData(stc,0,8);
  if (cmd == 0x05) lastData = millis(); // Reset led counter
  
  if (stc == old) return;
  if (cmd == 0) return;
  
  old = stc;
  
  String msg;
  
  // Interpreter les donnees
  if (cmd == 0x05)
  {
    if (getBinaryData(stc,12,1)) msg += "Error";
    if (getBinaryData(stc,13,1)) msg += "Bypass";
    if (getBinaryData(stc,14,1)) msg += "Memory";
    if (getBinaryData(stc,15,1)) msg += "Armed";
    if (getBinaryData(stc,16,1)) msg += "Ready";
  }
  
  if (cmd == 0xa5)
  {
    int year3 = getBinaryData(stc,9,4);
    int year4 = getBinaryData(stc,13,4);
    int month = getBinaryData(stc,19,4);
    int day = getBinaryData(stc,23,5);
    int hour = getBinaryData(stc,28,5);
    int minute = getBinaryData(stc,33,6);
    msg += "Date: 20" + String(year3) + String(year4) + "-" + String(month) + "-" + String(day) + " " + String(hour) + ":" + String(minute);
  }
  if (cmd == 0x27)
  {
    msg += "Zones: ";
    int zones = getBinaryData(stc,8+1+8+8+8+8,8);
    if (zones & 1) msg += "1";
    if (zones & 2) msg += "2";
    if (zones & 4) msg += "3";
    if (zones & 8) msg += "4";
    if (zones & 16) msg += "5";
    if (zones & 32) msg += "6";
    if (zones & 64) msg += "7";
    if (zones & 128) msg += "8";
  }
  
  Serial.print(formatDisplay(stc));
  Serial.print("-> ");
  Serial.print(cmd,HEX);
  Serial.print(":");
  Serial.println(msg);

}

void clkCalled()
{
  if (st.length() > 200) return; // Do not overflow the arduino's little ram
  if (digitalRead(DTA)) st += "1"; else st += "0";
}

unsigned long waitCLKchange(int currentState)
{
  unsigned long c = 0;
  while (digitalRead(CLK) == currentState)
  {
    delayMicroseconds(10);
    c += 10;
    if (c > 10000) break;
  }
  return c;
}

String formatDisplay(String st)
{
  String res;
  res = st.substring(0,8) + " " + st.substring(8,9) + " ";
  int grps = (st.length() - 9) / 8;
  for(int i=0;i

This way, I get codes 0x05, 0x27 0xa5 and others. Seems to work well. The code is not complete though, because I still need to make events happen (for example, disconnect the battery) and find out how to identify these events from the data the DSC spits out.

If somebody was to redo this, please share information about what you get out of it, I'd be really interested.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

riviera65 wrote:
Then, here is the Arduino code. Completely rewritten to use interrupt on pin 2 (interrupt 0), because otherwise it seems too slow to be able to receive all messages
Thanks for your code, riviera65, I'm using it to decode my own DSC unit, I think I have discovered some new information. I want to know which Access code arms and disarms, and I believe the information is encoded on the 0xA5 time/status line. Following the time are two zero bits, then bits 41-48 seem to indicate whether a system is being armed or disarmed, and by whom. Bits 41&42 are 0x02 for arming, and 0x03 for disarming. Subtracting 0x99 from the arming code and 0xC0 from the disarm code reveal the Access code (01..32, and master code 40 is represented as following duress code 34). Some examples, the first line is the entire string, the following are just the 8 bits pointed at:

10100101 1 0001 0010 01 1100 00010 00010 010101 00 10011001 11111111 01010101 1
0xA5:Date:2012-12-2 2:21                           ^^^^^^^^
10011001 is arming, user code 01
11000000 is disarming, user code 01
10100000 is arming, user code 01
11000111 is disarming, user code 08
10111011 is arming, master code (i.e. "35")
11100010 is disarming, master code (i.e. "35")

8 bits of ones follow a user code, plus another 8 bits unless it's a master code. Both sequences are then followed by a single bit (usually 1). I haven't been able to decode the last full byte for a user code (preceding the 1 bit).
Can anyone duplicate these findings?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Arduino_rich,

I reproduced your idea on my system.

   DDDDDDDD  DDDDDDDDDDDDDDDDDDDDA
a5:00010010011011101101000111101110100110110000000001111111 ARM user 0
a5:00010010011011101101001000011010100110110000000010101100 ARM user 1
a5:00010010011011101101001000001110100110110000000010100000 ARM user 2
a5:00010010011011101101001000100010100110110000000010110100 ARM user 40
a5:00010010011011101101001000001100110000000000000011000011 DISARM user 1
a5:00010010011011101101001000000000110000010000000010111000 DISARM user 2
a5:00010010011011101101001000100000111000100000000011111001 DISARM user 40

In this data, these are the a5 packets I received for different events. The first line identifies with the D which bits are used for Date and time (this I'm sure), The A is probably the Armed status (not completely sure yet). But, for the remaining bits (the last eight), I can't say I'm sure I get the same thing you do, and I'm not able to get the user number from those. Maybe you can? I'm still trying to make sense out of it though. I'll post other details if I finally get the enlightenment... ;)

Edit: Please disregard this example, I think I did not take the right A5 message, since when I arm the system, I get one first A5 message when the code is entered, and then another one when the exit delay has expired and the system is really armed. This is the second A5 that I displayed in the example above, and the first one seems better. Here is the first one:

   DDDDDDDD  DDDDDDDDDDDDDDDDDDDDA
a5:00010010011011101101000111101100101111110000000010100001 BEFORE ARM user 0
a5:00010010011011101101001000011000100110010000000010101000 BEFORE ARM user 1
a5:00010010011011101101001000001100100110100000000010011101 BEFORE ARM user 2
a5:00010010011011101101001000100000101110110000000011010010 BEFORE ARM user 40
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More info found.

   DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA   UUUUUU
a5:00010010011011101101000111101100101111110000000010100001 BEFORE ARM user 0
a5:00010010011011101101000111101110100110110000000001111111 ARM user 0
a5:00010010011011101101001000011000100110010000000010101000 BEFORE ARM user 1
a5:00010010011011101101001000011010100110110000000010101100 ARM user 1
a5:00010010011011101101001000001100100110100000000010011101 BEFORE ARM user 2
a5:00010010011011101101001000001110100110110000000010100000 ARM user 2
a5:00010010011011101101001000100000101110110000000011010010 BEFORE ARM user 40
a5:00010010011011101101001000100010100110110000000010110100 ARM user 40
a5:00010010011011101101001000001100110000000000000011000011 DISARM user 1
a5:00010010011011101101001000000000110000010000000010111000 DISARM user 2
a5:00010010011011101101001000100000111000100000000011111001 DISARM user 40


   DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA     B
a5:00010010001011101101001010100000111001111111111100111101 Battery disconnect
a5:00010010001011101101001010101100111011111111111101010001 Battery reconnect

In this data, I think I identified by PP the partition number. When this number is partition 1, we get a user (U section) in this weird encoding that I still have to figure out (I know you did, but I'm still stumped)

If we get partition 0, then the information is not a user but an error status (see how the B byte could be battery error, I'll have to get more data)

The hunt continues... ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mcd1992 wrote:
I am trying to understand this protocol that my DSC 1555 alarm uses between the base and the keypad, but issue is its propriatary of some sorts. There was another thread about it on this forums but it ended prematurely with the guy just checking one bit for stay or away mode.

From what I know about this protcol peimar led lights so far the clock line runs at 1kHz with 50% duty and oddly enough only does so for 41.6ms then it stays high for 5.4ms and starts all over again. The data line seems to transistion on either the falling or rising edge of the clock (or in the middle), which led Kortuk of chiphacker.com to belive that it is NRZ encoding which I'm not sure of yet but here are some OLS dumps of the data and clock lines hopefully with teamwork we can figure this out.

I'm pretty sure the data is the same as whats listed in the PC5401 pdf below just sent via some weird protocol, all I really need help with is figuring out whats a 1 and whats a 0. From there I'm confident I can figure out the rest. Thanks for your time :D

0 is the Data line, 1 is the Clock

DSC OLS Dump
ECP Patent
PC5401 Dev-PDF
Previous AVRFreaks Thread

I have used system many a times but never tried to learn the protocol

Last Edited: Tue. Dec 11, 2012 - 10:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are some code changes to the Nov 16, 2012 - 03:41 PM post which should help with the user codes,
Add this to the end of the "if (cmd == 0xa5)" section:

    int arm = getBinaryData(stc,41,2);
    int master = getBinaryData(stc,43,1);
    int user = getBinaryData(stc,43,6); // 0-36
    if (arm == 0x02) {
      msg += " armed";
      user = user - 0x19;
    }
    if (arm == 0x03) {
      msg += " disarmed";
    }
    if (arm > 0) {
      if (master) msg += " master code"; else msg += " user";
      user += 1; // shift to 1-32, 33, 34
      if (user > 34) user += 5; // convert to system code 40, 41, 42
      msg += " " + String(user);
    }

The 0xa5 armed message is received after the exit delay when the system switches off ready to armed. The disarm message is received immediately upon disarming. On my system I receive a date message every four minutes regardless of arming/disarming, so disregard that one for this user information. I think your "A" bit should be two bits long and is two bits later than your code sample. Note that it is followed by 8 zeros and then another 8-bit message which I can't determine. Also make sure your user codes are unique, if you post the same 4 digit pin for two user codes I believe it only finds the first one.

add this to the "if (cmd == 0x05)" section for a possible power fail indicator:

  if (getBinaryData(stc,28,1)) msg += "power fail? ";
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,
This is really great information. I've always wanted to interface with the Keybus protocol.
Some questions:
Do you know if the alarm is always the "master" and keypads are slaves?
When do slaves talk in the bus?

Thanks
Jose

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How can I write TO keybus? How to simulate a keypad sending keystrokes to the panel?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,my name is Federico. i have an Logic Analizer Tektronix TLA704 in order to help in the proyect.
me i captured some frames the CLK and DATA for sharing.
follow in the proyect?

Thanks and I am at your disposal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This guy made a simple solution at http://www.juliano.com.br/dsc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice info ..
But there is no source .... Only a hex

Would you by any "chance" be related to "This guy" .....

Your username is jpessini and http://www.juliano.com.br/ refers to a Juliano Zabero Pessini

If you are .. you might ask your "relative" to release the sourcecode :wink: :wink:

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello! I am also studying the bus DSC 5010, and I can not understand the purpose of the last bit in the package ..I want to use the keyboard in my project. So far only got to control LED ARM READY

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With the help of a synthesizer package I learned the purpose of each status bit
7- BACKLIGHT
6- FIRE
5- PROGRAM
4- TROUBLE
3- Bypass
2- Memory
1- Armed
0- Ready

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

0x27 - Status update zone 1-8
0x2D - Status update zone 9-16
0x5D - alarm memory group1
0x63 - alarm memory group2
0xB1 - zone configuration, next byte allowed zone
0x64 - beep command group1
0x69 - beep command group2

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The details in this forum are great. Wondering if anyone has made any more progress in opening up the keybus protocol for all?

I wonder if we should start a wiki page on it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys! This is very interesting and helpful for my project. Is there anything new on the matter?

Thx!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello to all.
Full information on this topic, but unfortunately the NT-COM solution Juliano does not fit my network architecture model.
I have to attach a GSM module and ethernet, and I can not have a functional Sketch for Keybus part.
Code Julianno (http://dsc.juliano.com.br/howto/default.htm)
is too truncated to be exploitable.
So you have to start almost from scratch.
Someone managed to implement something functional?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have DSC PC-1500, I found CLK(yellow) and Data(Green) wire have different output.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The PC1500 is older. The keybus is very simple. On negative edge of the first eight is for the keypad data, the positive edge for the 16  is for the zone data followed by the status.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi! I'm back from the dead it seems... I realized the code I posted working with interrupts was truncated, so I'm trying again to post it. I made changes though, this code sends the info to the IP 192.168.1.2 in UDP format, that I capture back on my linux machine by listening on port 1234 with nc ( nc -u -l 1234)

 

#define CLK 3
#define DTA 4

#include <SPI.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <dns.h>
#include "crc32.h"

#define DEVICEID "0952"

char hex[] = "0123456789abcdef";
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x02 };

EthernetUDP udp;
IPAddress serverIP;

String st, old;
unsigned long lastData;
char buf[100];

void setup()
{
  pinMode(CLK,INPUT);
  pinMode(DTA,INPUT);
  Serial.begin(57600);
  Serial.println("Booting");
 
  while (!Ethernet.begin(mac)) Serial.println("DHCP error");
  print_dhcp();
 
 
  // Interrupt 1 = PIN 3 external
  attachInterrupt(1,clkCalled,RISING);
  DNSClient dns;

 
  udp.begin(1234);
 
  Serial.println("Ready!");
}

void loop()
{
  if (millis() - lastData > 500)
    digitalWrite(13,0);
  else
    digitalWrite(13,1);
 
  if (waitCLKchange(1) < 2000) return;
  String stc = st;
  st = "";
 
  int cmd = getBinaryData(stc,0,8);
  if (cmd == 0x05) lastData = millis(); // Reset led counter
 
  if (stc == old) return;
  if (cmd == 0) return;
 
  old = stc;
 
  String msg;
 
  // Interpreter les donnees
  if (cmd == 0x05)
  {
    if (getBinaryData(stc,12,1)) msg += "Error";
    if (getBinaryData(stc,13,1)) msg += "Bypass";
    if (getBinaryData(stc,14,1)) msg += "Memory";
    if (getBinaryData(stc,15,1)) msg += "Armed";
    if (getBinaryData(stc,16,1)) msg += "Ready";
  }
 
  if (cmd == 0xa5)
  {
    int year3 = getBinaryData(stc,9,4);
    int year4 = getBinaryData(stc,13,4);
    int month = getBinaryData(stc,19,4);
    int day = getBinaryData(stc,23,5);
    int hour = getBinaryData(stc,28,5);
    int minute = getBinaryData(stc,33,6);
    msg += "Date: 20" + String(year3) + String(year4) + "-" + String(month) + "-" + String(day) + " " + String(hour) + ":" + String(minute);
  }
  if (cmd == 0x27)
  {
    msg += "Zones: ";
    int zones = getBinaryData(stc,8+1+8+8+8+8,8);
    if (zones & 1) msg += "1";
    if (zones & 2) msg += "2";
    if (zones & 4) msg += "3";
    if (zones & 8) msg += "4";
    if (zones & 16) msg += "5";
    if (zones & 32) msg += "6";
    if (zones & 64) msg += "7";
    if (zones & 128) msg += "8";
  }
 
  Serial.print(formatDisplay(stc));
  Serial.print("-> ");
  Serial.print(cmd,HEX);
  Serial.print(":");
  Serial.println(msg);
 
  udp.beginPacket(IPAddress(192,168,1,2),1234);
  String stf = formatSt(stc);
  stf.toCharArray(buf,100);
  udp.write(buf);
  udp.write(10);
  udp.endPacket();

}

void clkCalled()
{
  if (st.length() > 200) return; // Do not overflow the arduino's little ram
  if (digitalRead(DTA)) st += "1"; else st += "0";
}

unsigned long waitCLKchange(int currentState)
{
  unsigned long c = 0;
  while (digitalRead(CLK) == currentState)
  {
    delayMicroseconds(10);
    c += 10;
    if (c > 10000) break;
  }
  return c;
}

String formatDisplay(String &st)
{
  String res;
  res = st.substring(0,8) + " " + st.substring(8,9) + " ";
  int grps = (st.length() - 9) / 8;
  for(int i=0;i<grps;i++)
  {
    res += st.substring(9+(i*8),9+((i+1)*8)) + " ";
  }
  res += st.substring((grps*8)+9,st.length());
  return res;
}

unsigned int getBinaryData(String &st, int offset, int length)
{
  int buf = 0;
  for(int j=0;j<length;j++)
  {
    buf <<= 1;
    if (st[offset+j] == '1') buf |= 1;
  }
  return buf;
}

String formatSt(String &st)
{
  String res = DEVICEID + String(";");
  res += String(hex[getBinaryData(st,0,4)]) + String(hex[getBinaryData(st,4,4)]) + String(";");
  int grps = (st.length() - 9) / 4;
  for(int i=0;i<grps;i++)
  {
    res += String(hex[getBinaryData(st,9+(i*4),4)]);
  }
  char buf[100];
  res.toCharArray(buf,100);
  unsigned long crc = crc_string(buf);
  res += String(";") + String(crc,HEX);
  return res;
}

void print_dhcp()
{
  Serial.print("IP:");
  Ethernet.localIP().printTo(Serial);
  Serial.print("/");
  Ethernet.subnetMask().printTo(Serial);
  Serial.print(" GW:");
  Ethernet.gatewayIP().printTo(Serial);
  Serial.print(" DNS:");
  Ethernet.dnsServerIP().printTo(Serial);
  Serial.println();
}

Last Edited: Mon. Dec 1, 2014 - 02:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everybody,

 

Here are my findings so far. Feel free to challenge them if you think I'm wrong.

 

Each message from the DSC panel has a message type of 8 bits, then 1 (stop) bit, then a variable number of bits depending of the message type.

All offsets in this list are calculated from the 9th bit. For example the following string:

00000101 1 0000111 we have 8 first bits, the type (0x05) and then 1 stop? bit, and then the data bits. All offsets will be relative to the data bits.

All items with an asterisk * after them need to be confirmed.

 

Message type 0x05 seems to be a status update which sends the status led update for the panels.

Offset 3, Error flag

Offset 4, Bypass flag

Offset 5, Memory flag

Offset 6, Armed flag

Offset 7, Ready flag

Offset 20, powerfail flag*

 

Message type 0xa5 seems a status update, happens every 4 minutes, or more often if a special message needs to be sent.

offset 0-3, Third digit of the year (the 1 in 2014)

offset 4-7, Fourth digit of the year(the 4 in 2014)

offset 10-13, month

offset 14-18, day

offset 19-23, hour

offset 24-29, minute

 

offset 8-9, partition number.

if partition is > 0, information about arm/disarm status as follows:

-offset 32-33, arm/disarm state. Will be 0x02 for arming, 0x03 for disarming

-offset 30-31, flag (name/function unclear). Needs to be 0 for a valid arming message.

-offset 34-39 user. You need to add 1 to this number to get user numbers.

if arming (arm/disarm state 0x02 and flag=0), user = user - 0x19. if user = 35, then user = 40. if user = 34 then user = 0

if disarming, if user = 35, user = 40

 

if partition = 0, then the information does not seem to concern users arming/disarming the system, but instead a general status of the system, like is the battery connected, is ac connected, etc. This needs to be looked upon further.

 

type 0x27

offset 39, zone 1 triggered flag

offset 38, zone 2 triggered flag

offset 37, zone 3 triggered flag

offset 36, zone 4 triggered flag

offset 35, zone 5 triggered flag

offset 34, zone 6 triggered flag

offset 33, zone 7 triggered flag

offset 32, zone 8 triggered flag

 

Somebody said that type 0x2d is the same as 0x27, but for zones 9-16. Needs confirmation

 

 

What needs to be done: What happens when an alarm is triggered, and how to detect it. I suspect it would be in a5 partition 0 data section, or in a brand new message I did not see before.

 

Also, need to identify errors (error in communication, battery error, etc) in 0xa5 partition 0.

Last Edited: Mon. Dec 8, 2014 - 06:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sentinel,

 

Do you have the individual offsets for these packets? Can you elaborate? I tried to post a complete list of codes and offsets, and I'd really appreciate if you could try to add what you know to it.

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!!! I recently started working with DSC Bus.  I got this:

 

 

Ejemplo 1 - Continuo

 

00000001 0    0x01
00010000    0x10
00000011    0x03
00010001    0x11
11000111    0xc7

 

1

 

Ejemplo 2 - Continuo    

 

00000101 0    0x05
01010100    0x54
00010001    0x11
01010001    0x51
11000111     0xc7

0

 

 

Ejemplo 3 - Evento

 

10100101 0    0xa5
00010010    0x12
01101100    0x6c
00100000    0x20
00010100    0x14
01001110    0x4e
00100001    0x21
11000110    0xc6    CheckSum ok

0

 

 

Ejemplo 4

01011101 0    0x5d
00000000    0x00
00000000    0x00
00000000    0x00
00000000    0x00
00000000    0x00
01011101    0x5d             checksum OK

0

 

A couple of years ago  I worked with   "a5" commands which have the information of the Event and the Programmed  Flash Event into the panel.  I make a list of many events related with the Contact ID generated.

But now I have to control the panel remotely using GPRS... so, I need to fully understand  the keypad protocol. I never needed to know who generated the A5 command... I use it to generate a Radio Report( related to my job).

Now I need to know when the master and slave writes on the BUS. Have any of you information about it???????

 

Thanks!

 

 

 

 

 

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you happened to find any more info on users for partition 0?  I'm particularly interested in getting that working but can't quite figure it out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys, thanks for all the effort in here! I successfully tested this out today but found that the submitted code higher up wasn't quite complete. Fortunately it was a minor task to put it together, so I've done that and published to Github.

 

https://github.com/emcniece/Ardu...

 

This version doesn't have the network communication, but does include the CRC32 error checking functions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I have succesfully tested your software with my PC585 and keypad PC1555RKZ . Have you made any further progress?
Have anyone made any intent to write to the bus? So as to activate, deactivate or send any command to the system.
Thanks. Regards.
Gonzalo

Last Edited: Wed. Mar 23, 2016 - 02:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Gustavo,

I´ve read you make a list of Contact ID events with the 0xA5 command, can you  send it to me?

I'm working whith the Slave whiting, if you want I can send some information as soon as possible.

Thanks.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is anyone still working on this code?  I'm trying to get the sketch working from the github and I'm finding that the timings might not be right.  Instead of getting the 9 blocks of binary I'm getting something like 24 so it looks like it's not seeing the sync on the clock.

 

Eventually I want to also read the falling clock to get the keypad presses and eventually be able to output.  Be willing to collaborate if anyone else is working on this.

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To get it work for me I had to change the interrupt from attachInterrupt(1,clkCalled,RISING); to attachInterrupt(digitalPinToInterrupt(CLK), clkCalled, RISING);

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found the problem.  I didn't have the panel ground connected to the arduino.  Once that was done things started working.

 

Couple of other questions, has anyone tried changing the interrupt to "CHANGE" instead of "RISING" and doing writing on the keybus and has anyone tried monitoring the keypad->panel traffic and decoding that?  I've changed the interrupt type and successfully watch for HIGH in the interrupt itself so that's fine, the next part would be to write to the keybus.  Would this clock low be where I'd monitor for other keypads that are sending?

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings, I just created an account so I could comment on this thread. I am very interested in this topic, and look forward to messing around with it as soon as my new dsc 1864 arrives. I am very much hoping that the scripts and code in this thread will transfer over to the 1864.

Regarding the previous post, in my initial research, preparing for this project, I've found this link:

https://github.com/dougkpowers/pc1550-interface

This guy has made a fairly nice library for arduino to talk with the dsc (though an older panel) and it communicates over both the key bus and pgm). It has the ability to emulate the key pad, and I'm sure it would be helpful with this project (if not a direct solution). Look forward to working with you guys.

Cheers

Stagf15

Arduino, NodeMCU, IR, Vera, Automation, etc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I started with the code from this thread rather than the pc1550-interface.  If you can get that one working I'd love to see the results on the 18xx panels.  I exchanged emails with the developer of it and he's not sure it will work on anything but the 1500 series.

 

One thing I have noticed from the code in this thread is when you let things run for a while the output starts getting mangled because the serial print can't keep up with the speed that the data is coming in and overwrites the item being decoded.  I'm in the process of working in QueueArray to allow new data to be pushed onto the queue without disrupting the item being processed.

 

I've also just about got the reading on low part working so you can see the messages that are going from keybus->panel also.  That was my first step before I start writing.  The other piece that has to be done is removing "delaymicroseconds" from the code.  This is a blocking timer which is fine if you just want to monitor the traffic but if you need to read button presses or other input to write it could cause issues.  Working on that too.

 

It's been years since I've done any serious C programming and the arduino platform is new to me so I'm quite slow so it can take me a while to find the right way to code something.  If you are a good coder maybe I can transfer some of the knowledge I've gotten in the last few weeks and the code changes will come quicker. :)

 

Another project that's good to look at is interfacing the Amazon Echo with a PI to control the panel.  This fellow has done some really good work in documenting the protocol.

https://github.com/goruck/all

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds awesome! I am actually a self taught python, then c ++ (arduino), and a little Javascript coder. So, no formal training. I would be glad to take a look at the code and try to tackle it together. Are you just working on the script or have you created a library to help handle things?

Either way, please point me in the best direction to get the most up to date code, and I will start looking at it. Do you have a github dedicated to the project that I could pull from?

As far as the serial printing, I see the script at the top of this thread prints at 57,600. Have you tried upping it to 115,200? That may reduce the log-jam that's happening...

Stagf15

Arduino, NodeMCU, IR, Vera, Automation, etc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to PM me we can exchange details to collaborate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, im new in this theme. For my job i need to make an arduino interface to conect a dsc power 1832 and i need to show in a console the zone status. Can anyone help me whit the code? i don`t know how to do it. I only need see the zone status, pls help!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code posted in this thread does just what you are looking for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ty for the code

Last Edited: Tue. Sep 13, 2016 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

some who understand this protocol can teach me about the third byte line? is the only one that i can`t understand. I only whant to know about that line in the 0x27 cases.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Isn't there any working "complete" code which can communicate with my DSC (PC585)?

 

So far this is the best what I found:

https://github.com/dougkpowers/p...

 

Unfortunately there is no web interface.

Two question:

1, in the project above there is no words about resistors while connecting to green/yellow wires. Is this OK?

For example this project uses 10k resistor between wires:

https://github.com/sjlouw/dsc-al...

2, should I disconnect the main power from the alarm while I am connecting my Arduino to the green/yellow wires? My alarm is on a hard to reach place and it would be more easier to connect from the keypad.

Last Edited: Tue. Oct 25, 2016 - 09:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keep in mind most DSC panels will not recognise your 'virtual keypad' unless it has a unique address AND this address has been registered in the panel.  The only way around this is to use the same address as a registered keypad, but physically remove the real keypad before you connect your device.

 

Now I did a little snooping around as this subject has been asked all over the internet, and I noticed that DSC has several modules that would allow you to connect your AVR project through it's usart interface to the Keypad bus.  They even provide rather decent documentation on the commands too.:

 

While I understand this avenue may not be as exciting as decoding the bus yourself, from what I read in the guides, I would think that a clever person would see how valuable one of these modules would be to assist you in accomplishing your goal.

 

Jim

Attachment(s): 

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

I was able to upload the code into the ESP8266 and make it to decode the protocol. It's working fine, but I still don't understand how to identify when the alarm is fired. 

 

 

I'm using this code: https://github.com/sjlouw/dsc-al....

 

Thanks in advance.

 

Fernando

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

hope anyone who's contributed to this thread is still around. 

 

I am trying to get either a PC1555 or LCD5501 keypad to communicate with an Arduino Uno. I have tried communicating per specs outlined in this thread (1kHz clock/data, command + 0 bit + data + checksum) but haven't been able to do so. Maybe I am miscalculating the checksum (0xff mask of sum of all bytes, including command?)

 

After a few seconds, the keypads light up their Trouble light and aren't responsive. Since I don't have a DSC alarm panel, I am unable to get any data but what I can get here and there online. Does anyone know if a specific sequence has to be sent to the keypads to get them to "think" there's a control panel connected?

 

Thanks in advance, and happy new year!

Last Edited: Sat. Dec 31, 2016 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to bust in on this party late, but what is the relation between the keybus and the pclink connection?  Doesn't the pclink connection use standard RS-232 from a computer's serial port?

 

So as another back door into the system, couldn't a code guessing program simply be used on pclink, bypassing the keypad lockout issue?  Has anyone done any analysis of pclink traffic?  Did I miss that somewhere above?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Guys,

 

Thanks for the project at https://github.com/sjlouw/dsc-alarm-arduino - Just want to find out if there's any news on the Virtual Keypad from Arduino?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

Any news about this project? I have pc5020, and code works, but i think it`s a little buggy with my alarm. When i  sabotage one of zones, i have a message like this

Quote:

 

Panel]  00100111 0 10000001 00000001 00000000 11000111 00000000 01110000 0 (OK)
20:29:07, 4/18/2017 27(39): [Zones A] Secure 
Time Synchronized
[Panel]  10100101 0 00010111 01010010 01010100 01110100 01011101 11111111 00110010 0 (OK)
20:29:00, 4/18/2017 a5(165): [Info] , User Code 30
[Panel]  11001110 0 00100000 01110100 01011101 00000000 00000000 10111111 0 (OK)
20:29:00, 4/18/2017 ce(206): 
[Panel]  00000101 0 10010000 00000011 00010000 11000111 00010000 11000111 00010000 11000111 1
20:29:00, 4/18/2017 05(5): [Status] Not Ready, Error
[Panel]  11101011 0 00000001 00010111 00010010 01010100 01110100 00000000 01011101 11111111 00111001 0 (OK)
20:29:00, 4/18/2017 eb(235): 
[Panel]  00000101 0 10010000 00000011 00010000 11000111 00010000 11000111 00010000 11000111 1
20:29:00, 4/18/2017 05(5): [Status] Not Ready, Error
[Panel]  01100100 0 00000100 01101000 0 (OK)
20:29:02, 4/18/2017 64(100): [3 Beeps] 
[Panel]  00000101 0 10010000 00000011 00010000 11000111 00010000 11000111 00010000 11000111 1

 

or this when second zone i remove resistor

 

 

Time Synchronized
[Panel]  10100101 0 00010111 00010010 01010100 10000000 00000000 00000000 10100010 0 (OK)
20:32:00, 4/18/2017 a5(165): [Info] 
[Panel]  00000101 0 10010000 00000011 00010000 11000111 00010000 11000111 00010000 11000111 1
20:32:00, 4/18/2017 05(5): [Status] Not Ready, Error
[Panel]  00100111 0 10010000 00000011 00010000 11000111 00000000 10010001 0 (OK)
20:32:03, 4/18/2017 27(39): [Zones A] Secure 
Time Synchronized
[Panel]  10100101 0 00010111 01010010 01010100 10000000 01111101 11111111 01011110 0 (OK)
20:32:00, 4/18/2017 a5(165): [Info] , Master Code 67
[Panel]  11001110 0 00100000 10000000 01111101 00000000 00000000 11101011 0 (OK)
20:32:00, 4/18/2017 ce(206): 
[Panel]  00000101 0 10010001 00000001 00010000 11000111 00010000 11000111 00010000 11000111 1
20:32:00, 4/18/2017 05(5): [Status] Ready, Error
[Panel]  11101011 0 00000001 00010111 00010010 01010100 10000000 00000000 01111101 11111111 01100101 0 (OK)
20:32:00, 4/18/2017 eb(235): 
[Panel]  00000101 0 10010001 00000001 00010000 11000111 00010000 11000111 00010000 11000111 1
20:32:00, 4/18/2017 05(5): [Status] Ready, Error
[Panel]  00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1
20:32:00, 4/18/2017 05(5): [Status] Ready
[Panel]  00010001 0 10101010 10101000 10101010 10101010 10101010 10101010 10101010 10
20:32:11, 4/18/2017 11(17): [Keypad Query] 
[Panel]  00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1
20:32:11, 4/18/2017 05(5): [Status] Ready
[Panel]  11100110 0 00101100 10000000 00000000 00000000 00000000 00000000 10010010 0 (OK)
20:32:26, 4/18/2017 e6(230): 
[Panel]  00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1
20:32:26, 4/18/2017 05(5): [Status] Ready
[Panel]  00010001 0 10101010 10101000 10101010 10101010 10101010 10101010 10101010 10
20:32:41, 4/18/2017 11(17): [Keypad Query] 

 

Is this normal? Any news about sterring the keypad from arduino?

Last Edited: Tue. Apr 18, 2017 - 06:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am trying to interface a pc1555rkz keypad with a micro. Using info from this thread. I was able to sound the beeper, and turn on the three top leds. 

But  can only get the zone leds to blink, didnt find a way to turn them on continuously.

Can anybody help me with this ?

I have used commands 05 and 27 for the leds and 64 for the beeper. The zone leds start to blink with command 5d.

If there is still interest in this subject I can post some of my findings.

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fernando,

Great you did this on the ESP8266 yes

 - Can you share the code?

 - have you figured out when the alarm is activated?

Last Edited: Tue. Mar 6, 2018 - 06:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings all,

 

Thanks for the excellent discussion detailing the Keybus clock and data lines.  I've written a library for Arduino and esp8266 that supports reading Keybus data, decoding system status, and writing as a virtual keypad (using an NPN transistor) with examples integrating with Apple HomeKit and Siri, MQTT, email, and push notifications with Pushbullet:

 

https://github.com/taligentx/dscKeybusInterface

 

This is an early release supporting zones 1-8 on one partition as seen on a PC1555MX panel.  The library reads the Keybus using hardware interrupts for the clock and timer interrupts for the data line to capture data 250us after the clock changes - this was necessary as I observed delays up to 160us for keypads to send data.  

 

At this point, I've decoded many of the commands listed in the DSC IT-100 Developers Guide and documented these with samples of the binary and the decoded message in src/dscKeybusPrintData.cpp

 

Further development for zones 9-64, multiple partitions, PC1616/PC1832/PC1864, and wireless modules will require logs of data from these panels, feel free to add an issue/pull request with logs, additions, and corrections - it'd be nice to get the library in a usable state for all DSC panels (including the classic series eventually, the dougkpowers/pc1550-interface library is functional but uses polling and blocking delays).

 

Cheers,

Nikhil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings,

 

DSC Keybus Interface 1.0 is now available in the Arduino IDE Library Manager and PlatformIO Library Registry:  https://github.com/taligentx/dscKeybusInterface

 

The library is now capable of decoding partitions 1-8 status, zones 1-64 status, and writing as a virtual keypad to partitions 1-8 across all PowerSeries panels.  See src/dscKeybusPrintData.cpp for the details of the protocol as I've decoded it so far - post a reply here or a Github issue if there are any sections that are unclear.  Ideally, the protocol information would be separately documented but I'll leave that to anyone interested.

 

I've also added a virtual keypad example for iOS and Android using Blynk.  Now that quite a bit of the protocol is decoded, the focus can move on to integrating with home automation and other software - there are lots of systems out there so this portion is up to anyone interested in working on a particular integration.  SmartThings and openHAB, for example, seem like useful targets.

 

-Nikhil