Dilbert66
commented
3 years ago Make the changes below to have your panel identified. Yours sends 0x32 in byte3 (which is your panel version)
Actually, you have found a good thing here. Byte 3 is not as initially thought. Byte 3 is the panel version number. I have a different panel with version 4.6 and I have 0x46. Good. Now we have good way to identify panel version but we still need to identify panel type.
Edit: I agree with you that it seems that bit 3 of byte4 is a 6 digit code indicator. The code below will need to be modified to represent that.
for example your panel 5010 sends for byte4: 11101101. So we break it down to assumed sections:
bits4567(1110 ) bit3(1) bit2(1) bits01( 01)
It is assumed that bits01 are the termination type.
bit2 - unknown
bit3 - assumed 4/6 digit code type
bits4567 - unknown at this time
//0x16 processing:
//this should now be:
stream->print(F("Panel version: "));
stream->print(panelData[3],HEX);
/*
switch (panelData[3]) { //this is the panel version. Not panel model
case 0x10: stream->print(F("PC5015 ")); break;
case 0x11: stream->print(F("PC5016 ")); break;
case 0x22: stream->print(F("PC1565 ")); break;
case 0x23: stream->print(F("PC1555MX/PC585 ")); break; //make this change to add pc585 in the description
case 0x32: stream->print(F("PC5020 ")); break; // add this line to identify your panel correctly
case 0x41: stream->print(F("PC1832 ")); break;
case 0x42: stream->print(F("PC1864 ")); break;
default: stream->print(F("Unknown panel ")); break;
}
*/
switch (panelData[4] & 0x03) {
case 0x01: stream->print(F("| Zone wiring: NC ")); break;
case 0x02: stream->print(F("| Zone wiring: EOL ")); break;
case 0x03: stream->print(F("| Zone wiring: DEOL ")); break;
}
switch (panelData[4] >> 2) {
case 0x2C: stream->print(F("| Armed")); break;
case 0x2D: stream->print(F("| Interval 4m")); break;
case 0x34: stream->print(F("| Exit installer programming")); break;
case 0x39: stream->print(F("| Installer programming")); break; //this was your first 5020 example (4digit)
case 0x3B: stream->print(F("| Installer programming")); break; //add this line for your 2nd example (6digit), please note what the operation was at the time you saw this 016.
case 0x3C: stream->print(F("| Armed, Exit *8 +15s, Power-on +2m")); break;
case 0x3D: stream->print(F("| Interval 4m")); break;
default: stream->print(F("| Unknown data")); break;
}
}
kricon
taligentx
Thanks for creating and developing this project, I was amazed when first saw it year ago, but just now got time to get into the testing and write here. Im not new into electronic and microcontrollers, I had some programming experinces but never used github before and I'm pretty new when it comes to Arduino/IoT (this is my first time using/coding on arduino).
I have some panels (PC5020, PC1565-2P, PC585) and modules (RF5132 v5, PC5104, few PC5108) available for testing and giving feedback if needed to help further development because as I see it has not been tested with PC5020 before and also wireless/hardwired expanders is a thing in development nowadays.
As I use 6-digit code, using KeybusReader 0x16 cmd is showing unknown data, so I gave my shot at decoding protocol:
This is using master branch. If I use expander branch, PC5020 is identified as PC5005 panel. If I figured correctly, when byte 4, bit5 bit3 is true, system uses 6-digit codes, _and true status scrambles byte 4 sum for "switch (panelData[4] >> 2)"_. Its probably easy to fix it, but I give look and as for now I dont have enough knowledge to do it by myself.
I wonder is anybody decoded left-right buttons from LCD keypads? If not, maybe I can get my hands on one and look at serial output. Blynk really lack possibility to scroll left/right on lcd to view troubles, alarm memory and so on.
Im planning to use this project with Blynk for remotely monitor and control of my DSC panel in holiday house, which have wired and wireless expansions and I would like to be able to monitor as much data as possible so Im willing to help in reporting/decoding protocol as much as I can.
I have to thanks @Dilbert66 for helping me about script-typo which caused zone tamper being misreported and for recent updates on decoding pc5108/pc5208/rf5132 modules aswell as decoding memory buffer and trouble statuses which would be really nice If possible to implement it so I could, for example, find out if my system report zone sensor low battery (which often does as in winter there is freezing temperatures) or view memory buffer somehow.
It would be great if all that new findings will be included in new build (I see that @taligentx plans soon to revisit code, merge some things and hopefully release new version main branch. I'm testing PC5020 v3.2 and as for now, it works nicely so it can be added to list of supported panels.