New Cmds 0x41, 0x22 and more info on cmd 0xE6 subcmd 0x1A

[Dilbert66]

Model PC5010 Version 2.0

Battery for zone 11 low 25182.38:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error] 25182.38:[MODULE] 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [RF module] Unknown key: 0xFF

Battery for zone 11 recovered 24903.54:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error] 24903.54:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 11011111 11111111 11111111 11011000 [RF module] Unknown key: 0xFF

New command 0x41. This command gets sent from the panel as a response to a request by the PC5132 RF module, which sends it when it detects a low battery on any devices assigned to it.
The PC5132 responds back with the battery status of each zone. Byte 3 represents the battery status of each zone with the high bit = lowest zone. Byte 7 is the restored battery status.. From the bit location it looks to have a bit for every zone from 1 to 32 for both low and high bat levels. I have not tested with other ranges except for 9-16.

I'm assuming here that for a 64 zone system, the 0x41 cmd will be a larger variant.

A zone tamper will also trigger the 0x41 command .

[taligentx]

Hi Alain, thanks for the decoding! It's great to fill in more gaps. I've added decoding the wireless module battery status to the expander branch and it'll get into develop once I trim down the code for the 32kB Arduino boards (same with the zone expander decoding). Before and after for KeybusReader:

Before:
Battery for zone 11 low
25182.38:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error]
25182.38:[MODULE] 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [RF module] Unknown key: 0xFF

After:
25182.38: 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Wireless module query
25182.38: 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [Module/0x41] Wireless module | Battery low zones: 11 

Do you have logs of the notification sent during command 0x05 by the RF5132 that triggers the panel to send the 0x41 query? I'd like to add this to the decoding.

I'm assuming here that for a 64 zone system, the 0x41 cmd will be a larger variant.

The RF1532 can only work as zones 1-32 so I suspect that this is the complete format of 0x41: https://www.alarmsystemstore.com/pages/dsc-rf5132-433-how-many-zones

A zone tamper will also trigger the 0x41 command .

Do you have logs of this? I just have the zone tamper reporting in 0xA5 (zones 1-32) and 0xEB (zones 33-64). Thanks!

-Nikhil

[Dilbert66]

Notes: zones 9-16 are on partition 2 in this case. The pc5132 module only sends out a 0x41 low battery notice after the 3rd sensor transmission from a zone with a low battery condition. I assume this is to ensure no false positives. On a zone tamper condition , the module will always send a request for cmd 41 update. Presumably this is to assume the user changed the battery. The battery status will not be updated until the zone tamper also occurs since you can't change the battery without removing the sensor cover,.

//Open zone low battery on 3rd notification from sensor. Module sends a zone range 9-16 status update notification to panel (position 9) 25182.03:[MODULE] 11111111 1 11111111 11111111 10111111 11111111 [Zone Expander] Status notification (position 9) // panel responds with cmd 28 25182.17:[PANEL] 00101000 0 11111111 11111111 11111111 11111111 11111111 [0x28] Zone expander zones 9-16 query //module sends zone range 9-16 data. Zone 11 open (bits = 11) (closed and normal=01) 25182.17:[MODULE] 11111111 1 01110101 01010101 01010101 01010101 01100100

//panel then sends general notification to keypads about open zone 25182.23:[PANEL] 00101101 0 10000001 00000001 10000001 11000111 00000100 11111011 [0x2D] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 9-16 open: 11

//module after sensing and asserting low battery from sensor now sends a pc5132 battery status update(position 12) request to send to panel 25182.28:[MODULE] 11111111 1 11111111 11111111 11110111 11111111 //panel responds with cmd 41 25182.38:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error] //module sends back position encode battery status for all zones with low battery - in this case zone 11 25182.38:[MODULE] 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [Keypad] Unknown key: 0xFF

//panel then sends general notice to keypads. Turns on trouble light (zones 9-16 in this case are on partition 2) 25182.43:[PANEL] 00000101 0 10000001 00000001 10000000 11000111 [0x05] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled 25182.67:[PANEL] 00000101 0 10010001 00000001 10010000 11000111 [0x05] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: disabled 25186.66:[PANEL] 01100011 0 00000000 00000000 00000000 00000000 00000000 01100011 [0x63] Partition 2 | Status lights flashing: none | Zones 1-32 flashing: none 25186.69:[PANEL] 01100100 0 00000100 01101000 [0x64] Partition 1 | Beep: 2 beeps 25186.72:[PANEL] 01101001 0 00000100 01101101 [0x69] Partition 2 | Beep: 2 beeps

//zone with a tamper condition and replaced new battery

//zone 9-16 status updat request (position 9) 24902.21:[MODULE] 11111111 1 11111111 11111111 10111111 11111111 [Zone Expander] Status notification //zone 9-16 status update cmd 24902.36:[PANEL] 00101000 0 11111111 11111111 11111111 11111111 11111111 [0x28] Zone expander zones 9-16 query //zone response for 9-16 - zone 11 has value 10= tamper condition 24902.36:[MODULE] 11111111 1 01100101 01010101 01010101 01010101 01010100

//panel sends general keypad update with trouble light for zone tamper issue. 24902.42:[PANEL] 00101101 0 10010001 00000001 10010001 11000111 00000000 00010111 [0x2D] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: disabled | Zones 9-16 open: none 24902.51:[PANEL] 00000101 0 10010001 00000001 10010000 11000111 [0x05] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: disabled //pc5132 sends status update request with position 9 and 12 cleared indicating a zone update AND battery status updates 24903.22:[MODULE] 11111111 1 11111111 11111111 10110111 11111111 //panel cmd 28 24903.37:[PANEL] 00101000 0 11111111 11111111 11111111 11111111 11111111 [0x28] Zone expander zones 9-16 query //module sends back cleared zones status (all zones closed - 01) 24903.37:[MODULE] 11111111 1 01010101 01100101 01010101 01010101 01010100 //panel clears trouble light 24903.44:[PANEL] 00101101 0 10010001 00000001 10010000 11000111 00000000 00010110 [0x2D] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: disabled | Zones 9-16 open: none //panel then sends cmd 41 for battery status 24903.54:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error] //module then sensd back cleared status for zone 11 (0 in battery level ok bitfield) 24903.54:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 11011111 11111111 11111111 11011000 [Keypad] Unknown key: 0xFF //panel updates general keypad 24903.69:[PANEL] 00000101 0 10000001 00000001 10000001 11000111 [0x05] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled

[kricon]

Im just testing expander branch with KeybusReader sketch on PC5020 v3.2, PC5108 (same without) and RF5132 v5.0, everything is connected on desk for testing, wireless motion detector is on zone 2, partition 8 (same happens when its on partition 1) and I found something odd when I make tamper condition on wireless motion detector (even once said negative number):

23:52:55.090 ->  8458.22: 11111111 1 11111111 11111111 01111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] 
23:52:55.330 ->  8458.43: 00100010 0 11111111 11111111 11111111 11111111 11111111 [0x22] Unknown data[No CRC or CRC Error]
23:52:55.330 ->  8458.43: 11111111 1 01011001 01010101 01010101 01010101 10000100 [Module/0x22] Unrecognized data
23:52:55.434 ->  8458.54: 00100111 0 10000001 00000001 00000000 11000111 00000010 01110010 [0x27] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 1-8 open: 2 
23:52:55.502 ->  8458.63: 10100101 0 00100000 00101010 00010111 11010000 01010111 11111111 00101100 [0xA5] 2020.10.16 23:52 | Zone tamper: 2
23:52:55.811 ->  8458.92: 11101011 0 10000000 00100000 00101010 00010111 11010000 00000000 01010111 11111111 11110010 [0xEB] 2020.10.16 23:52 | Partition 8 | Zone tamper: 123
23:52:55.913 ->  8459.01: 00011011 0 00010000 11000111 00010000 11000111 00010000 11000111 10010000 00000011 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Trouble Backlight - Zones open

But, sometimes (this time sensor is on zone 32) the log is completely different when I make tamper condition on sensor:

01:40:28.409 -> 14911.65: 11111111 1 11111111 11111111 11101111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 11 
01:40:28.547 -> 14911.80: 00111001 0 11111111 11111111 11111111 11111111 11111111 [0x39] Zone expander slot 11 query
01:40:28.547 -> 14911.80: 11111111 1 01010101 01010101 10010101 01010101 01001000 [Module/0x39] Zone expander status update: Slot 11 | Zones changed: 32 unknown 
01:40:28.615 -> 14911.87: 00111110 0 10000001 00000001 00000000 11000111 10000000 00000111 [0x3E] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 25-32 open: 32 
01:40:28.790 -> 14912.05: 00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 [0x05] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Partition 3: disabled | Partition 4: disabled
01:40:29.067 -> 14912.32: 00011011 0 00010000 11000111 00010000 11000111 00010000 11000111 10010000 00000011 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Trouble Backlight - Zones open

I don't know what causes results to be different. Except that, PC5020 works fine and can be added to verified panels, I didnt find any more quirks for now. EDIT: It seems PC5020 have major issue with 0x16 cmd - everything except resistor option is unknown data. I will dig more into it and open new issue about that, hopefully we will be able to decode that aswell. As for now, 0x05 zone reporting etc works like it should, but 0x16 cmd is unknown data so everything related to that is pretty delayed and waits for 0x05 update (if I got right about that commands - Im newb in arduino). Also, did anybody decode left/right buttons on LCD keypads? EDIT2: its not related just to PC5020. Its related to 6-digit user codes. So, PC5020 works fine with 4-digit user codes. If needed, I have some panels and modules available for testing and giving feedback to help further development.

[Dilbert66]

The cmd to retrieve data will be different depending on the zone range. Cmd 0x28 for 9-16, 0x33 for 17-24, 0x39 for 25-32. in the first example you show a request to send on slot 8 with a zone tamper on zone 2 in range 1-8 The request to send will use slot 9 for 9-16, slot 10 for 17-24 and slot 11 for 25-32. Slot 12 is used by the pc5132 for battery status updates.

In your first example you show a cmd 0x22 with slot 8. This is for zone range 1-8 which is the internal zone range of the panel. If you did the tamper on the wireless and it shows on that range, something is not set right.
Edit. Ok , I see what you've done. You've setup the zone as wireless so it ignores the internal hardware zone and uses the 5132 zone definition. Either way, everything looks fine from what I see.

[Dilbert66]

Are you testing the expander with an address set for an emulated device? What address are you using for this. We can add 0x22 as a new cmd to add for the 5132 support for zones 1-8 slot 8. That range is not used for zone expanders. It's only addressable to wireless devices, internal hardware channels or to keypads with zones ( I believe- not verified)

[kricon]

Thanks for reply. Im not new into electronic and microcontrollers, I have some programming experiences before but I'm pretty new when it comes to arduino/IoT. I have a lot of experience with DSC panels so I know how to set zones, attributes, partitions etc. The system is on the desk, for testing before putting ESP8266 into installed system at house. Both of my PC5108 didnt have any zones enabled/connected to them and was set to 9-16 and 17-24 zone range. RF5132 have one motion detector (for testing) in zone 2, or later at zone 32. I dont use any emulated zones for now, but maybe I will later when I learn a bit about it. I have set wireless detector on zone 2, which is in range of panel but on panel its unused. You can put any wireless device on any zone except the ones in which range is PC5108 or above zone 32. Same as for keypad zones.

Here is example with wireless sensor on zone 32, triggered tamper and 0xEB says Tamper zone 131 which is wrong. And sometimes, 0xA5 and 0xEB dont say anything so in KeybusReader output it isnt visible that tamper triggered on zone 32 - it just show zone open and trouble condition:

01:54:59.125 -> 15782.39: 11111111 1 11111111 11111111 11101111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 11 
01:54:59.330 -> 15782.60: 00111001 0 11111111 11111111 11111111 11111111 11111111 [0x39] Zone expander slot 11 query
01:54:59.330 -> 15782.60: 11111111 1 01010101 01010101 10010101 01010101 01001000 [Module/0x39] Zone expander status update: Slot 11 | Zones changed: 32 unknown 
01:54:59.434 -> 15782.71: 00111110 0 10000001 00000001 00000000 11000111 10000000 00000111 [0x3E] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 25-32 open: 32 
01:54:59.537 -> 15782.80: 10100101 0 00100000 00101010 00100001 11011000 01110101 11111111 01011100 [0xA5] 2020.10.17 01:54 | Zone tamper: 32
01:54:59.846 -> 15783.10: 11101011 0 10000000 00100000 00101010 00100001 11011000 00000000 01110101 11111111 00100010 [0xEB] 2020.10.17 01:54 | Partition 8 | Zone tamper: 131
01:54:59.914 -> 15783.19: 00011011 0 00010000 11000111 00010000 11000111 00010000 11000111 10000000 00100010 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Backlight - Partition busy

You can compare it to second code example in my previous post, which was also on Z32 but didnt show on which zone tamper occured, and also to the one I trigger just now:

02:53:03.068 -> 19266.42: 11111111 1 11111111 11111111 11101111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 11 
02:53:03.241 -> 19266.58: 00111001 0 11111111 11111111 11111111 11111111 11111111 [0x39] Zone expander slot 11 query
02:53:03.241 -> 19266.58: 11111111 1 01010101 01010101 10010101 01010101 01001000 [Module/0x39] Zone expander status update: Slot 11 | Zones changed: 32 unknown 
02:53:03.309 -> 19266.66: 00111110 0 10000001 00000001 00000000 11000111 10000000 00000111 [0x3E] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 25-32 open: 32 
02:53:03.584 -> 19266.92: 00011011 0 00000000 11000111 00000000 11000111 00000000 11000111 10000100 00000011 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Memory Backlight - Zones open

So it seems that 0xEB and 0xA5 'dont trigger' everytime to show on which zone tamper condition occured?

[Dilbert66]

The 131 is a typo in the print routine for the 0xEB print command. This won't impact normal operation, just logging but good catch.

  if (panelData[panelByte] >= 0x56 && panelData[panelByte] <= 0x75) {
    stream->print(F("Zone tamper: "));
    stream->print(panelData[6] - 0x55);  should be     stream->print(panelData[panelByte] - 0x55);
    return;
  }

[Dilbert66]

As to why the panel does not always indicate a tamper condition, that I can't say. There has to be a factor controlling that in test environment I would think that would cause the difference in behavior. When the tamper occurred on that zone, was the panel already indicating a tamper on that zone already or was it cleared?

[kricon]

Thanks! I edited the typo and now it correctly detect zone tamper. I hope it will be also edited on github soon. Is it possible that typo didnt affect the smaller panels (like pc585) as I think 0xA5 displayed zone tamper correctly? Edit: 0xA5 always display correct zone, 0xEB didnt before. And PC585 didn't send 0xEB cmd in log, so no errors.

When the tamper occurred on that zone, was the panel already indicating a tamper on that zone already or was it cleared?

Tamper/trouble condition was always cleared before I did tamper again.

I figured out why panel wasnt showing tamper condition always. After 3 tamper conditions on same zone, panel doesnt trigger 0xEB and 0xA5 but show trouble condition. Same for wired zones, I didnt know that, wonder if it have some timeout when it start to show tamper condition again like it should.

[Dilbert66]

Ah yes, the 3 times rule. I see that as well with battery level reporting for wireless sensors. After 3 transmissions from a wireless sensor with a low battery condition, the PC5132 will send a low battery status report to the panel who will then set the trouble condition. As far as clearing the tamper update timeout, perhaps it needs 3 good zone reports to clear it also. That's something I have not tested.

As to affecting the 0xA5, no the error would not have impacted that cmd since 6 was the correct value. For the 0xEB it has to be 8

[Dilbert66]

More info on cmd 0xE6 subcommand 0x1A.

This command provides panel AC POWER status on byte 6 bit 4. If bit 4 is set, AC power is off. Also looks like bit 3 is the "Loss of system Time" system error flog , bit 5 is the Tel line error flag and bit 6 is the No Communications error flag. Havent been able to identify the other bits yet. Bit 0 is always 1 in my testing .

Example Power off: 20401.38:[PANEL] 11100110 0 00011010 01000000 00000000 00000000 00010001 00000000 00000000 00000000 01010001 [0xE6] 0x1A: Unknown data

Power returned: 20409.20:[PANEL] 11100110 0 00011010 01000000 00000000 00000000 00000001 00000000 00000000 00000000 01000001 [0xE6] 0x1A: Unknown data

[taligentx]

@Dilbert66 Thanks! I've updated the module notification decoding in the expander branch:

Before:
25182.28:[MODULE] 11111111 1 11111111 11111111 11110111 11111111
//panel responds with cmd 41
25182.38:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Unknown data[No CRC or CRC Error]
//module sends back position encode battery status for all zones with low battery - in this case zone 11
25182.38:[MODULE] 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [Keypad] Unknown key: 0xFF

After:
25182.28:[MODULE] 11111111 1 11111111 11111111 11110111 11111111 [Module/0x05] Wireless module battery notification
25182.38:[PANEL] 01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Wireless module query
25182.38:[MODULE] 11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [Module/0x41] Wireless module | Battery low zones: 11

Hi @kricon - thanks for the detailed info and logs! This is the first data I've run across with the RF5132 setup with zones 1-8. I've updated the module decoding to handle slot 8 and zones 1-8 for the wireless module in the expander branch and fixed the zone tamper decoding for 0xEB in both the develop and expander branches:

Before:
23:52:55.090 ->  8458.22: 11111111 1 11111111 11111111 01111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] 
23:52:55.330 ->  8458.43: 00100010 0 11111111 11111111 11111111 11111111 11111111 [0x22] Unknown data[No CRC or CRC Error]
23:52:55.330 ->  8458.43: 11111111 1 01011001 01010101 01010101 01010101 10000100 [Module/0x22] Unrecognized data
23:52:55.434 ->  8458.54: 00100111 0 10000001 00000001 00000000 11000111 00000010 01110010 [0x27] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 1-8 open: 2 
23:52:55.502 ->  8458.63: 10100101 0 00100000 00101010 00010111 11010000 01010111 11111111 00101100 [0xA5] 2020.10.16 23:52 | Zone tamper: 2
23:52:55.811 ->  8458.92: 11101011 0 10000000 00100000 00101010 00010111 11010000 00000000 01010111 11111111 11110010 [0xEB] 2020.10.16 23:52 | Partition 8 | Zone tamper: 123
23:52:55.913 ->  8459.01: 00011011 0 00010000 11000111 00010000 11000111 00010000 11000111 10010000 00000011 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Trouble Backlight - Zones open

After:
23:52:55.090 ->  8458.22: 11111111 1 11111111 11111111 01111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 8 
23:52:55.330 ->  8458.43: 00100010 0 11111111 11111111 11111111 11111111 11111111 [0x22] Zone expander slot 8 query
23:52:55.330 ->  8458.43: 11111111 1 01011001 01010101 01010101 01010101 10000100 [Module/0x22] Zone expander status update: Slot 8 | Zones changed: 2 tamper 
23:52:55.434 ->  8458.54: 00100111 0 10000001 00000001 00000000 11000111 00000010 01110010 [0x27] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Zones 1-8 open: 2 
23:52:55.502 ->  8458.63: 10100101 0 00100000 00101010 00010111 11010000 01010111 11111111 00101100 [0xA5] 2020.10.16 23:52 | Zone tamper: 2
23:52:55.811 ->  8458.92: 11101011 0 10000000 00100000 00101010 00010111 11010000 00000000 01010111 11111111 11110010 [0xEB] 2020.10.16 23:52 | Partition 8 | Zone tamper: 2
23:52:55.913 ->  8459.01: 00011011 0 00010000 11000111 00010000 11000111 00010000 11000111 10010000 00000011 [0x1B] Partition 5: disabled | Partition 6: disabled | Partition 7: disabled | Partition 8: Trouble Backlight - Zones open

It seems PC5020 have major issue with 0x16 cmd - everything except resistor option is unknown data. I will dig more into it and open new issue about that, hopefully we will be able to decode that aswell. As for now, 0x05 zone reporting etc works like it should, but 0x16 cmd is unknown data so everything related to that is pretty delayed and waits for 0x05 update

Yep, I'll pick up the 0x16 decoding in the other issue, though the output you see in KeybusReader is a direct decoding of the Keybus data in real time, there isn't any status processing (like interpreting a command and then setting a state, etc). So 0x16 having unrecognized data has no effect on the later messages, the sketch is just spitting out the data as seen on the wire.

I figured out why panel wasnt showing tamper condition always. After 3 tamper conditions on same zone, panel doesnt trigger 0xEB and 0xA5 but show trouble condition.

This is likely related to swinger shutdown, per README.md:

PC1555MX/5015 section 370, PC1616/PC1832/PC1864 section 377: Swinger shutdown: By default, the panel will limit the number of alarm commands sent in a single armed cycle to 3 - for example, a zone alarm being triggered multiple times will stop reporting after 3 alerts. This is to avoid sending alerts repeatedly to a third-party monitoring service, and also affects this interface. As I do not use a monitoring service, I disable swinger shutdown by setting this to 000.

For example, from the PC1832/1864 installation manual:

[377] Communicator Variables Program a 3-digit number for each program entry:

• Swinger Shutdown (Alarms): Maximum number of alarm/restoral transmissions per zone. Valid entries: [001] to [014]. Program data [000] to disable shutdown.
• Swinger Shutdown (Tamper): Maximum number of tamper alarm/restoral transmissions per zone. Valid entries: [000] to [014]. Program data [000] to disable shutdown.
• Swinger Shutdown (Trouble): Maximum number of trouble alarm/restoral transmissions per trouble condition. Valid entries: [000] to [014]. Program data [000] to disable shutdown.
• Communicator (Transmission) Delay: Time, in seconds, the panel will delay reporting an alarm event. Valid entries: [000] to [255].
• AC Failure Communication Delay: Time, in minutes, the panel will delay reporting an AC trouble event. Valid entries: [000] to [255].
• TLM Trouble Delay: Time, in 3-second intervals, before the system will consider the phone line disconnected. Valid entries: [002] to [255] (e.g., 3 x10 seconds = 30 seconds). TLM Restoral follows the same delay.
• Test Transmission Cycle (Land Line): Number of days between test transmission reporting events. Valid entries: [001] to [255].
• Wireless Zone Low Battery Delay: Number of days the system will delay reporting a wireless low battery to the central station. Valid entries: [000] to [255]. Program data [000] for no delay.
• Delinquency Transmission Delay: Number of hours (Activity Delinquency) or days (Arming Delinquency) the panel will delay before transmit- ting the event to the central station. Valid entries: [001] to [255].
• Communication Cancel Window: Time, in minutes, after an alarm has occurred that the system will report a Communication Cancel reporting event if the system is disarmed. They keypad will beep rapidly to indicate that the Communication Cancel reporting event has been communi- cated successfully. Valid entries: [001] to [255].

Regarding 0xE6-0x1A:

This command provides panel AC POWER status on byte 6 bit 4. If bit 4 is set, AC power is off. Also looks like bit 3 is the "Loss of system Time" system error flog , bit 5 is the Tel line error flag and bit 6 is the No Communications error flag.

Interesting, I'll dig into this to see if it can be correlated to the 0xA5 and 0xEB status messages - I'm curious why this data is being duplicated with those commands. Perhaps there's some module that can't interpret 0xA5 and 0xEB and needs a simpler command with those states as simple bit flags.

Thanks, Nikhil

[Dilbert66]

Hold on with the tel line flag. It's not what I thought but the other flags are confirmed. The A5/EB commands on the version 4.6 1832 board I have only get sent if the communications flag is enabled in cmd 380. Therefore the only method to know of trouble conditions such as ac power is the 05 trouble indicator light or the 0xe6 1a command for ac power . This will happen if users are not using monitoring. There will also be the cmd0x64/0x6x beep commands. I have to test how to disable the com error (when coms are enabled but there is no monitoring) since I want the messages. I did turn off the tel line with cmd 015 (tlm enabled flag) to disabled tel line error messages. Edit: I reading through I believe I need to disable test transmissions in cmd 377. I'll try that out and see if it takes care of the com error. Edit. The test transmission did not work. Still get the com error. Set all values on cmd377 to 000 as well. Edit: Ok, pgm 350 set to 06 seems to do the trick and disables the com error.

[kricon]

We can add 0x22 as a new cmd to add for the 5132 support for zones 1-8 slot 8. That range is not used for zone expanders. It's only addressable to wireless devices, internal hardware channels or to keypads with zones ( I believe- not verified)

@Dilbert66 about adressing wireless zones, I put my WLS PIR on zone 32 which was adressed to same range as PC5108 (25-32) by mistake. To my suprise, wireless zone worked just like other zones on PC5108 in same range. Closing (wired) zone 32 (assigned to WLS device) on pc5108 expander says "Zone 32 trouble", so if used WLS zones in same range as PC5108, you need to leave it open (not connected) on wired expander. Then I tested to have keypad zone in same range as wired expander which also worked - tested on PC5020 v3.2, LCD5500 v3.13, 3x5108 9-32, RF5132 v5.0, NC zone loops. Seems it is possible to adress wireless, keypad and wired expander zones together in same slot range, which I thought wasn't possible. But its nice catch, as for example on pc5132 to mix 3x5108 and wls zones on same range, also I discover that on PC1616 v4.5 its possible to have up to 22 wired zones by using keypad input zones. About assigning keypad zones into 1-8 zone range it even says in manual that its possible and I have verifyed it multime times: If the keypad zone is assigned a zone number that is present on the main panel, it will replace the existing zone and the zone on the main panel will be disabled.

I've updated the module decoding to handle slot 8 and zones 1-8 for the wireless module in the expander branch and fixed the zone tamper decoding for 0xEB in both the develop and expander branches:

@taligentx thanks, just tested it and it works fine. Its nice to have more things decoded and less Unrecognized/unknown/CRC data errors. Sadly, on PC5020 I have a lot of 0xCE cmd Unknown data "spam" thru code, sometimes few times in row, on PC585 I didnt get a single line with it. I know that 0xCE cmd is unknown yet, just saying what I noticed - it might help somehow. After weekend I will test it on 1565-2P v2.2 and some other panels, if I find something interesting related to this I'll edit this post with new info included.

Interesting, I'll dig into this to see if it can be correlated to the 0xA5 and 0xEB status messages - I'm curious why this data is being duplicated with those commands. Perhaps there's some module that can't interpret 0xA5 and 0xEB and needs a simpler command with those states as simple bit flags.

If that means something, I noticed that PC5020 v.3.2 sends both 0xA5 and 0xEB status for example when making tamper condition (if less than two minutes since power up, it doesnt send 0xCE and 0xEB lines):

05:03:26.502 ->  5842.78: 11111111 1 11111111 11111111 11101111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 11 
05:03:26.776 ->  5843.03: 00111001 0 11111111 11111111 11111111 11111111 11111111 [0x39] Zone expander slot 11 query
05:03:26.776 ->  5843.03: 11111111 1 01010101 01010101 01010101 10010101 01001000 [Module/0x39] Zone expander status update: Slot 11 | Zones changed: 32 closed 
05:03:26.845 ->  5843.11: 00111110 0 10010000 00000011 00010000 11000111 00000000 10101000 [0x3E] Partition 1: Trouble Backlight - Zones open | Partition 2: disabled | Zones 25-32 open: none
05:03:26.914 ->  5843.19: 10100101 0 00100000 01101010 10100101 00111100 10010101 11111111 10100100 [0xA5] 2020.10.21 05:15 | Partition 1 | Zone tamper restored: 32
05:03:26.984 ->  5843.26: 11001110 0 00100000 00111100 10010101 00000000 00000000 10111111 [0xCE] Unknown data
05:03:27.191 ->  5843.45: 11101011 0 00000001 00100000 00101010 10100101 00111100 00000000 10010101 11111111 10101011 [0xEB] 2020.10.21 05:15 | Partition 1 | Zone tamper restored: 32
05:03:27.260 ->  5843.53: 00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 [0x05] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled | Partition 3: disabled | Partition 4: disabled

But PC585 v2.3 sends just 0xA5:

04:52:52.327 ->  5208.60: 11111111 1 11111111 11111111 11101111 11111111 [Module/0x05] Zone expander notification: Slot 11 
04:52:52.532 ->  5208.78: 00111001 0 11111111 11111111 11111111 11111111 11111111 [0x39] Zone expander slot 11 query
04:52:52.532 ->  5208.78: 11111111 1 01010101 01010101 10010101 01010101 01001000 [Module/0x39] Zone expander status update: Slot 11 | Zones changed: 32 tamper 
04:52:52.599 ->  5208.86: 00111110 0 10010001 00000001 11111111 11111111 10000000 01001110 [0x3E] Partition 1: Ready Trouble Backlight - Partition ready | Zones 25-32 open: 32 
04:52:52.668 ->  5208.93: 10100101 0 00100000 01101010 10100101 00010100 01110101 11111111 01011100 [0xA5] 2020.10.21 05:05 | Partition 1 | Zone tamper: 32
04:52:52.771 ->  5209.02: 00000101 0 10010000 00000011 10010001 11000111 [0x05] Partition 1: Trouble Backlight - Zones open | Partition 2: disabled

Yep, I'll pick up the 0x16 decoding in the other issue, though the output you see in KeybusReader is a direct decoding of the Keybus data in real time, there isn't any status processing (like interpreting a command and then setting a state, etc). So 0x16 having unrecognized data has no effect on the later messages, the sketch is just spitting out the data as seen on the wire.

I dont know why and what caused it, but at first run I had major problems with PC5020 and Blynk: typing a code for arm/disarm worked fine, led zone status worked fine. But arm/trouble/ready status and also LCD text had few min delay or doesnt work at all. cmds was unusable, after pressing it was locked-on and everything glitched, unable to do anything. Changed panel to PC585, everything work. So at first I though this has something with 0x16cmd, as I saw it reports armed/*8 programming on PC585 and unknown data on PC5020 (because used 6-digits code) but I was wrong. Changed back to PC5020 and since that everything worked like it should (with 4 and 6 code lenght) and pretty much instantly - I was even able to do some (blind) programming from Blynk app. You know the rule, when something doesnt work like it should, rebooting is first thing to try and I failed to do it before answering here. I apologize if I caused confusion because of it. Now everything works on every power up, could be related to wiring as I have multiple resistors soldered in series instead of single 33k ohm one.

This is likely related to swinger shutdown, per README.md:

Yep, exactly, set it to 000 and now it reports every time. My bad, I was confused just making/restoring tamper conditions looking at false random numbers from 0xEB, every time different (sometimes even negative) and then wont appear anymore so I didnt know if some script buffer-overflow thing happened at fist.

[taligentx]

@Dilbert66,

More info on cmd 0xE6 subcommand 0x1A. This command provides panel AC POWER status on byte 6 bit 4. If bit 4 is set, AC power is off. Also looks like bit 3 is the "Loss of system Time" system error flog , bit 5 is the Tel line error flag and bit 6 is the No Communications error flag. Havent been able to identify the other bits yet. Bit 0 is always 1 in my testing .

Great! I've updated the 0xE6-0x1A decoding (except for the telephone line trouble as you mentioned) in the expander branch. Byte 6 bit 7 seems related to the bell (siren) or a partition alarm based on jvitkauskas' logs in #2, but I can't verify that personally at the moment. Here's an excerpt from those logs (updated with the current decoding) showing the keypad fire alarm triggered and then disarmed:

  315.33: 01100100 0 00000110 01101010 [0x64] Partition 1 | Beep: 3 beeps
  315.38: 10111011 0 00100000 00000000 11011011 [0xBB] Bell: on
  315.45: 10100101 0 00011000 00011000 00100000 00011000 01001110 11111111 01011010 [0xA5] 2018.06.01 00:06 | Keypad Fire alarm
  315.49: 10000111 0 00000001 00000011 10001011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
  315.58: 11100110 0 00011010 01000000 00000001 00000000 10011001 00000000 00000000 00000000 11011010 [0xE6] Loss of system time | AC power trouble | Bell on (?) 
  315.61: 01110101 0 10000000 11110101 [0x75] Partition 1 | Beep pattern: solid tone
  315.67: 11001110 0 00100000 00011000 01001110 00000000 00000000 01010100 [0xCE] Keypad Fire alarm
  315.76: 00000101 0 00000000 00010111 01010000 11000111 01010000 11000111 01010000 11000111 [0x05] Partition 1: none - Unknown data: 0x17 | Partition 2: disabled | Partition 3: disabled | Partition 4: disabled
  315.90: 11100110 0 00011000 00000001 00010000 00000000 00000000 00000000 00000000 00001111 [0xE6] Partition 1 | Status lights flashing: Trouble | Zones 33-64 flashing: none
  315.95: 10000111 0 00000001 11110011 01111011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
  316.04: 11101011 0 00000000 00011000 00011000 00100000 00011000 00000000 01001110 11111111 10100000 [0xEB] 2018.06.01 00:06 | Keypad Fire alarm
  316.19: 10100101 0 00011000 00011000 00100000 00011000 01010010 11111111 01011110 [0xA5] 2018.06.01 00:06 | Keypad Fire alarm restored
  316.26: 11001110 0 00100000 00011000 01010010 00000000 00000000 01011000 [0xCE] Keypad Fire alarm restored
  316.43: 11101011 0 00000000 00011000 00011000 00100000 00011000 00000000 01010010 11111111 10100100 [0xEB] 2018.06.01 00:06 | Keypad Fire alarm restored
  316.84: 00000101 0 11010100 00010001 01010000 11000111 01010000 11000111 01010000 11000111 [0x05] Partition 1: Memory Trouble Fire Backlight - Partition in alarm | Partition 2: disabled | Partition 3: disabled | Partition 4: disabled
  316.88: 10000111 0 00000001 00000011 10001011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
  317.67: 11111111 1 00000101 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 1 
  317.88: 10000111 0 00000001 11110011 01111011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
  318.04: 11111111 1 00001010 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 2 
  318.44: 11111111 1 00001111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 3 
  318.95: 11111111 1 00010001 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 4 
  319.01: 01100100 0 00001100 01110000 [0x64] Partition 1 | Beep: 6 beeps
  319.05: 10000111 0 00000001 00000011 10001011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
  319.23: 10000111 0 00000001 00000000 10001000 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 on | PGM4 off
  319.27: 10111011 0 00000000 00000000 10111011 [0xBB] Bell: off
  319.36: 11100110 0 00011010 01000000 00000000 00000000 00011001 00000000 00000000 00000000 01011001 [0xE6] Loss of system time | AC power trouble 
  319.39: 01110101 0 00000000 01110101 [0x75] Partition 1 | Beep pattern: off
  319.47: 00000101 0 10010100 00000011 00010000 11000111 00010000 11000111 00010000 11000111 [0x05] Partition 1: Memory Trouble Backlight - Zones open | Partition 2: disabled | Partition 3: disabled | Partition 4: disabled
  332.83: 11100110 0 00101100 00001000 00000000 00000000 00000000 00000000 00011010 [0xE6] Partition 4 | Enabled zones 33-64: none

Still a lot to work out for 0xE6-0x1A but it's a start.

@kricon,

Sadly, on PC5020 I have a lot of 0xCE cmd Unknown data "spam" thru code, sometimes few times in row, on PC585 I didnt get a single line with it. I know that 0xCE cmd is unknown yet, just saying what I noticed - it might help somehow.

I've partly decoded 0xCE and added to the expander branch - some of these messages contain the same status codes as 0xA5 and 0xEB. Byte 3 bits 0,1 specify the set of status codes (split up into printPanelStatus0 ... printPanelStatus3) and byte 4 contains the status code:

11001110 0 00100000 00011000 01001110 00000000 00000000 01010100 [0xCE] Keypad Fire alarm
11001110 0 00100000 00011000 01010010 00000000 00000000 01011000 [0xCE] Keypad Fire alarm restored
11001110 0 00100000 00000000 11101001 00000000 00000000 11010111 [0xCE] Bell trouble
11001110 0 00100000 00011101 10001100 00000000 00000000 10010111 [0xCE] Zone fault: 1
11001110 0 00100000 00011101 01101100 00000000 00000000 01110111 [0xCE] Zone fault restored: 1
11001110 0 00100000 10001000 11101000 00000000 00000000 01011110 [0xCE] Panel AC power failure

You can try the expander branch and see if this correlates to the panel activities - if this decoding proves accurate, I'll look at adding it to dscKeybusProcessData.cpp as a redundant data source to 0xA5 and 0xEB. Still need to see if there's anything in 0xCE that is related to specific partitions, or if it is only for system-wide status updates.

There are two other types of 0xCE messages that are still unknown and often sent by the panel consecutively:

27.97: 11001110 0 00000011 00000001 00000000 00000000 00000000 11010010 [0xCE] Unknown data [Byte 2/0x03]
28.03: 11001110 0 01000000 11111111 11111111 11111111 11111111 00001010 [0xCE] Unknown data [Byte 2/0x40]

I've also added a note on my TODO list to go through dscKeybusPrintData.cpp and document which commands are completely decoded vs partially decoded, and list the bytes/bits that are unknown for the partially decoded commands. There's quite a bit left undecoded, it'd be interesting to see if there's any more useful data that can be put to good use in the example sketches.

[kricon]

Great! I've updated the 0xE6-0x1A decoding (except for the telephone line trouble as you mentioned) in the expander branch. Byte 6 bit 7 seems related to the bell (siren) or a partition alarm...

I can confirm Loss of clock and bell flags. Both triggered and disappear nicely. Bell flag triggered on keypad fire alarm, sadly I didnt yet tested if Byte6 bit7 is just for fire alarm bell, or it will also triger with panic/burglar alarm and partition-only bell. I will test it and report soon. For telephone line trouble flag, maybe it have something related to TLM trouble delay in section 377?

You can try the expander branch and see if this correlates to the panel activities - if this decoding proves accurate, I'll look at adding it to dscKeybusProcessData.cpp as a redundant data source to 0xA5 and 0xEB. Still need to see if there's anything in 0xCE that is related to specific partitions, or if it is only for system-wide status updates.

Byte 4 is correct and corresponds to 0xA5 data, even verified it with entering/exiting *8 and zone tampers. But, sometimes [0xCE] Unknown data [Byte 2/0x20] are shown instead of any status messages. I think its related to Byte3? There is nothing changed, few minutes is recognized, few minutes are unknown - it itself changes to unknown data, even in middle of making/restoring zone fault:

00:13:28.086 ->  2505.04: 10100101 0 00100000 00101100 00100000 00011101 10001100 11111111 10111001 [0xA5] 2020.11.01 00:07 | Zone fault: 1
00:13:28.191 ->  2505.12: 11001110 0 00100000 00011101 10001100 00000000 00000000 10010111 [0xCE] Unknown data [Byte 2/0x20] 
00:13:28.363 ->  2505.31: 11101011 0 00000000 00100000 00101100 00100000 00011100 00000001 10001100 11111111 11111111 [0xEB] 2020.11.01 00:07 | Zone fault: 1
00:13:30.823 ->  2507.79: 10100101 0 00100000 00101100 00100000 00100001 01101100 11111111 10011101 [0xA5] 2020.11.01 00:08 | Zone fault restored: 1
00:13:30.926 ->  2507.86: 11001110 0 00100000 00100001 01101100 00000000 00000000 01111011 [0xCE] Zone fault restored: 1
00:13:31.097 ->  2508.05: 11101011 0 00000000 00100000 00101100 00100000 00100000 00000001 01101100 11111111 11100011 [0xEB] 2020.11.01 00:08 | Zone fault restored: 1

Here are more messages of making keypad fire alarm:

23:48:34.651 ->  1011.58: 11001110 0 00100000 10111100 01001110 00000000 00000000 11111000 [0xCE] Keypad Fire alarm
23:50:27.261 ->  1124.18: 11001110 0 00100000 11000000 01001110 00000000 00000000 11111100 [0xCE] Unknown data [Byte 2/0x20] //fire alarm keypad
23:50:43.747 ->  1140.67: 11001110 0 00100000 11000100 01001110 00000000 00000000 00000000 [0xCE] Unknown data [Byte 2/0x20] //fire alarm keypad
23:57:38.354 ->  1555.29: 11001110 0 00100000 11011000 01001110 00000000 00000000 00010100 [0xCE] Unknown data [Byte 2/0x20] //fire alarm keypad
23:59:14.500 ->  1651.42: 11001110 0 00100000 11100000 01001110 00000000 00000000 00011100 [0xCE] Keypad Fire alarm

And restoring it:
23:49:19.861 ->  1056.78: 11001110 0 00100000 10111100 01010010 00000000 00000000 11111100 [0xCE] Keypad Fire alarm restored
23:50:27.708 ->  1124.63: 11001110 0 00100000 11000000 01010010 00000000 00000000 00000000 [0xCE] Unknown data [Byte 2/0x20]//fire alarm restored 
23:50:44.198 ->  1141.11: 11001110 0 00100000 11000100 01010010 00000000 00000000 00000100 [0xCE] Unknown data [Byte 2/0x20] //fire alarm restored
23:57:38.804 ->  1555.73: 11001110 0 00100000 11011000 01010010 00000000 00000000 00011000 [0xCE] Unknown data [Byte 2/0x20] //fire alarm restored

Same for zone faults:

00:24:17.656 ->  3154.63: 10100101 0 00100000 00101100 00100000 01000001 10001101 11111111 11011110 [0xA5] 2020.11.01 00:16 | Zone fault: 2
00:24:17.725 ->  3154.70: 11001110 0 00100000 01000001 10001101 00000000 00000000 10111100 [0xCE] Unknown data [Byte 2/0x20] 
00:24:23.527 ->  3160.47: 11001110 0 00100000 01000101 10001101 00000000 00000000 11000000 [0xCE] Unknown data [Byte 2/0x20] 
00:26:07.400 ->  3264.36: 11001110 0 00100000 01001001 10001101 00000000 00000000 11000100 [0xCE] Unknown data [Byte 2/0x20] 
00:29:00.365 ->  3437.31: 11001110 0 00100000 01010001 10001101 00000000 00000000 11001100 [0xCE] Unknown data [Byte 2/0x20] 
00:32:06.583 ->  3623.53: 11001110 0 00100000 01011101 10001101 00000000 00000000 11011000 [0xCE] Unknown data [Byte 2/0x20] 
00:34:09.635 ->  3746.62: 11001110 0 00100000 01100101 10001101 00000000 00000000 11100000 [0xCE] Zone fault: 2
00:24:17.931 ->  3154.89: 11101011 0 00000000 00100000 00101100 00100000 01000000 00000001 10001101 11111111 00100100 [0xEB] 2020.11.01 00:16 | Zone fault: 2

And restoring it:
00:24:20.558 ->  3157.53: 10100101 0 00100000 00101100 00100000 01000101 01101101 11111111 11000010 [0xA5] 2020.11.01 00:17 | Zone fault restored: 2
00:24:20.662 ->  3157.61: 11001110 0 00100000 01000101 01101101 00000000 00000000 10100000 [0xCE] Unknown data [Byte 2/0x20] 
00:24:25.773 ->  3162.72: 11001110 0 00100000 01000101 01101101 00000000 00000000 10100000 [0xCE] Unknown data [Byte 2/0x20]  
00:26:09.756 ->  3266.73: 11001110 0 00100000 01001001 01101101 00000000 00000000 10100100 [0xCE] Unknown data [Byte 2/0x20] 
00:29:04.615 ->  3441.56: 11001110 0 00100000 01010001 01101101 00000000 00000000 10101100 [0xCE] Unknown data [Byte 2/0x20] 
00:32:09.249 ->  3626.21: 11001110 0 00100000 01011101 01101101 00000000 00000000 10111000 [0xCE] Unknown data [Byte 2/0x20] 
00:34:12.507 ->  3749.48: 11001110 0 00100000 01100101 01101101 00000000 00000000 11000000 [0xCE] Zone fault restored: 2
00:24:20.833 ->  3157.81: 11101011 0 00000000 00100000 00101100 00100000 01000100 00000001 01101101 11111111 00001000 [0xEB] 2020.11.01 00:17 | Zone fault restored: 2

Tested on PC5020, partition 1. I will try to check if 0xCE has something keypad-slot/partition-related in next few days. Also I got PC5204 and I can confirm 0xCE byte 4 is the same as 0xA5 byte 6 and 0xEB byte 8 for Out1 supervision, tamper, ac/battery troubles. I was little confused with 0xCE byte7 inconsistence at first but I think its irrelevant, and I'm still confused of Byte3 bits 2,3,4,5 differences for same reports?

Another thing I found out, zone fault (0xEB, 0xCE) are reported even if the zone is disabled but it is immediately show as restored (before trouble will be annouced), even if the zone fault still isnt restored yet. (just saying, I know it is related to panel and doesnt have anything with this project)

[taligentx]

I've added decoding the wireless module battery status to the expander branch and it'll get into develop once I trim down the code for the 32kB Arduino boards (same with the zone expander decoding).

I've consolidated code in develop so KeybusReader with the expander decoding fits in ~28k of flash (for Arduino Uno, etc) - so going forward, all updates except for expander emulation will be develop. There seem to be some stability differences in writing keys between develop and expander based on #168 so I'll need to keep the expander emulation only in the expander branch until I can get hands back on hardware for testing in another month or so (typical Covid travel planning issues).

I've also rewritten most of the documentation for the Keybus commands in dscKeybusPrintData.cpp to better indicate which data is known and which data bits are still unknown. Previously, it was easy to assume that a command was fully decoded if it produced any kind of output, at least now the documentation reflects how much is still unknown, down to the command byte and individual bits.

For example, the module response to 0x41 is mostly decoded, but byte 10 is still unknown:

/*
 *  Module data during panel command 0x41: Wireless module query
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 2: Wireless battery low zones 1-8
 *  Byte 3: Wireless battery low zones 9-16
 *  Byte 4: Wireless battery low zones 17-24
 *  Byte 5: Wireless battery low zones 25-32
 *  Byte 6: Wireless battery restored zones 1-8
 *  Byte 7: Wireless battery restored zones 9-16
 *  Byte 8: Wireless battery restored zones 17-24
 *  Byte 9: Wireless battery restored zones 25-32
 *  Byte 10: Unknown
 *
 *  01000001 0 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [0x41] Wireless module query
 *  11111111 1 11111111 11011111 11111111 11111111 11111111 11111111 11111111 11111111 11011000 [Module/0x41] Wireless module | Battery low zones: 11
 *  11111111 1 11111111 11111111 11111111 11111111 11111111 11011111 11111111 11111111 11011000 [Module/0x41] Wireless module | Battery restored zones: 11
 */
void dscKeybusInterface::printModule_Panel_0x41() {
(...)

For example 0xE6-1A byte 4 is still pending testing, it seems to be either just partitions or partitions in alarm:

/*
 *  0xE6_0x1A: Panel status
 *  CRC: yes
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 3: Unknown
 *  Byte 4: Partitions in alarm (?)
 *  Byte 5: Unknown
 *  Byte 6 bit 0-2: Unknown
 *  Byte 6 bit 3: Loss of system time status
 *  Byte 6 bit 4: AC power trouble status
 *  Byte 6 bit 5: Unknown
 *  Byte 6 bit 6: Fail to communicate status
 *  Byte 6 bit 7: Bell on (?)
 *  Byte 7: Unknown
 *  Byte 8: Unknown
 *  Byte 9: Unknown
 *  Byte 10: CRC
 *
 *  11100110 0 00011010 01000000 00000001 00000000 00010001 00000000 00000000 00000000 01010010 [0xE6] AC power trouble
 *  11100110 0 00011010 01000000 00000000 00000000 00011001 00000000 00000000 00000000 01011001 [0xE6] Loss of system time | AC power trouble
(...)

Seems it is possible to adress wireless, keypad and wired expander zones together in same slot range, which I thought wasn't possible. But its nice catch, as for example on pc5132 to mix 3x5108 and wls zones on same range, also I discover that on PC1616 v4.5 its possible to have up to 22 wired zones by using keypad input zones.

This is great to know and means that there likely isn't any need to have the library check for other physical expanders for conflicts when using expander emulation.

But, sometimes [0xCE] Unknown data [Byte 2/0x20] are shown instead of any status messages. I think its related to Byte3? There is nothing changed, few minutes is recognized, few minutes are unknown - it itself changes to unknown data, even in middle of making/restoring zone fault:

This is strange behavior, I'm not clear why the same data is being decoded differently over time - if you can, try again using the current develop branch and it may help narrow down if the issue is on both branches.

Edit: typo

[kricon]

For example 0xE6-1A byte 4 is still pending testing, it seems to be either just partitions or partitions in alarm:

Yep, I can confirm byte4 is partitions in alarm. Bit0 partition 1...bit7 partition 8. Verified with partitions 1, 2, 4, and 8.

Byte 6 bit 7 seems related to the bell (siren) or a partition alarm...

Byte6 bit7 seems to be fire alarm. Tested several times, it only flips when fire-related alarm is going on, no matter of section 013 option 8.

This is strange behavior, I'm not clear why the same data is being decoded differently over time - if you can, try again using the current develop branch and it may help narrow down if the issue is on both branches.

Just tested and it behaves same. Only difference I see when [0xCE] saying "Unknown data" is related to change of byte3, especially bit5 being zero. Wherever bit5 is true, [0xCE] correctly display informations. And in source I see that byte3 is responsible for printing "Unknown data":

void dscKeybusInterface::printPanel_0xCE() {
  if (panelData[3] & 0x20) {
    switch (panelData[3] & 0x03) {
      case 0x00: printPanelStatus0(4); return;
      case 0x01: printPanelStatus1(4); return;
      case 0x02: printPanelStatus2(4); return;
    }
  }
  else {
    printUnknownData();
    stream->print(F(" [Byte 2/0x"));
    if (panelData[2] < 16) stream->print("0");
    stream->print(panelData[2], HEX);
    stream->print(F("] "));
  }
}

BTW, I think I can also log output for RF zone deliquency trouble and decode it. It is available on v4.1+ powerseries and viewable only with pk5500 keypad which I currently doesnt have at home - its installed at my weekend-house and often (well, lets say once per month) get RF Deliquency trouble no matter that the zone still works fine, it doesnt generate an alarm (even when all partitions armed) and trouble restores when I disarm partitions.

EDIT: I forgot to say, current develop branch is saying "Unknown data" after each keypress: 02:23:08.527 -> 413.35: 11111111 1 00010110 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 5 Unknown data And also I found out when you're programming date/time (*6, 1) from lcd5500, keybusreader is showing like you're pressing left/right buttons, but in reality you're pressing numerical buttons 0-9. This "glitch" isnt present in LED keypads. Nothing major, just saying for information.

[taligentx]

Another thing I found out, zone fault (0xEB, 0xCE) are reported even if the zone is disabled but it is immediately show as restored (before trouble will be annouced), even if the zone fault still isnt restored yet.

I think I remember seeing this for the panel zones (0xA5) as well - it is an interesting little quirk.

Yep, I can confirm byte4 is partitions in alarm. Bit0 partition 1...bit7 partition 8. Verified with partitions 1, 2, 4, and 8. Byte6 bit7 seems to be fire alarm. Tested several times, it only flips when fire-related alarm is going on, no matter of section 013 option 8.

Great, thanks! Added in develop.

Just tested and it behaves same. Only difference I see when [0xCE] saying "Unknown data" is related to change of byte3, especially bit5 being zero. Wherever bit5 is true, [0xCE] correctly display informations. And in source I see that byte3 is responsible for printing "Unknown data":

Found the 0xCE bug, it was a typo while migrating code from a testing tool to the library code - the first line should be checking byte 2, not 3. Fixed in the latest develop commit:

void dscKeybusInterface::printPanel_0xCE() {
  if (panelData[3] & 0x20) {
    switch (panelData[3] & 0x03) {

Should be:
void dscKeybusInterface::printPanel_0xCE() {
  if (panelData[2] & 0x20) {
    switch (panelData[3] & 0x03) {

BTW, I think I can also log output for RF zone deliquency trouble and decode it.

Sounds good! Filling in Keybus data gaps is always appreciated.

I forgot to say, current develop branch is saying "Unknown data" after each keypress:

Fixed, I've been consolidating a bunch of code for KeybusReader and there will probably be a few bugs, please let me know of any issues.

For now I've been testing the Keybus decoding code with a little CLI tool based off of the library's RTOS port, which I'll be adding to the repository. Runs on macOS and Linux (haven't tried Windows), takes KeybusReader log data either directly input line by line or multiple lines from a file, and parses the data with the current code. It's a quick hack but handy for looking at logs or simulating Keybus data.