dscKeybusInterface
dscKeybusInterface copied to clipboard
taligentx
Event buffer - logs requested to improve Keybus decoding
Continuing discussion from PR #155 for event buffer decoding thanks to the work by @BriceDet.
This issue is to decode the event buffer messages with logs of KeybusReader while accessing the DSC *6 event buffer with an LCD keyboard, noting any KeybusReader messages that are different than the DSC keypad display.
Panel commands 0xAA and 0xEC display event buffer messages, and seem to correspond to 0xA5 and 0xEB with an additional byte for an event index number.
Current 0xAA decoding - byte 3 bit 6-7 may be partition number but needs confirmation:
* 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: Unknown (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 5 bit 2-7: Minute
* Byte 6: Status, printPanelStatus0...printPanelStatus3
* Byte 7: Event number
* Byte 8: CRC
*
* YYY1YYY2 MMMMDD DDDHHHHH MMMMMM
* 10101010 0 00100001 01000110 00001000 00100100 00011100 11111111 01011000 [0xAA] Event: 255 | 2021.01.16 08:09 | Zone alarm: 20
* 10101010 0 00100000 01100110 10001101 00111000 10011001 00001000 10010110 [0xAA] Event: 008 | 2020.09.20 13:14 | Armed by user code 1
Current 0xEC decoding, byte 4 bit 6-7 may be partition but also needs to be checked:
* 0xEC: Event buffer - partitions 1-8
* CRC: yes
* Structure decoding: *incomplete
* Content decoding: *incomplete
*
* Byte 2: Partition
* Byte 3 bit 0-3: Year digit 2
* Byte 3 bit 4-7: Year digit 1
* Byte 4 bit 0-1: Day digit part 1
* Byte 4 bit 2-5: Month
* Byte 4 bit 6-7: Unknown (partition?)
* Byte 5 bit 0-4: Hour
* Byte 5 bit 5-7: Day digit part 2
* Byte 6 bit 0-1: Unknown
* Byte 6 bit 2-7: Minute
* Byte 7: Selects set of status commands
* Byte 8: Status, printPanelStatus0...printPanelStatus14
* Byte 9: Event number
* Byte 10: CRC
*
* YYY1YYY2 MMMMDD DDDHHHHH MMMMMM
* 11101100 0 00000000 00100000 00101101 01100011 10111100 00000001 10101100 00001011 00010000 [0xEC] Event: 011 | 2020.11.11 03:47 | Exit *8 programming
These commands seem to be mostly decoding other than the two mentioned bits - additional logs and feedback on this decoding would be useful to make sure it's being decoded correctly.
@BriceDet,
I don't understand fully the integration done by @taligentx
The 0xAA command that you decoded turns out to be nearly the same as the 0xA5 panel status command, but it has 1 additional byte for the event index number. So I was able to use the same decoding functions as 0xA5 (also used by 0xEB) to get the panel status messages. I only considered that this might be a duplicate of 0xA5 after seeing the status messages that you decoded, they looked familiar - so thank you for digging into this!
@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.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
Thanks, this should be fixed in develop and the log of the 0xEC command was also handy - this is another event buffer message for partitions 3-8 and similar to 0xEB, added this decoding as well for testing.
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.
With the decoding above this should be possible, added to the TODO list for the Blynk sketch.
I'm working on an .ino to show how to automatically get the full event buffer.
@kricon :It still have an error in the implementation of the event number (byte 7). Let me check the difference between my initial code and the final merge.
Current 0xAA decoding - byte 3 bit 6-7 may be partition number but needs confirmation:
Confirmed:
2224.73: 11111111 1 10000010 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: Enter in buffer memory
2224.98: 10101010 0 00100000 01110000 00100001 01110010 11100110 00000000 10110011 [0xAA] Event: 000 | 2020.12.01 01:28 | Enter *6 programming
2225.08: 11101100 0 00000001 00100000 00110000 00100001 01110000 00000010 11100110 00000000 10110110 [0xEC] Event: 000 | 2020.12.01 01:28 | | Partition 1 | Enter *6 programming
2237.64: 11111111 1 11111111 10000010 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 2 Key: Enter in buffer memory
2237.72: 10101010 0 00100000 10110000 00100001 01110010 11100110 00000000 11110011 [0xAA] Event: 000 | 2020.12.01 01:28 | Enter *6 programming
2237.84: 11101100 0 00000010 00100000 00110000 00100001 01110000 00000010 11100110 00000000 10110111 [0xEC] Event: 000 | 2020.12.01 01:28 | | Partition 2 | Enter *6 programming
Current 0xEC decoding, byte 4 bit 6-7 may be partition but also needs to be checked:
Byte4 bits6-7 remain low all the time no matter of the partition when I checked it thru partitions.
(does) It still have an error in the implementation of the event number (byte 7).
Thanks for help! But its fixed in latest develop commit, as author said in message above.
Some messages from event buffer log which are reported as Unknown data (or their decoded names differ from event buffer on keypads) that I took from panels:
131.34: 10101010 0 00001011 00000100 00100000 00000011 11111111 00000111 11100010 [0xAA] Event: 007 | 20011.01.01 00:00 | Unknown data //No entry (new panel)
131.43: 11101100 0 00000000 00001011 01000100 00100000 00000000 11111111 11111111 00000111 01100000 [0xEC] Event: 007 | 20011.01.01 00:00 | //No entry (new panel)
182.29: 10101010 0 00010010 00101000 10001100 11100011 11111111 10010101 11100111 [0xAA] Event: 149 | 2012.10.04 12:56 | Unknown data //EVENT 1BF1 (I dont know what it is, but its in log like that)
182.38: 11101100 0 00000000 00010010 00101000 10001100 11100000 00011011 11110001 10010101 00110011 [0xEC] Event: 149 | 2012.10.04 12:56 | //EVENT 1BF1 (I dont know what it is, but its in log like that)
5350.42: 10101010 0 00010010 01101000 10001101 00001001 11010001 10000111 00010010 [0xAA] Event: 135 | 2012.10.04 13:02 | Unknown data //Exit fault pre-alarm
5350.50: 11101100 0 00000001 00010010 00101000 10001101 00001000 00000001 11010001 10000111 00010101 [0xEC] Event: 135 | 2012.10.04 13:02 | | Partition 1 | Unknown data //Exit fault pre-alarm
5253.47: 10101010 0 00010010 00101000 10001011 01110000 11111010 01001100 00100101 [0xAA] Event: 076 | 2012.10.04 11:28 | Unknown data //Downloading Lead-in
5253.56: 11101100 0 00000000 00010010 00101000 10001011 01110000 00000000 11111010 01001100 01100111 [0xEC] Event: 076 | 2012.10.04 11:28 | Unknown data //Downloading Lead-in
5281.02: 10101010 0 00010010 00101000 10001011 01110100 11111011 01001011 00101001 [0xAA] Event: 075 | 2012.10.04 11:29 | Unknown data //Downloading Lead-out
5281.11: 11101100 0 00000000 00010010 00101000 10001011 01110100 00000000 11111011 01001011 01101011 [0xEC] Event: 075 | 2012.10.04 11:29 | Unknown data //Downloading Lead-out
317.59: 10101010 0 00010010 00101000 10001101 00001011 11111111 01111011 11110110 [0xAA] Event: 123 | 2012.10.04 13:02 | Unknown data //Exit fault
317.67: 11101100 0 00000001 00010010 00101000 10001101 00001000 00000100 10000111 01111011 11000010 [0xEC] Event: 123 | 2012.10.04 13:02 | | Partition 1 | Unknown data //Exit fault
342.21: 10101010 0 00010010 01101000 10001101 00001110 11000000 01110001 11110000 [0xAA] Event: 113 | 2012.10.04 13:03 | Unknown data //*1 access by user 40
342.30: 11101100 0 00000001 00010010 00101000 10001101 00001100 00000010 11000000 01110001 11110011 [0xEC] Event: 113 | 2012.10.04 13:03 | | Partition 1 | Unknown data //*1 access by user 40
797.01: 10101010 0 00011000 00011100 01010000 01000000 11110111 10110011 00011000 [0xAA] Event: 179 | 2018.07.02 16:16 | Unknown data //Phone number 1 FTC
797.10: 11101100 0 00000000 00011000 00011100 01010000 01000000 00000000 11110111 10110011 01011010 [0xEC] Event: 179 | 2018.07.02 16:16 | Unknown data //Phone number 1 FTC
797.51: 10101010 0 00011000 00011100 01010000 01011000 11111000 10110010 00110000 [0xAA] Event: 178 | 2018.07.02 16:22 | Unknown data //Phone number 2 FTC
797.60: 11101100 0 00000000 00011000 00011100 01010000 01011000 00000000 11111000 10110010 01110010 [0xEC] Event: 178 | 2018.07.02 16:22 | Unknown data //Phone number 2 FTC
798.03: 10101010 0 00011000 00011100 01100001 01011011 11111111 10110001 01001010 [0xAA] Event: 177 | 2018.07.03 01:22 | Unknown data //Periodic test with trouble
798.13: 11101100 0 00000000 00011000 00011100 01100001 01011000 00000100 10000110 10110001 00010100 [0xEC] Event: 177 | 2018.07.03 01:22 | Unknown data //Periodic test with trouble
1704.28: 10101010 0 00100000 00010111 10010110 00100100 11111110 11011101 01110110 [0xAA] Event: 221 | 2020.05.28 22:09 | Unknown data //Periodic test transmission
1704.36: 11101100 0 00000000 00100000 01010111 10010110 00100100 00000000 11111110 11011101 11111000 [0xEC] Event: 221 | 2020.05.28 22:09 | Unknown data //Periodic test transmission
4688.11: 10101010 0 00100000 00101010 01000000 01011110 10010001 00000110 00101001 [0xAA] Event: 006 | 2020.10.18 00:23 | Unknown data //Swinger shutdown
4688.20: 11101100 0 00000000 00100000 00101010 01000000 01011100 00000010 10010001 00000110 01101011 [0xEC] Event: 006 | 2020.10.18 00:23 | Unknown data //Swinger shutdown
1345.43: 10101010 0 00100000 00110000 00100000 00000011 00001010 00001001 00110000 [0xAA] Event: 009 | 2020.12.01 00:00 | Unknown data //PC5204 Supervisory trouble
1345.53: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000011 00001010 00001001 01110010 [0xEC] Event: 009 | 2020.12.01 00:00 | Unknown data //PC5204 Supervisory trouble
1422.80: 10101010 0 00100000 00110000 00100011 11010111 00001001 00010101 00010010 [0xAA] Event: 021 | 2020.12.01 03:53 | Unknown data //PC5204 Supervisory restore
1422.90: 11101100 0 00000000 00100000 00110000 00100011 11010100 00000011 00001001 00010101 01010100 [0xEC] Event: 021 | 2020.12.01 03:53 | Unknown data //PC5204 Supervisory restore
1368.49: 10101010 0 00100000 00110000 00100000 00000011 00000110 00001010 00101101 [0xAA] Event: 010 | 2020.12.01 00:00 | Unknown data //RF5132 Supervisory trouble
1368.59: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000011 00000110 00001010 01101111 [0xEC] Event: 010 | 2020.12.01 00:00 | Unknown data //RF5132 Supervisory trouble
1597.58: 10101010 0 00100000 00110000 00100011 10011111 00000101 00101111 11110000 [0xAA] Event: 047 | 2020.12.01 03:39 | Unknown data //RF5132 Supervisory restore
1597.68: 11101100 0 00000000 00100000 00110000 00100011 10011100 00000011 00000101 00101111 00110010 [0xEC] Event: 047 | 2020.12.01 03:39 | Unknown data //RF5132 Supervisory restore
1388.75: 10101010 0 00100000 00110000 00100000 00000010 11111111 00001100 00100111 [0xAA] Event: 012 | 2020.12.01 00:00 | Unknown data //Zone expander 1 Supervisory trouble
1388.85: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000010 11111111 00001100 01101001 [0xEC] Event: 012 | 2020.12.01 00:00 | Unknown data //Zone expander 1 Supervisory trouble
1638.44: 10101010 0 00100000 00110000 00100010 10001110 11111001 01000101 11101000 [0xAA] Event: 069 | 2020.12.01 02:35 | Unknown data //Zone expander 1 Supervisory restore
1638.55: 11101100 0 00000000 00100000 00110000 00100010 10001100 00000010 11111001 01000101 00101010 [0xEC] Event: 069 | 2020.12.01 02:35 | Unknown data //Zone expander 1 Supervisory restore
1515.40: 10101010 0 00100000 00110000 00100011 11010011 10110110 00011100 11000010 [0xAA] Event: 028 | 2020.12.01 03:52 | Unknown data //PC5204 AUX supply trouble
1515.51: 11101100 0 00000000 00100000 00110000 00100011 11010000 00000011 10110110 00011100 00000100 [0xEC] Event: 028 | 2020.12.01 03:52 | Unknown data //PC5204 AUX supply trouble
1444.68: 10101010 0 00100000 00110000 00100011 11010011 10110101 00011000 10111101 [0xAA] Event: 024 | 2020.12.01 03:52 | Unknown data //PC5204 AUX supply restore
1444.78: 11101100 0 00000000 00100000 00110000 00100011 11010000 00000011 10110101 00011000 11111111 [0xEC] Event: 024 | 2020.12.01 03:52 | Unknown data //PC5204 AUX supply restore
2022.10: 10101010 0 00100000 00011100 00110111 01110011 11111111 01001111 11011110 [0xAA] Event: 079 | 2020.07.01 23:28 | Unknown data //TLink Receiver trouble
2022.19: 11101100 0 00000000 00100000 01011100 00110111 01110000 00010100 11000100 01001111 00110110 [0xEC] Event: 079 | 2020.07.01 23:28 | Unknown data //TLink Receiver trouble
2099.83: 10101010 0 00100000 00011100 00110111 10111111 11111111 01001100 00100111 [0xAA] Event: 076 | 2020.07.01 23:47 | Unknown data //TLink Receiver restore
2099.91: 11101100 0 00000000 00100000 01011100 00110111 10111100 00010100 11000101 01001100 10000000 [0xEC] Event: 076 | 2020.07.01 23:47 | Unknown data //TLink Receiver restore
2808.11: 10101010 0 00100000 00011100 11000000 00001011 11111111 00001001 10111001 [0xAA] Event: 009 | 2020.07.06 00:02 | Unknown data //TLink network fault
2808.20: 11101100 0 00000000 00100000 01011100 11000000 00001000 00010100 11000010 00001001 00001111 [0xEC] Event: 009 | 2020.07.06 00:02 | Unknown data //TLink network fault
2830.90: 10101010 0 00100000 00011100 11000000 00000011 11111111 00000011 10101011 [0xAA] Event: 003 | 2020.07.06 00:00 | Unknown data //TLink communication fault
2830.99: 11101100 0 00000000 00100000 01011100 11000000 00000000 00010100 11000000 00000011 11111111 [0xEC] Event: 003 | 2020.07.06 00:00 | Unknown data //TLink communication fault
2144.74: 10101010 0 00100000 00011100 11000001 00110000 11101011 00110101 11110111 [0xAA] Event: 053 | 2020.07.06 01:12 | Unknown data //System AUX supply trouble
2144.82: 11101100 0 00000000 00100000 01011100 11000001 00110000 00000000 11101011 00110101 01111001 [0xEC] Event: 053 | 2020.07.06 01:12 | Unknown data //System AUX supply trouble
2985.09: 10101010 0 00100000 00011100 11000001 00110000 11110011 00110000 11111010 [0xAA] Event: 048 | 2020.07.06 01:12 | Unknown data //System AUX supply trouble restore
2985.18: 11101100 0 00000000 00100000 01011100 11000001 00110000 00000000 11110011 00110000 01111100 [0xEC] Event: 048 | 2020.07.06 01:12 | Unknown data //System AUX supply trouble restore
2297.42: 10101010 0 00100000 00101010 01000000 00010011 11111111 00011101 01100011 [0xAA] Event: 029 | 2020.10.18 00:04 | Unknown data //Fault restore, zone 40
2297.51: 11101100 0 00000001 00100000 00101010 01000000 00010000 00010111 01000111 00011101 00000010 [0xEC] Event: 029 | 2020.10.18 00:04 | | Partition 1 | //Fault restore, zone 40
2352.49: 10101010 0 00100000 00101010 01000000 00001111 11111111 00011111 01100001 [0xAA] Event: 031 | 2020.10.18 00:03 | Unknown data //Low battery Zone 35
2352.58: 11101100 0 00000001 00100000 00101010 01000000 00001100 00010111 00100010 00011111 11011011 [0xEC] Event: 031 | 2020.10.18 00:03 | | Partition 1 | //Low battery Zone 35
2383.38: 10101010 0 00100000 00101010 01000000 00000010 01100100 00100111 11000001 [0xAA] Event: 039 | 2020.10.18 00:00 | Unknown data //Keybus fault
2383.47: 11101100 0 00000000 00100000 00101010 01000000 00000000 00000010 01100100 00100111 00000011 [0xEC] Event: 039 | 2020.10.18 00:00 | Unknown data //Keybus fault
2252.85: 10101010 0 00100000 01101010 01000000 01000001 00100110 00010011 11101110 [0xAA] Event: 019 | 2020.10.18 00:16 | Auto-arm cancelled by master code 40 //User 40 log (*7 PGM access code)
2252.94: 11101100 0 00000001 00100000 00101010 01000000 01000000 00000001 00100110 00010011 11110001 [0xEC] Event: 019 | 2020.10.18 00:16 | | Partition 1 | Auto-arm cancelled by master code 40 //User 40 log (*7 PGM access code)
1315.71: 10101010 0 00100000 00110000 11111010 00001110 10001101 00000110 10010101 [0xAA] Event: 006 | 2020.12.07 26:03 | Power on //Warm start (power on while armed)
1315.82: 11101100 0 00000000 00100000 00110000 11111010 00001100 00000010 10001101 00000110 11010111 [0xEC] Event: 006 | 2020.12.07 26:03 | Power on //Warm start (power on while armed)
2416.20: 10101010 0 00100000 00101010 01000000 00000010 10001100 00101010 11101100 [0xAA] Event: 042 | 2020.10.18 00:00 | System time loss //Cold start (power on in non-armed state)
2416.29: 11101100 0 00000000 00100000 00101010 01000000 00000000 00000010 10001100 00101010 00101110 [0xEC] Event: 042 | 2020.10.18 00:00 | System time loss (power on in non-armed state)
297.02: 10101010 0 00010010 01101000 10001101 00001000 01001011 01111111 10000011 [0xAA] Event: 127 | 2012.10.04 13:02 | Partition in alarm //Recent closing in log
297.10: 11101100 0 00000001 00010010 00101000 10001101 00001000 00000000 01001011 01111111 10000110 [0xEC] Event: 127 | 2012.10.04 13:02 | | Partition 1 | Partition in alarm //Recent closing in log
1548.95: 10101010 0 00100000 00110000 00100011 11001011 00110101 00100001 00111110 [0xAA] Event: 033 | 2020.12.01 03:50 | Module tamper restored: Slot 9 //Zone expander 1 Tamper restore
1549.05: 11101100 0 00000000 00100000 00110000 00100011 11001000 00000011 00110101 00100001 10000000 [0xEC] Event: 033 | 2020.12.01 03:50 | Module tamper restored: Slot 9 //Zone expander 1 Tamper restore
Some messages from event buffer log which are reported as Unknown data (or their decoded names differ from event buffer on keypads) that I took from panels:
Thanks for the detailed logs! I've added these status messages - this is a great method to decode status data so I've updated the issue topic and first message to indicate that logs with unknown data would be useful.
Some of the 0xAA messages are odd - the status byte 6 is 0xFF/11111111 with the byte 5 bit 0-1 11, this seems to occur for all messages that are beyond the range of the 0xA5 and 0xAA commands and handled by 0xEB/0xEC. For now I've marked these as "Extended status" and the actual status will be on the 0xEC message, but this decoding concept is open to interpretation:
317.59: 10101010 0 00010010 00101000 10001101 00001011 11111111 01111011 11110110 [0xAA] Event: 123 | 2012.10.04 13:02 | Extended status
317.67: 11101100 0 00000001 00010010 00101000 10001101 00001000 00000100 10000111 01111011 11000010 [0xEC] Event: 123 | 2012.10.04 13:02 | Partition 1 | Exit fault
There are also a few ranges of status messages that will probably get filled in - for example, in printPanelStatus2() it's likely that all messages in the 0xF9 - 0xFF range are for different zone expander slots supervisory status:
// 0xE9 - 0xF0: Keypad restored: Slots 1-8
// 0xF1 - 0xF8: Keypad trouble: Slots 1-8
case 0xF9: stream->print(F("Zone expander restored: Slot 9")); return;
case 0xFF: stream->print(F("Zone expander trouble: Slot 9")); return;
There are also a few ranges of status messages that will probably get filled in - for example, in printPanelStatus2() it's likely that all messages in the 0xF9 - 0xFF range are for different zone expander slots supervisory status:
If it helps you, here are more zone expander supervisory status - took yesterday (I can took supervision logs for all zone expanders from 1-7 if needed):
1690.33: 10101010 0 00100000 00110000 00100000 00000011 00000011 01001110 01101110 [0xAA] Event: 078 | 2020.12.01 00:00 | Unknown data //Zone expander 5 supervisory trouble
1690.43: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000011 00000011 01001110 10110000 [0xEC] Event: 078 | 2020.12.01 00:00 | Unknown data //Zone expander 5 supervisory trouble
1717.22: 10101010 0 00100000 00110000 00100000 00000011 00000010 01010000 01101111 [0xAA] Event: 080 | 2020.12.01 00:00 | Unknown data //Zone expander 4 supervisory trouble
1717.32: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000011 00000010 01010000 10110001 [0xEC] Event: 080 | 2020.12.01 00:00 | Unknown data //Zone expander 4 supervisory trouble
1781.54: 10101010 0 00100000 00110000 00100000 00000010 11111101 01100000 01111001 [0xAA] Event: 096 | 2020.12.01 00:00 | Unknown data //Zone expander 5 supervisory restore
1781.64: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000010 11111101 01100000 10111011 [0xEC] Event: 096 | 2020.12.01 00:00 | Unknown data //Zone expander 5 supervisory restore
1798.76: 10101010 0 00100000 00110000 00100000 00000010 11111100 01100001 01111001 [0xAA] Event: 097 | 2020.12.01 00:00 | Unknown data //Zone expander 4 supervisory restore
1798.86: 11101100 0 00000000 00100000 00110000 00100000 00000000 00000010 11111100 01100001 10111011 [0xEC] Event: 097 | 2020.12.01 00:00 | Unknown data //Zone expander 4 supervisory restore
Suggestion, maybe change zone expander naming from "Slot 9" onto "Zone Expander 1"?
I was comparing Event buffer from LCD to DLS. As per DLS, Event 1BF1 seems to be "System reset transmission". I will check how its displayed on PK5500 event buffer, but I think DLS says correctly and it just wasnt implemented into LCD5500.
About Low battery: Zone 35 it is *2 access by master code 40. Sorry for giving wrong information, but LCD5500 was made before access code needed ability added for *2/*3. Zone fault restored: 40 is *3 by system master. Other messages seems to be correct. Some more *1, *2 and *3 access code by user informations:
1518.31: 10101010 0 00100000 01101010 01010110 10010010 10011110 00000001 10111011 [0xAA] Event: 001 | 2020.10.18 22:36 | Partition 1 | Unknown data //*1 access by user 1
1518.40: 11101100 0 00000001 00100000 00101010 01010110 10010000 00000010 10011110 00000001 10111110 [0xEC] Event: 001 | 2020.10.18 22:36 | Partition 1 | Unknown data //*1 access by user 1
1571.56: 10101010 0 00100000 01101010 01010110 10010110 10110110 00000001 11010111 [0xAA] Event: 001 | 2020.10.18 22:37 | Partition 1 | Unknown data //*1 access by user 25
1571.65: 11101100 0 00000001 00100000 00101010 01010110 10010100 00000010 10110110 00000001 11011010 [0xEC] Event: 001 | 2020.10.18 22:37 | Partition 1 | Unknown data //*1 access by user 25
1714.37: 10101010 0 00100000 00101010 01010110 10100011 11111111 00000001 11101101 [0xAA] Event: 001 | 2020.10.18 22:40 | Extended status //*2 access by user 1
1714.46: 11101100 0 00000001 00100000 00101010 01010110 10100000 00010111 00000000 00000001 01000101 [0xEC] Event: 001 | 2020.10.18 22:40 | Partition 1 | Unknown data //*2 access by user 1
1770.73: 10101010 0 00100000 00101010 01010110 10100011 11111111 00000001 11101101 [0xAA] Event: 001 | 2020.10.18 22:40 | Extended status //*2 access by user 25
1770.82: 11101100 0 00000001 00100000 00101010 01010110 10100000 00010111 00011000 00000001 01011101 [0xEC] Event: 001 | 2020.10.18 22:40 | Partition 1 | Unknown data //access by user 25
1842.06: 10101010 0 00100000 00101010 01010110 10101011 11111111 00000001 11110101 [0xAA] Event: 001 | 2020.10.18 22:42 | Extended status //*3 access by user 1
1842.15: 11101100 0 00000001 00100000 00101010 01010110 10101000 00010111 00100101 00000001 01110010 [0xEC] Event: 001 | 2020.10.18 22:42 | Partition 1 | Unknown data //*3 access by user 1
1889.65: 10101010 0 00100000 00101010 01010110 10101011 11111111 00000001 11110101 [0xAA] Event: 001 | 2020.10.18 22:42 | Extended status //*3 access by user 25
1889.74: 11101100 0 00000001 00100000 00101010 01010110 10101000 00010111 00111101 00000001 10001010 [0xEC] Event: 001 | 2020.10.18 22:42 | Partition 1 | Unknown data //*3 access by user 25
1990.63: 10101010 0 00100000 01101010 01010110 10110010 11000110 00000010 00000100 [0xAA] Event: 002 | 2020.10.18 22:44 | Partition 1 | Auto-arm cancelled by user code 1 //*71 user log 1 (activated by user 1)
1990.72: 11101100 0 00000001 00100000 00101010 01010110 10110000 00000010 11000110 00000010 00000111 [0xEC] Event: 002 | 2020.10.18 22:44 | Partition 1 | Auto-arm cancelled by user code 1 //*71 user log 1 (activated by user 1)
2053.98: 10101010 0 00100000 01101010 01010110 10110110 11011110 00000010 00100000 [0xAA] Event: 002 | 2020.10.18 22:45 | Partition 1 | Auto-arm cancelled by user code 25 //*71 user log 25 (activated by user 25)
2054.07: 11101100 0 00000001 00100000 00101010 01010110 10110100 00000010 11011110 00000010 00100011 [0xEC] Event: 002 | 2020.10.18 22:45 | Partition 1 | Auto-arm cancelled by user code 25 //*71 user log 25 (activated by user 25)
Keypad buffer on LCD keypads and DLS reports *5/*6 access by user code X, but keybusreader says just "*6 programming", without which user code accessed it. But it is showing for "*1 Master code 40".
I've partly decoded new cmd 0x57, which is for wireless keyfobs, atleast part of it. No recorded event in memory buffer.
CMD 0x57:
Byte 2: bit 0 = key 1 restore; bit 1 = key 1 lowbat ... bit 7 = key 4 lowbat
Byte 3: bit 0 = key 5 restore; bit 1 = key 5 lowbat ... bit 7 = key 8 lowbat
Byte 4: bit 0 = key 9 restore; bit 1 = key 9 lowbat ... bit 7 = key 12 lowbat
Byte 5: bit 0 = key 13 restore; bit 1 = key 13 lowbat ... bit 7 = key 16 lowbat
4872.65: 11111111 1 01000110 11111111 11111111 10111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: //same for all, should be keyfob disarm key.
4872.75: 01010111 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x57] [CRC Error] //same for all messages
4616.96: 11111111 1 11111101 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11110110 [Module/0x57] Unknown data //Keyfob 1 low battery
4872.75: 11111111 1 11111110 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11110111 [Module/0x57] Unknown data //Keyfob 1 low bat restore
5920.50: 11111111 1 11111111 11111111 11111111 01111111 11111111 11111111 11111111 11111111 01111000 [Module/0x57] Unknown data //Keyfob 16 low battery
6057.59: 11111111 1 11111111 11111111 11111111 10111111 11111111 11111111 11111111 11111111 10111000 [Module/0x57] Unknown data //Keyfob 16 low bat restore
6207.38: 11111111 1 11111111 11111111 01111111 11111111 11111111 11111111 11111111 11111111 01111000 [Module/0x57] Unknown data //Keyfob 12 low battery
6937.38: 11111111 1 11111111 11111111 10111111 11111111 11111111 11111111 11111111 11111111 10111000 [Module/0x57] Unknown data //Keyfob 12 low bat restore
In dscKeybusPrintData.cpp 0xEB decoding section, you wrote * Byte 4 bit 6-7: Unknown, always observed as: 00. But that isnt correct. In logs from post above, I see that bit6 flip sometimes, on old logs still in memory buffer. I didnt discover when. I was changing partitions from 1-8 and they both stay at 00 whole time.
If it helps you, here are more zone expander supervisory status - took yesterday (I can took supervision logs for all zone expanders from 1-7 if needed):
Hi @kricon - thank you! I've added the supervisory status for zone expanders 1-6. If you get a chance to setup expander 7 and capture the supervisory trouble/restored data, I can add this as well (zone expander 7's data is normally separate from expanders 1-6).
Suggestion, maybe change zone expander naming from "Slot 9" onto "Zone Expander 1"?
Makes sense, done.
I was comparing Event buffer from LCD to DLS. As per DLS, Event 1BF1 seems to be "System reset transmission". I will check how its displayed on PK5500 event buffer, but I think DLS says correctly and it just wasnt implemented into LCD5500.
About Low battery: Zone 35 it is *2 access by master code 40. Sorry for giving wrong information, but LCD5500 was made before access code needed ability added for *2/*3. Zone fault restored: 40 is *3 by system master. Other messages seems to be correct. Some more *1, *2 and *3 access code by user informations:
Okay, these make sense - the low battery zone 35 didn't seem like it belonged in that set of status data. The status data normally runs in a sequential range, for example based on your access code data with users 1 and 25, I've extrapolated the rest of the user codes including the duress, master, and supervisor codes that are usually tacked onto the end of the user codes 1-32. Pending confirmation but it makes sense and fits well with the rest of the status data.
For the user codes that I had listed for auto-arm canceled and you're seeing used for *71, I've simplified the labels to just user code as it seems like this access code data is being used for multiple functions.
Keypad buffer on LCD keypads and DLS reports *5/*6 access by user code X, but keybusreader says just "*6 programming", without which user code accessed it. But it is showing for "*1 Master code 40".
Can you get logs of this? I'm curious how the access code is being encoded, it may be in a command before or after the 0xAA line showing *6 programming.
I've partly decoded new cmd 0x57, which is for wireless keyfobs, atleast part of it. No recorded event in memory buffer.
Great! I've added 0x57 panel and module response decoding.
In dscKeybusPrintData.cpp 0xEB decoding section, you wrote * Byte 4 bit 6-7: Unknown, always observed as: 00. But that isnt correct.
Gotcha, I've updated the documentation to just Unknown.