Dsc Serial Protocol
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. 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.
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.
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. 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 100000 110001 0000111 1 zone 3 00000101 0 100000 110001 0000111 1 zone 2 00000101 0 100000 110001 0000111 1 zone 4 00000101 0 100000 110001 0000111 1 zone 1 00000101 0 100000 110001 0000111 1 no zone 00000101 0 100100 110001 0000111 1 arm delay 00000101 0 100100 110001 0000111 1 arm delay short beeps 00000101 0 100010 110001 0000111 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.
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. 10100101 1 0001 00 0 0101101 01010101 1 0xA5:Date:2012-12-2 2:21 ^^^^^^^^ 10011001 is arming, user code 0 is disarming, user code 0 is arming, user code 1 is disarming, user code 1 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? DDDDDDDD DDDDDDDDDDDDDDDDDDDDA a5:111111 ARM user 0 a5:101100 ARM user 1 a5:100000 ARM user 2 a5:110100 ARM user 40 a5:000011 DISARM user 1 a5:111000 DISARM user 2 a5:111001 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.
DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA UUUUUU a5:100001 BEFORE ARM user 0 a5:111111 ARM user 0 a5:101000 BEFORE ARM user 1 a5:101100 ARM user 1 a5:011101 BEFORE ARM user 2 a5:100000 ARM user 2 a5:010010 BEFORE ARM user 40 a5:110100 ARM user 40 a5:000011 DISARM user 1 a5:111000 DISARM user 2 a5:111001 DISARM user 40 DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA B a5:111101 Battery disconnect a5:010001 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.;). 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 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 I have used system many a times but never tried to learn the protocol. 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. I recently started working with DSC Bus. I got this: Ejemplo 1 - Continuo 00000001 0 0x0 0x1 0x1 0x1 0xc7 1 Ejemplo 2 - Continuo 00000101 0 0x0 0x1 0x1 0x1 0xc7 0 Ejemplo 3 - Evento 10100101 0 0xa5 00010010 0x0 0x6c 00100000 0x0 0x0 0x4e 00100001 0x0 0xc6 CheckSum ok 0 Ejemplo 4 01011101 0 0x5d 00000000 0x0 0x0 0x0 0x0 0x1 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??????? 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? 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: 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. 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. Kabhi khushi kabhi gham mp3 songs free download doregama. 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. 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. Hi, Isn't there any working 'complete' code which can communicate with my DSC (PC585)?
So far this is the best what I found: 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. For example this project uses 10k resistor between wires: 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. 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). 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! 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: 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. 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. Greetings, DSC Keybus Interface 1.0 is now available in the Arduino IDE Library Manager and PlatformIO Library Registry: 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 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.
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. 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. 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. 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. 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 100000 110001 0000111 1 zone 3 00000101 0 100000 110001 0000111 1 zone 2 00000101 0 100000 110001 0000111 1 zone 4 00000101 0 100000 110001 0000111 1 zone 1 00000101 0 100000 110001 0000111 1 no zone 00000101 0 100100 110001 0000111 1 arm delay 00000101 0 100100 110001 0000111 1 arm delay short beeps 00000101 0 100010 110001 0000111 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. 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. 10100101 1 0001 00 0 0101101 01010101 1 0xA5:Date:2012-12-2 2:21 ^^^^^^^^ 10011001 is arming, user code 0 is disarming, user code 0 is arming, user code 1 is disarming, user code 1 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? DDDDDDDD DDDDDDDDDDDDDDDDDDDDA a5:111111 ARM user 0 a5:101100 ARM user 1 a5:100000 ARM user 2 a5:110100 ARM user 40 a5:000011 DISARM user 1 a5:111000 DISARM user 2 a5:111001 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. DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA UUUUUU a5:100001 BEFORE ARM user 0 a5:111111 ARM user 0 a5:101000 BEFORE ARM user 1 a5:101100 ARM user 1 a5:011101 BEFORE ARM user 2 a5:100000 ARM user 2 a5:010010 BEFORE ARM user 40 a5:110100 ARM user 40 a5:000011 DISARM user 1 a5:111000 DISARM user 2 a5:111001 DISARM user 40 DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA B a5:111101 Battery disconnect a5:010001 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.;). 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 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 I have used system many a times but never tried to learn the protocol.
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. I recently started working with DSC Bus.
I got this: Ejemplo 1 - Continuo 00000001 0 0x0 0x1 0x1 0x1 0xc7 1 Ejemplo 2 - Continuo 00000101 0 0x0 0x1 0x1 0x1 0xc7 0 Ejemplo 3 - Evento 10100101 0 0xa5 00010010 0x0 0x6c 00100000 0x0 0x0 0x4e 00100001 0x0 0xc6 CheckSum ok 0 Ejemplo 4 01011101 0 0x5d 00000000 0x0 0x0 0x0 0x0 0x1 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??????? 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?
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: 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.
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.
Dsc Serial Number
This fellow has done some really good work in documenting the protocol. 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. Hi, Isn't there any working 'complete' code which can communicate with my DSC (PC585)? So far this is the best what I found: 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. For example this project uses 10k resistor between wires: 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. 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.
Dsc Alarm Serial Communication Protocol
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).