[QUESTION] Zone Expander

[jpmartin-gicom]

GREAT WORK!

Did anyone found the way to also act as a zone expander? Would be very nice to add "virtual" sensors or zones. I couldn't find any reference/information on how zones expanders work. If someone has any guess we might work on it! Thanks in advance.

[Zippair]

Hi! I hope, I will test a zone expander (dsc5108) next week, but I think, it’s easy to use, for example in homebridge config.json just you have to write the zone number.

[jpmartin-gicom]

Thank you for your answer Zippair, but I think might has been a misunderstanding. I meant to use the ESP8266 (for example) as a zone expander. Meaning that you can use it as a panel and also, to use the GPIO of the ESP8266 as new zones of the system.
I hope I was clear enough. Also, let me know if I can help you, maybe to reverse engineer the DSC5108. Once again, thank you a lot!

[taligentx]

Hi @jpmartin-gicom - in theory this is possible, I picked up a 5108 module to decode its protocol quite a while ago but haven't gotten around to it. It would be a matter of checking out the data in the KeybusReader sketch before adding the 5108 and then seeing the changes after it is connected. It'd be great if anyone is able to break down the protocol - it'd make implementation much quicker.

I'll leave this issue open for all interested in this feature request to comment.

[cmer]

I am also looking at a way to create "virtual" zones I could trigger over MQTT. Google led me here. Specifically, I was to use cameras as motion sensors.

[Dilbert66]

Nikhil, I'm currently working on adding zone expander and relay module emulation to the library. I have a bit of the protocol decoded currently so will start coding up some test functions soon. I will post a pull request to your repository when I have something working, unless you want to code it yourself. No problem with me. It's an interesting project. Either way, I believe it will be a great addon on to this great implementation you have here. The relay module should also be fairly simple to add once the zone expander is done as the framework should be there.

There are a few more commands to add that are used to retrieve the zone statuses from the board, such as 0x28, 0x33,0x39 and E6 subcommands 0x08,0x0A,0x0C,0x0E depending on what zone range the panel is requesting (what module has requested to send),

Supervision is the same as a keypad, the panel sends cmd 0x11 and the module sends it's address in the appropriate slot 9,10,11,12,13,14,16 (depending on the zone range selected) where 9 = 9 -16 . ( Slot 15 is used for the PC510x module. )
One oddball in this is what should be slot address 16 (zones 57-64), actually reports itself in slot 24 (0x11 response) but the panel registers it as being in slot 16 .

As far as the channel updates are concerned, the module sends it's changes in groups of 4 channels (low ,high) . The first byte is current state and 2nd byte is previous state. There is a checksum (last byte), that adds the nibbles of each 2 byte groups and does a modulo % 10 and sends it in the appropriate nibble of the last byte of the response. Terminated is 11, open is 00, and a short is 01.
If events happen at the same time, the module with send both low,high group data on the same request. Normally for one channel change event, it only sends the low or high group info that the channel is on. For the lower end zone ranges, the response starts on bit 10. For the higher zone ranges (response to 0xE6), response starts on bit 18.

Th initial request to send occurs on the 0x05 command. The module will send it's programmed zone slot by setting a bit to 0 in either byte4 for slots 9,10,11 and byte5 for slots 12,13,14 and 15 (in this case device 16 sets zone slot 15). Bit0=first zone slot, bit2=2nd and so on. The panel will respond with either 0x28,0x33,0x39, 0xE6 depending on the zone slot. The module will then send it's channel status update. The panel will then respond with a general zone update message to update the bus.

I think that covers most of it. I did see why you needed that 250us delay before bit sampling. I'm using pulseview to capture the raw bits and it sometimes misses some delayed bits because the decoder I use triggers on rising/falling edges of the clock and I don't have a setting to delay the sampling.

What analyzer do you use? I was contemplating cobling up a decoder for sigrok but didnt think it was worth it as your code does a very good job decoding the raw data.

[Dilbert66]

I did some tests using hard coded values to test the logic and everything seems good. I can respond to a supervision requests with a emulated zone. Also can request a zone update for zone 9, have the panel respond with cmd 0x28, where I then send back the fault response back on that cmd. It accepts it fine. So looks like the logic above is on right track.

[Dilbert66]

Relay modules are easy. They are represented for supervision on slot 15 on the 0x11 command and are controlled via cmd 0x87 byte 2. Each channel is one bit. 1 for on and 0 for off.

Ok I have zone emulation working for all ranges on my test system. I'll push a pull request soon once I clean it up a bit and merge the code to the current dev branch. The system should support modules for all slots. Of course the true test is how many simultaneous zone events can it process at once from multiple emulated boards. That would need to be tested further.

I'll add the relay emulation too since it's a fairly easy add on.

[taligentx]

Nikhil, I'm currently working on adding zone expander and relay module emulation to the library. I have a bit of the protocol decoded currently so will start coding up some test functions soon. I will post a pull request to your repository when I have something working, unless you want to code it yourself.

Hi Alain, this is fantastic work, thanks for sharing the expander logic! And PRs are always welcome, but no worries if it's even just test code - I wouldn't be surprised if adding the expander code will require restructuring the code (for example, I'll be splitting off some functionality for Arduino). Getting the protocol decoded is great, it's been on the TODO list for a long time.

The relay module should also be fairly simple to add once the zone expander is done as the framework should be there.

Are you referring to the PC5100 addressable zone expander, PC5208 programmable output module, or a different module?

One oddball in this is what should be slot address 16 (zones 57-64), actually reports itself in slot 24 (0x11 response) but the panel registers it as being in slot 16 .

How many bytes is the 0x11 command on your PC5010 with the zone expander installed? I'm curious how slot 24 is represented, as normally 0x11 has 5 data bytes, with 2 bits per keypad slot = 20 slots (unless the expander and other modules use 1 bit per slot).

Also, is your PC5010 using firmware 2.x or is it one of the apparently few that shipped with 3.x firmware? I'm curious if there's a difference at the Keybus level for the different configuration modes of the PC5108 - per the PC5108 documentation:

On control panels with software versions 3.x and higher, the PC5108 v2.0 will operate in a single group of eight zones.
On control panels with software versions 2.x and lower, the PC5108 v2.0 will operate in two groups of four zones. 

What analyzer do you use?

I used an Arduino as an improvised logic analyzer with sigrok, it was a quick hack but enough to bootstrap the interrupt-driven code to be reliable enough that a real logic analyzer wasn't necessary. Since then, I've only used the library code - the goal is for KeybusReader to be representative of the Keybus. I really should pickup one of the Saleae Logic interfaces or their clones one of these days.

Ok I have zone emulation working for all ranges on my test system. I'll push a pull request soon once I clean it up a bit and merge the code to the current dev branch.

Sounds great - I've added a new branch expander with a few placeholders for the commands you've described that can be used for PRs related to expander modules. Again, no worries if the code is basic test code for functionality, I have a few other code changes in mind that I'll see about implementing at the same time - for one, the library has no handling for simultaneous writes (collisions) by the library and physical keypads, and this may be required to deal with simultaneous events on multiple expander modules.

-Nikhil

[Dilbert66]

That's interesting on the length of your 0x11. Mine has 7 data bytes. My test panel version is 4.60 (according to the sticker on it) and the zone expander is a pc5108 version 2.0. The relay board I have is pc 5208. I'm sure there is a version differential with how the zone panels work as you noted. Some panels do not support the higher zone ranges. Here's a sample of the slot 16 interactions. First group is the supervisory, 2nd is a channel update from the zone expander. My main system is an older panel but I'd rather not test on that one yet and upset the family :)

As to collisions, that should not happen hopefully as I am using a queue based update process so that only one update can be sent at a time, first in , first out type thing. I'll post a link to my github dev branch shortly with the latest updates.

'''
slot 14
11581.54:[PANEL] 00010001 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x11] Keypad slot query
11581.54:[MODULE] 11111111 1 00111111 11111111 11111111 11001111 11111111 11111111 11111111 [Keypad] Slots active: 1

slot 24 (for range 16)
54150.52:[PANEL] 00010001 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x11] Keypad slot query
54150.52:[MODULE] 11111111 1 00111111 11111111 11111111 11111111 11111111 11111100 11111111 [Keypad] Slots active: 1

range 57-64 uses slot 15 for the request to send update
slot 15 (for range 16) channel 2 fault request to send plus 0xE6 response
53276.91:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 11101111 11111111 11111111 [Keypad] Unknown key: 0xFF
53276.99:[PANEL] 11100110 0 00001110 11111111 11111111 11111111 11111111 11111111 11111111 [0xE6] [CRC Error]
53277.00:[MODULE] 11111111 1 11111111 11000011 11001111 11111111 11111111 10101111 11111111
'''

[Dilbert66]

Here's a dump of the 0x05 responses to a request to send command from the module for various slot ranges.
04 54.61:[MODULE] 11111111 1 11111111 11111111 10111111 11111111 11111111 11111111 11111111 11111111 9
0 321.61:[MODULE] 11111111 1 11111111 11111111 11011111 11111111 11111111 11111111 11111111 11111111 10
064 8.68:[MODULE] 11111111 1 11111111 11111111 11101111 11111111 11111111 11111111 11111111 11111111 11
09 61.55:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 01111111 11111111 11111111 12
11116.10:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 10111111 11111111 11111111 13
2 022.21:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 11011111 11111111 11111111 14
3275.73:[MODULE] 11111111 1 11111111 11111111 11111111 11111111 11111111 11101111 11111111 11111111 16

[Dilbert66]

I've been using a Salae clone for most bus work. It's great when you want to check your timings, etc. It was really handy with the honeywell vista bus since the protocol decoders did a great job decoding the uart traffic. With the DSC bus, it's different since you have the rising/falling clock data differenatial so you need two separate synchronous decoders decoding traffic on both clock phases. Unfortunately, the timing of the module/keypad data is delayed from the rising/falling and the decoders fail to capture all bits. I'd have to cobble up a delay with those. Like, you I just used the keybusreader code to analyze the bus and it worked awesome. Great work you did on that.

[Dilbert66]

Here's a link to my current development code.

https://github.com/Dilbert66/esphome-dsckeybus/tree/dev

This is the ESPhome version but the code in the folder dsckeybusinterface should be the same as your dev version (plus a couple other changes that I did a previous pull request for ie debouncing ).

There were a few changes to the both ISR functions for sending responses.etc. I've tried to minimize the time and memory impact of having the ISR routines call functions (in IRAM) by trying to setup many variables outside of the ISR first and storing within a structure with the module info.

The function to add a module are addModule(address). address is any slot address 9-16
The new function to turn on or turn off a zone fault is setZoneFault(byte zone, bool fault). where zone can be 9 - 64 if your system supports it. If your 0x11 only sends 5 bytes, then you are limited to maybe max 56?

I'll copy this code to a clone of your expander branch then create a pull request on it later today.

[Dilbert66]

For the relay module, you add it using addRelayModule() and view channels looking at relayStatusChanged and relayChannels

eg:
if (dsc.relayStatusChanged) {
Serial.print(dsc.relayChannels,HEX);

[Dilbert66]

ok, PR created on the expander branch.

[Dilbert66]

Still needs work to make it configurable for different systems such as those that only support up to 32 zones. Would be nice to see dumps on those systems.

[taligentx]

That's interesting on the length of your 0x11. Mine has 7 data bytes.

As you mentioned, it's 5 data bytes on older panels before 64 zones was designed into the firmware, this was based on the logs in dscKeybusPrintData.cpp that are mostly from a PC1555MX. That panel is in production these days so I'll have to see about either getting logs or getting another older panel as I test with a PC1864 these days. As far as the code, it can likely be handled by checking the length of the 0x11 command and acting accordingly.

ok, PR created on the expander branch.

Merged and thanks for the contribution! It'll be a month or so until I can get hands on hardware to test but will make sure this gets into the next release.

[Dilbert66]

The 05 command differs as well. Mine has 8 data bytes while the older panels as seen in your dumps, show 4 bytes.

My pleasure for the contribution. It was a good project. Code still needs tweaking and work to support older/smaller panels correctly. I put a basic config setting called maxZones with a default of 32. This adjusts all the responses to fit within the older command sizes. If the setting is set higher than 32, then the code will use the larger versions. This needs checking for sure.

[Dilbert66]

Another note. Module supervision is not required for the expander to function normally. In the emulation code, I added a config to control this. This makes it easier for testing as by default I do not set the cmd11 supervision flags for the module (controlled by the flag). This way the panel will not set a trouble condition when new firmware is pushed since the delay will cause the module to disappear temporarily (and alert the monitoring provider if monitored) . There really is no need to supervise an emulated expander . We just need the functionality of setting /clearing zone faults. If users want to have it supervised they can just set the flag.

[taligentx]

Hi Alain, do you have KeybusReader logs for the PC5208 (the PGM relay module)? They'd be helpful for debugging - for example, it'd be handy to see logs while the PC5208 tamper switch is closed and then tripped. I was looking at getUpdateMask(), case 18 for the relay module and it looks like that would set the same bit as the tamper bit for the PC5108 zone expanders as seen in @kricon's logs in #166. If so, it'd be good to see how the relay module responds to the 0x4C query to indicate tamper:

zoneMaskType dscKeybusInterface::getUpdateMask(byte address) {
(...)
        switch (address) {
            case 9:  zm.idx=2;zm.mask=0xbf; break; //5208
(...)
            case 18: zm.idx=2;zm.mask=0xfe; break; //relay board 5108 sends to slot 16

PC5108 zone expander tamper:
11111111 1 11111111 11111111 11111110 11111111 [Module/0x05] Module tamper notification
01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Module tamper query
11111111 1 11111111 11111111 11111111 11110000 00111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 [Module/0x4C] Module tamper: Slot 9

Here's what I currently have for module responses to 0x05/0x1B - the mask you have for the relay module matches the module tamper notification bit:

 *  Module data during panel commands 0x05, 0x1B: Panel status
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 2: Partition 1 keypad keys
 *  Byte 3: Partition 2 keypad keys
 *  Byte 4 bit 0: Module tamper notification, panel response: 0x4C Module tamper query
 *  Byte 4 bit 1-2: Unknown
 *  Byte 4 bit 3: Wireless module battery notification, panel response: 0x41 Wireless module query
 *  Byte 4 bit 4: Zone expander slot 11 notification, panel response: 0x39 Zone expander slot 11 query
 *  Byte 4 bit 5: Zone expander slot 10 notification, panel response: 0x33 Zone expander slot 10 query
 *  Byte 4 bit 6: Zone expander slot 9 notification, panel response: 0x28 Zone expander slot 9 query
 *  Byte 4 bit 7: Zone expander slot 8 notification, panel response: 0x22 Zone expander slot 8 query
 *  Byte 5 bit 0-1: Unknown
 *  Byte 5 bit 2: Keypad zone status notification, panel response: 0xD5 Keypad zone query
 *  Byte 5 bit 3-4: Unknown
 *  Byte 5 bit 5: Module status notification, panel response: 0x58 Module status query
 *  Byte 5 bit 6-7: Unknown
 *
 *  Later generation panels:
 *  Byte 6: Unknown
 *  Byte 7 bit 0-3: Unknown
 *  Byte 7 bit 4: Zone expander slot 16 notification, panel response: 0xE6.0E Zone expander slot 16 query
 *  Byte 7 bit 5: Zone expander slot 14 notification, panel response: 0xE6.0C Zone expander slot 14 query
 *  Byte 7 bit 6: Zone expander slot 13 notification, panel response: 0xE6.0A Zone expander slot 13 query
 *  Byte 7 bit 7: Zone expander slot 12 notification, panel response: 0xE6.08 Zone expander slot 12 query
 *  Byte 8: Unknown
 *  Byte 9: Unknown
 *
 *  00000101 0 10000001 00000001 10010001 11000111 [0x05] Partition 1: Ready Backlight - Partition ready | Partition 2: disabled
 *  11111111 1 00000101 11111111 11111111 11111111 [Module/0x05] Partition 1 Key: 1
 *  11111111 1 11111111 00010001 11111111 11111111 [Module/0x05] Partition 2 Key: 4
 *  11111111 1 11111111 11111111 01111111 11111111 [Module/0x05] Zone expander notification: Slot 8
 *  11111111 1 11111111 11111111 10111111 11111111 [Module/0x05] Zone expander notification: Slot 9
 *  11111111 1 11111111 11111111 11011111 11111111 [Module/0x05] Zone expander notification: Slot 10
 *  11111111 1 11111111 11111111 11101111 11111111 [Module/0x05] Zone expander notification: Slot 11
 *  11111111 1 11111111 11111111 11110111 11111111 [Module/0x05] Wireless module battery notification
 *  11111111 1 11111111 11111111 11111110 11111111 [Module/0x05] Module tamper notification
 *  11111111 1 11111111 11111111 11111111 11011111 [Module/0x05] Module status notification
 *  11111111 1 11111111 11111111 11111111 11111011 [Module/0x05] Keypad zone notification
 *  11111111 1 11111111 11111111 11111111 11111111 11111111 01111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 12
 *  11111111 1 11111111 11111111 11111111 11111111 11111111 10111111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 13
 *  11111111 1 11111111 11111111 11111111 11111111 11111111 11011111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 14
 *  11111111 1 11111111 11111111 11111111 11111111 11111111 11101111 11111111 11111111 [Module/0x05] Zone expander notification: Slot 16

For the response to 0x11 supervision, you mentioned that the PC5208 uses slot 15, logs of this would be handy as well - for earlier generation panels, I'm curious if it uses 4 bits like the zone expanders or if it's only using 2 bits like with later panels. By the way, can you confirm the relay module mask in setSupervisorySlot()? It's currently 0xFC for bits 0-1 but slot 15 would be 0xF3 for bits 2-3 on later panels and maybe 0xF0 bits 0-3 on earlier panels:

void dscKeybusInterface::setSupervisorySlot(byte address,bool set=true) {
       //set our response data for the 0x11 supervisory request
       if (panelVersion < 3) {
            switch (address) {
            //11111111 1 00111111 11111111 11111111 11111111 11111111 11111100 11111111 16
            //11111111 1 00111111 11111111 11111111 00111111 11111111 11111111 11111111 13
            // 1111111 1 00111111 11111111 00111111 11111111 11111111 11111111 11111111 slots 9
            //11111111 1 00111111 11111111 11111111 11111111 11111111 11111100 11111111 slots 16
             //for older versions we need to set 2 slots since they expect groups of 4 zones per slot
            case 9:   moduleSlots[2]=set?moduleSlots[2]&0x3f:moduleSlots[2]|~0x3f; //pc5108 
                      moduleSlots[2]=set?moduleSlots[2]&0xcf:moduleSlots[2]|~0xcf;
                      break; 
            case 10:  moduleSlots[2]=set?moduleSlots[2]&0xf3:moduleSlots[2]|~0xf3; //pc5108
                      moduleSlots[2]=set?moduleSlots[2]&0xfc:moduleSlots[2]|~0xfc;
                      break; 
            case 11:  moduleSlots[3]=set?moduleSlots[3]&0x3f:moduleSlots[3]|~0x3f;//pc5108
                      moduleSlots[3]=set?moduleSlots[3]&0xcf:moduleSlots[3]|~0xcf;
                      break; 
            case 18:  moduleSlots[3]=set?moduleSlots[3]&0xfc:moduleSlots[3]|~0xfc;break;

Current decoding for module response to 0x11:

 *  Module data during panel command 0x11: Module supervision query
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 2 bit 0-1: Keypad slot 4
 *  Byte 2 bit 2-3: Keypad slot 3
 *  Byte 2 bit 4-5: Keypad slot 2
 *  Byte 2 bit 6-7: Keypad slot 1
 *  Byte 3 bit 0-1: Keypad slot 8
 *  Byte 3 bit 2-3: Keypad slot 7
 *  Byte 3 bit 4-5: Keypad slot 6
 *  Byte 3 bit 6-7: Keypad slot 5
 *
 *  Early generation panels:
 *  Byte 4 bit 0-3: Zone expander slot 10
 *  Byte 4 bit 4-7: Zone expander slot 9
 *  Byte 5 bit 0-1: PC5208 PGM module (?)
 *  Byte 5 bit 2-3: PC5208 PGM module (?)
 *  Byte 5 bit 4-7: Zone expander slot 11
 *  Byte 6: Unknown
 *
 *  00010001 0 10101010 10101010 10101010 10101010 10101010 [0x11] Module supervision query
 *  11111111 1 00111111 11111111 11111111 11111111 11111111 [Module/0x11] Keypad slots: 1
 *  11111111 1 11111111 11111100 00001111 11111111 11111111 [Module/0x11] Keypad slots: 8 | Zone expander slots: 9
 *
 *  Later generation panels:
 *  Byte 4 bit 0-1: Zone expander slot 12
 *  Byte 4 bit 2-3: Zone expander slot 11
 *  Byte 4 bit 4-5: Zone expander slot 10
 *  Byte 4 bit 6-7: Zone expander slot 9
 *  Byte 5 bit 0-1: Unknown
 *  Byte 5 bit 2-3: PC5208 PGM module
 *  Byte 5 bit 4-5: Zone expander slot 14
 *  Byte 5 bit 6-7: Zone expander slot 13
 *  Byte 6: Unknown
 *  Byte 7 bit 0-1: Zone expander slot 16
 *  Byte 7 bit 2-7: Unknown
 *  Byte 8: Unknown
 *
 *  00010001 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x11] Module supervision query
 *  11111111 1 00111111 11111111 00001111 11110011 11111111 11111111 11111111 [Module/0x11] Keypad slots: 1 | Zone expander slots: 9 10 | PC5208
 *  11111111 1 00111111 11111111 11001111 11111111 11111111 11111100 11111111 [Module/0x11] Keypad slots: 1 | Zone expander slots: 10 16

And finally, I'm looking at the 0x87 PGM command layout in dscAlarm.h, can you verify that 0x87 byte 2 bit 0 (right-most, least bit) = PGM 3/PC5208 output 1 ... byte 2 bit 7 = PGM 10/PC5208 output 8? Still unknown if 0x87 also controls the PC5204 power supply module for PGM 11-14 - perhaps it uses byte 3 bits 4-7.

Current 0x87 decoding - the "Bell on" command is likely wrong, 0x87 is probably purely about the PGMs and not related to the siren at all:

 *  0x87: Panel PGM outputs
 *  CRC: yes
 *  Structure decoding: *incomplete
 *  Content decoding: *incomplete
 *
 *  Byte 2, 11111111: Bell on
 *  Byte 2 bit 0: PGM 3 status
 *  Byte 2 bit 1: PGM 4 status
 *  Byte 2 bit 2-7: Unknown
 *  Byte 3 bit 0: PGM 1 status
 *  Byte 3 bit 1: PGM 2 status
 *  Byte 3 bit 2-7: Unknown
 *  Byte 4: CRC
 *
 *  10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
 *  10000111 0 00000000 00000001 10001000 [0x87] Panel output: Bell off | PGM1 on | PGM2 off | PGM3 off | PGM4 off
 *  10000111 0 00000000 00001000 10001111 [0x87] Panel output: Bell off | Unknown data | PGM3 off | PGM4 off
 *  10000111 0 00000001 00000011 10001011 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 off
 *  10000111 0 00010001 00000010 10011010 [0x87] Panel output: Bell off | PGM1 off | PGM2 on | PGM3 on | PGM4 off
 *  10000111 0 00010011 11110011 10001101 [0x87] Panel output: Bell off | PGM1 on | PGM2 on | PGM3 on | PGM4 on
 *  10000111 0 00010011 00000000 10011010 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 on | PGM4 on
 *  10000111 0 11111111 11110000 01110110 [0x87] Panel output: Bell on | PGM1 off | PGM2 off
 *  10000111 0 11111111 11110010 01111000 [0x87] Panel output: Bell on | PGM1 off | PGM2 on

Thanks,
Nikhil

[Dilbert66]

Not a problem Nikhil, I'll hook up the modules and get some logs. That's one thing I have not tested much is the tamper since I wasnt planning on emulating that :). Interesting about the slot arrangement conflict there. As to the cmd87, I'll get you more info on that too.

I have to get some paying work done too :) I"m contract software developer as well! C++ though i'm very rusty at since it's not my primary tool!

[kricon]

Current 0x87 decoding - the "Bell on" command is likely wrong, 0x87 is probably purely about the PGMs and not related to the siren at all:

Yeah, Byte2 certainly isn't Bell status. See my logs #166.

  *  Byte 2 bit 0-7: PGM 3-10 status
  *  Byte 3 bit 0: PGM 1 status
  *  Byte 3 bit 1: PGM 2 status
  *  Byte 3 bit 4-7: PGM 11-14 status
  *  Byte 4: CRC

I've checked data output for PGM outputs 3-14. Tamper decoding for PC5208 is still pending though.
Can the remaining Byte3 bit2 and bit3 possibly be local keypad PGM outputs 15 local pulse and 16 local toggle from PK55XX, maybe for record in event buffer? I wont be able to check it for few weeks, I dont have PK55XX keypad handy at the moment.

BTW: There are some minor issues while more than one module tamper is present. While RF5132 was in tamper condition, I restored tamper on PC5204 and 0x4C responded saying RF5132 tamper and restore in same message.

07:10:13.260 -> 16360.07: 00010110 0 00001110 00110010 11110101 01001011 [0x16] Panel version: v3.2 | Zone wiring: NC | Code length: 4 digits | *8 programming: no 
07:10:29.907 -> 16376.68: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Module/0x05] Module tamper notification 
07:10:30.043 -> 16376.84: 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Module tamper query
07:10:30.078 -> 16376.85: 11111111 1 11111111 11111111 11111111 11110000 11111111 11111111 11111111 00001111 11001111 11111111 11111111 11111111 11111111 [Module/0x4C] RF5132: Tamper | RF5132: Tamper restored | PC5204: Tamper restored 
07:10:30.112 -> 16376.88: 10000111 0 00000000 00000010 10001001 [0x87] Panel output: Bell off | PGM1 off | PGM2 on | PGM3 off | PGM4 off
07:10:30.180 -> 16376.97: 10100101 0 00100000 00101101 01100110 01100111 01000101 11111111 00000011 [0xA5] 2020.11.11 06:25 | PC5204: Tamper restored
07:10:30.386 -> 16377.16: 11101011 0 00000000 00100000 00101101 01100110 01100100 00000011 01000101 11111111 01001001 [0xEB] 2020.11.11 06:25 | PC5204: Tamper restored
07:10:49.315 -> 16396.06: 11100110 0 00101100 00000010 00000000 00000000 00000000 00000000 00010100 [0xE6.2C] Partition 2 | Enabled zones 33-64: none

[Dilbert66]

My testing agrees with krikon on the 0x87 pgm outputs. ie pgm1-14. As far as the dscalarm.h decoding goes, I was more concerned with the pc5208 relay board channel decoding so focused only on byte2 where I numbered the channels 1-8. which in actuallity correspond to PGM3-10. I will change the decoding to do the full range of pgm1-14.

For the pc5208 supervisory slot, it is indeed 16, not 15 so the mask of 0xfc is correct. I probably stated the wrong slot in a previous comment. From my testing, it looks like the pc5208, pc5108 and rf5132 ( i will post logs later), all use the same 05 slot to indicate a tamper and the resultant 0x4c response will hold all devices tamper statuses . Basically they all respond on the same command but different response slots.

I should remove the pc5208 relay board from the getupdatemask code group as it's really a tamper update and not a status update like the pc5108 expander. The pc5208 has no two way communications (that i've seen anyways) except for supervision and tamper. I put it there really for a placeholder. That tamper update mask is shared with other devices as noted.

Krikon has done a great job posting the device logs and mine match what he has. We just need versions from older panels (version 2.0 ) as you indicated. My older panel is my main house panel so it's bit tricky to get to for logging so that will take me some time.

[Dilbert66]

Examples. All are done by first pressing the tamper switch then release. These were all from a pc1832 ver 4.6 panel

PC5108 
zone 9-16 
40087.86:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
40088.02:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
40088.02:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11001111 11111111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
40088.07:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
40088.14:[PANEL] 10100101 0 00100000 00001001 10000000 00011111 00110101 11111111 10100001 [0xA5] 2020.02.12 00:07 | Unknown data :6
40088.32:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 00011100 00000011 00110101 11111111 11100111 [0xEB] 2020.02.12 00:07 | Unknown data :8
40089.90:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
40090.07:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
40090.07:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 00111111 11111111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
40090.11:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
40090.19:[PANEL] 10100101 0 00100000 00001001 10000000 00011111 00111011 11111111 10100111 [0xA5] 2020.02.12 00:07 | Unknown data :6
40090.37:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 00011100 00000011 00111011 11111111 11101101 [0xEB] 2020.02.12 00:07 | Unknown data :8

pc5108
zone range 24-31
42578.39:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
42578.55:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
42578.55:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 11001111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
42578.59:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
42578.66:[PANEL] 10100101 0 00100000 00001001 10000000 11000011 00110111 11111111 01000111 [0xA5] 2020.02.12 00:48 | Unknown data :6
42578.84:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 11000000 00000011 00110111 11111111 10001101 [0xEB] 2020.02.12 00:48 | Unknown data :8
42580.11:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
42580.27:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
42580.27:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 00111111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
42580.30:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
42580.39:[PANEL] 10100101 0 00100000 00001001 10000000 11000011 00111101 11111111 01001101 [0xA5] 2020.02.12 00:48 | Unknown data :6
42580.57:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 11000000 00000011 00111101 11111111 10010011 [0xEB] 2020.02.12 00:48 | Unknown data :8

PC5208
42800.85:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
42801.02:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
42801.02:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 00001111 11111111 11111100 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
42801.05:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
42801.13:[PANEL] 10100101 0 00100000 00001001 10000000 11010011 01000011 11111111 01100011 [0xA5] 2020.02.12 00:52 | Unknown data :6
42801.30:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 11010000 00000011 01000011 11111111 10101001 [0xEB] 2020.02.12 00:52 | Unknown data :8
42802.49:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
42802.66:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
42802.66:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 00001111 11111111 11110011 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
42802.71:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
42802.78:[PANEL] 10100101 0 00100000 00001001 10000000 11010011 01000100 11111111 01100100 [0xA5] 2020.02.12 00:52 | Unknown data :6
42802.96:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 11010000 00000011 01000100 11111111 10101010 [0xEB] 2020.02.12 00:52 | Unknown data :8


PC5132 
  165.51:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
  165.68:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
  165.69:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 00001111 11111111 11000000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
  165.72:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
  165.79:[PANEL] 10100101 0 00100000 00001001 10000000 00001011 01000001 11111111 10011001 [0xA5] 2020.02.12 00:02 | Unknown data :6
  165.97:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 00001000 00000011 01000001 11111111 11011111 [0xEB] 2020.02.12 00:02 | Unknown data :8
  166.29:[MODULE] 5: 11111111 1 11111111 11111111 11111110 11111111 11111111 11111111 11111111 11111111 [Keypad] Unknown Keybus notification
  166.46:[PANEL] 01001100 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x4C] Keybus query
  166.47:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11111111 00001111 11111111 00110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
  166.50:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
  166.59:[PANEL] 10100101 0 00100000 00001001 10000000 00001011 01000010 11111111 10011010 [0xA5] 2020.02.12 00:02 | Unknown data :6
  166.76:[PANEL] 11101011 0 00000000 00100000 00001001 10000000 00001000 00000011 01000010 11111111 11100000 [0xEB] 2020.02.12 00:02 | Unknown data :8

[taligentx]

I've checked data output for PGM outputs 3-14. Tamper decoding for PC5208 is still pending though. Can the remaining Byte3 bit2 and bit3 possibly be local keypad PGM outputs 15 local pulse and 16 local toggle from PK55XX, maybe for record in event buffer?

@kricon Thank you! I've updated 0x87 to reflect PGM output 1-14. As far as PGM 15/16, it seems reasonable to be byte 3 bits 2-3, but I've left these bits undecoded pending confirmation.

There are some minor issues while more than one module tamper is present. While RF5132 was in tamper condition, I restored tamper on PC5204 and 0x4C responded saying RF5132 tamper and restore in same message.

I've reworked the module tamper response decoding - it looks like 0000 indicates a module is already in tamper, while 0011 indicates a new tamper. By the way, have you seen the 5204 respond to a supervisory slot (response to 0x11 query)? I'm curious which slot it uses.

Examples. All are done by first pressing the tamper switch then release. These were all from a pc1832 ver 4.6 panel

@Dilbert66 Thank you! Added the the PC5208 tamper and the 0xA5/0xEB status commands:

Before:
40088.02:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11001111 11111111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Keypad] 3
40088.07:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] Panel output: Bell off | PGM1 off | PGM2 off | PGM3 off | PGM4 off
40088.14:[PANEL] 10100101 0 00100000 00001001 10000000 00011111 00110101 11111111 10100001 [0xA5] 2020.02.12 00:07 | Unknown data :6

Now:
40088.02:[MODULE] 4C: 11111111 1 00001111 11111111 11111111 11111111 11001111 11111111 11111111 11110000 11111111 11111111 11111111 11111111 11111111 [Module/0x4C] Keypad tamper: Slot 1 | Module tamper restored: Slot 9 | PC5208: Tamper 
40088.07:[PANEL] 10000111 0 00000000 00000000 10000111 [0x87] PGM outputs enabled: none
40088.14:[PANEL] 10100101 0 00100000 00001001 10000000 00011111 00110101 11111111 10100001 [0xA5] 2020.02.12 00:07 | Module tamper restored: Slot 9

For the pc5208 supervisory slot, it is indeed 16, not 15 so the mask of 0xfc is correct.

Thanks for confirming, I've updated the 5208 supervisory to slot 16 (byte 5 bits 0-1) - this is synthetic data but hopefully matches the panel output:

00010001 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x11] Module supervision query
11111111 1 00111111 11111111 11111111 11111100 11111111 11111111 11111111 [Module/0x11] Keypad slots: 1 | PC5208

I'm curious about what module is reporting in slot 15, I've seen a few logs with that supervisory slot populated (this is from a PC1864 in #2):

00010001 0 10101010 10101010 10101010 10101010 10101010 10101010 10101010 [0x11] Module supervision query
11111111 1 00111111 11111111 00001111 11110011 11111111 11111111 11111111 [Module/0x11] Keypad slots: 1 | Zone expander slots: 9 10 | Unknown module

Interesting about the slot arrangement conflict there. As to the cmd87, I'll get you more info on that too.
I have to get some paying work done too :) I"m contract software developer as well!

Yep, this is still very much a hobbyist project so it's been great to have contributions like yours. By the way, feel free to point out any/all bad coding practices that you notice here, I'm not a developer by trade so I'm sure there's quite a bit to optimize.

[kricon]

@kricon Thank you! I've updated 0x87 to reflect PGM output 1-14. As far as PGM 15/16, it seems reasonable to be byte 3 bits 2-3, but I've left these bits undecoded pending confirmation.

No problem. I'm glad I can help. I will check if PGM15-16 are indeed byte3 bits2-3 as soon as I get PK5500 available (should be in few weeks).

I've reworked the module tamper response decoding (...). By the way, have you seen the 5204 respond to a supervisory slot (response to 0x11 query)? I'm curious which slot it uses.

Look like tamper decoding now works fine. PC5204 respond with setting byte6 bit6-7 low (slot17?)
4622.30: 11111111 1 11111111 11111100 00111111 11111111 00111111 11111111 11111111 [Module/0x11] Keypad slots: 8 | Zone expander slots: 9 //PC5204 connected on keybus

I'm curious about what module is reporting in slot 15, I've seen a few logs with that supervisory slot populated (this is from a PC1864 ):

PC5132/RF5132/any keyboard with RF module integrated (byte5, bit2-3):
114.28: 11111111 1 11111111 11111100 00111111 11110011 11111111 11111111 11111111 [Module/0x11] Keypad slots: 8 | Zone expander slots: 9 | Unknown module //rf5132 present on keybus

BTW, just as note: keypad tampers seem to have same quirk as for disabled zone faults, if keypad tampers are disabled keybusreader will still log the keypad in tamper condition. Which is somewhat expected, as keypad report tamper condition but the panel just ignores it (as its disabled in programming), and its communicated thru keybus. With RF5132, you can disable tampers directly in [804] wireless expander programming so it doesnt send it thru keybus.

And I suppose that panels which have only 1 partition (like PC585) sometimes send 0x27 cmd bytes 4&5 with 0x00:

   80.65: 00100111 0 10010001 00000001 00000000 00000000 00000000 10111001 [0x27] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: none - Unknown data: 0x00 | Zones 1-8 open: none 
   81.80: 00100111 0 10010001 00000001 10010001 11000111 00000000 00010001 [0x27] Partition 1: Ready Trouble Backlight - Partition ready | Partition 2: disabled | Zones 1-8 open: none 

[taligentx]

Thanks! I've updated the supervisory for the 5204 and RF wireless, as well as disabled partitions.

BTW, just as note: keypad tampers seem to have same quirk as for disabled zone faults, if keypad tampers are disabled keybusreader will still log the keypad in tamper condition. Which is somewhat expected, as keypad report tamper condition but the panel just ignores it (as its disabled in programming), and its communicated thru keybus. With RF5132, you can disable tampers directly in [804] wireless expander programming so it doesnt send it thru keybus.

Good to know, yep it does seem like the modules (at least the keypads) aren't getting any data from the panel to disable their tampers if not in use.

[juanpmartin]

Guys, you've done a great job! I'm trying to test the branch expander, but I wasn't able to make any progress. Sorry for my luck of knowledge of the protocol. If you could provide anything (a very simple example would be great) to test the expander functionality would be great. If so, I could make it better to publish it as another example bundled with the library. Once again, thanks a lot!

[rburkholder]

For those coming here like I did, note that the expander branch is deprecated. There is a #290 (comment) pull request outstanding with revised code.