Start decoding Memory/Event buffer

[BriceDet]

Just finished first step of decoding the event buffer. I need now to catch others alarm zone event.

If somebody want to help me to complete, you're welcome!

[taligentx]

This is great, thanks for digging into decoding these messages! I'm going through the code for the next release and will merge once I can check out against a DSC panel (currently no access to one until November).

[BriceDet]

It stills have some holes in code list. Not sure with translation because of my training hardware (spare parts aftermarket bought only for this project). When I try to change the LCD5500 language, it reboot !

Hope to solved this issue before final merge ;-)

[kricon]

Its normal that LCD5500 / PK5500 reboots after changing language.

There is also one glitch with using LCD5500 on panels which supports RF interference/delinquency. If rf interference was detected, it will show you trouble condition, --> Wireless device low battery --> No zone with low battery --> No keys with low battery --> No keypads with low battery --> and when you press * another time, keypad reboots. On newer PK5500 it show RF interference and on which sensor it triggered. Everything works, just keypad reboots as probably cant process given data because RF interference didnt exist when LCD5500 was relased. Tested with RF5132 v3.13, which is some of last versions AFAIK (manufactured 2007 when new PK keypad series was already available).

[taligentx]

Hi @BriceDet - I noticed that other than byte 7, command 0xAA is very similar to 0xA5 and was able to consolidate the code to use the new printPanelTime() and to use the existing panel status messages in printPanelStatus0...printPanelStatus3. This lets the code fit on Arduino Uno, etc and should save the effort of deriving all of the status codes again. But kudos on getting so many decoded!

One future TODO is to go through those status messages and match them exactly with the DSC phrasing as seen in the event buffer or DLS, most of those were referenced against the IT-100 developer guide but comparing the same events against event buffer/DLS would be a better way.

For byte 7 that's currently labeled as "Index", do you see any other info on the keypads (or perhaps there's something in DLS) that corresponds to the value in byte 7? I'm not sure what it means as a straight decimal number - or perhaps the individual bits are different flags for the event buffer message? I'm not at all familiar with the event buffer so more logs/info would be great.

Also, are all of your example 0xAA messages for partition 1 or are these buffer events on multiple partitions? Byte 3 bit 6-7 (showing up as 01 in your examples) might be partition number for older panels that would only support 1 or 2 partitions, but not sure if this is a valid decoding - and would also mean different decoding for later panels with up to 8 partitions as they would need more bits.

Current 0xAA decoding:

/*
 *  0xAA: Event buffer
 *  CRC: yes
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 2 bit 0-3: Year digit 2
 *  Byte 2 bit 4-7: Year digit 1
 *  Byte 3 bit 0-1: Day digit part 1
 *  Byte 3 bit 2-5: Month
 *  Byte 3 bit 6-7: Partition (?)
 *  Byte 4 bit 0-4: Hour
 *  Byte 4 bit 5-7: Day digit part 2
 *  Byte 5 bit 0-1: Selects set of status commands
 *  Byte 6: Status, printPanelStatus0...printPanelStatus3
 *  Byte 7: Index (?)
 *  Byte 8: CRC
 *
 *             YYY1YYY2   MMMMDD DDDHHHHH MMMMMM
 *  10101010 0 00100001 01000110 00001000 00100100 00011100 11111111 01011000 [0xAA] Event buffer: 255 | 2021.01.16 08:09 | Zone alarm: 20
 *  10101010 0 00100000 01100110 10001101 00111000 10011001 00001000 10010110 [0xAA] Event buffer: 008 | 2020.09.20 13:14 | Armed by user code 1
 *  10101010 0 00100000 01100110 10001101 10011000 10011010 00000011 11110010 [0xAA] Event buffer: 003 | 2020.09.20 13:38 | Armed by user code 2
(...)
 *  10101010 0 00100000 01100110 10001100 11010110 11100110 00000000 01111000 [0xAA] Event buffer: 000 | 2020.09.20 12:53 | Enter *6 programming
 *  10101010 0 00100000 01100110 10101101 10010001 00101011 00000011 10011100 [0xAA] Event buffer: 003 | 2020.09.21 13:36 | Armed by auto-arm
 *  10101010 0 00100000 01100110 10101101 11000101 10101101 00000010 01010001 [0xAA] Event buffer: 002 | 2020.09.21 13:49 | Enter *8 programming
 *  10101010 0 00100000 01100110 10101101 11000101 10101100 00000001 01001111 [0xAA] Event buffer: 001 | 2020.09.21 13:49 | Exit *8 programming
 *
 */
void dscKeybusInterface::printPanel_0xAA() {

  stream->print(F("Event buffer: "));
  if (panelData[7] < 10) stream->print("00");
  else if (panelData[7] < 100) stream->print("0");
  stream->print(panelData[7], 0);
  stream->print(F(" | "));

  printPanelTime(2);

  stream->print(F(" | "));

  switch (panelData[5] & 0x03) {
    case 0x00: printPanelStatus0(6); return;
    case 0x01: printPanelStatus1(6); return;
    case 0x02: printPanelStatus2(6); return;
    case 0x03: printPanelStatus3(6); return;
  }
}

I'm pleasantly surprised that the event buffer is a straightforward add-on, thanks for digging into this! If you're up for digging into this further, it's not a problem to continue here in the PR but for better visibility you can open up a new Issue for event buffer decoding. Thanks for the contribution!

-Nikhil

[BriceDet]

I'm tired and a need to read again your comments 😅

Byte 7 is an unsigned integer to index the event in memory. The dsc memory deep is 256 event. When you scroll event with the LCD panel you found it. And when new event appears, index moved.

[taligentx]

Byte 7 is an unsigned integer to index the event in memory. The dsc memory deep is 256 event. When you scroll event with the LCD panel you found it. And when new event appears, index moved.

Okay, makes sense - I was trying to figure out how the index worked from the examples you provided, it sounds like the examples are from different panels or different logs because several have the same index.

[BriceDet]

Exactly : i done an extract to make relative different sample. To create a lot of different event is not so easy 😅

[kricon]

There is some weird symbol characters output into log instead of Byte7 mem.buffer event nr, and also unknown 0xEC cmd send afterwards (log taken from PC5020):

05:00:56.299 ->  8614.72: 11111111 1 10000111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: Right arrow
05:00:56.368 ->  8614.79: 10101010 0 00100000 00101101 01100011 10111101 10101100 00001011 11001110 [0xAA] Event buffer: 0 | 2020.11.11 03:47 | Exit installer programming
05:00:56.470 ->  8614.89: 11101100 0 00000000 00100000 00101101 01100011 10111100 00000001 10101100 00001011 00010000 [0xEC] Unknown data

When we talk about event buffer, and when its mostly decoded aswell as < > buttons for getting it, it would be nice to implement viewing event buffer from Blynk sketch.

[BriceDet]

Let me try to give you this new micro project 👍

[BriceDet]

@kricon : it's not the code what i've done. I don't understand fully the integration done by @taligentx I'll try to check missing parts and mistakes.