DSC Classic series support testing/feedback

[taligentx]

Support for DSC PC1500/PC1550 is now in develop - this uses the same interrupt-based data capture as the PowerSeries, and like dougkpowers/pc1550-interface, requires configuring the panel PGM in PC16 mode.

Most sketches are supported and require minimal changes, excluding TimeSync-NTP (should be possible to support) and Unlocker (likely will not be supported as there is very little data feedback on the Classic series Keybus). Edit: Unlocker now supports Classic series (2024.03)

Post results from testing/feedback here - if you have a PC2500/2550/3000 panel, data captures from KeybusReader would be useful to see if support for these panels can be added.

[kricon]

I've just tested new develop branch on PC560 panel (keybus output should be same as for PC500, PC510, PC550) which doesn't support PC-16 output module. As expected, keybus reader output was just a mess without anything recognized. It was constantly streaming 11110111 00111111 [Keypad] so taking any logs comparing to status in real-time would be pretty hard but I saw different data output when arming/disarming/long beep etc. I'm not sure about keypad keys, If I recall correctly # was recognized as 0: 11010111 00111111 [Keypad] 0 and others wasn't recognized.

So my question, is PC-16OUT PGM output really necessary or panels can work without them programmed, for example on PC1550 - how limited it would be without PC-16OUT PGM connected? What about supporting PC500/PC510/PC550/PC560 panels, would it be easy to implement or just not worth it? I can took logs at different states but it is impossible when I get constant data stream as it is now. I know it's possible to connect KEY/STROBE/BELL/PGM terminal onto different ESP8266 inputs and write new code to monitor/control panel that way but if this project can easily support it from just keybus connections I'm willing to help.

At weekend-house I have PC2550 panel, surely I'll take the logs but is there something specifically you're interested into or just doing basic arm-disarm stuff and verifying it's recognized correctly?

Oh BTW, in every .ino sketch example the section for enabling PC16-out module on PC1500/PC1550 is misspelled. It should be section 13, not 19. Section 14 for PC2500, 16 for PC2550 and 19 is for PC3000. And there's typo in readme.md, TinyGMS-SMS should be TinyGSM-SMS.

[taligentx]

Hi @kricon,

So my question, is PC-16OUT PGM output really necessary or panels can work without them programmed, for example on PC1550 - how limited it would be without PC-16OUT PGM connected?

Thanks for testing! The Classic series is extremely limited as far as the info available, there's info on the protocol at: https://github.com/dougkpowers/pc1550-interface

Without PC16-OUT, the data is just zone lights and keypad lights. At least on PC1500/PC1550, the PGM can be configured to trigger when the alarm is tripped, but this isn't an option for PC560. It looks like the PC560 PGM can only be set to trigger when the system is armed/disarmed, so it'd take some context clues to figure out if the alarm is tripped.

Even with PC16-OUT mode, I needed to setup a Rube Goldberg-esque series of checks on the data to see if various keypad lights were on, blinking, and then combining that with the PC16 data to work out the panel status (which is why I'm expecting bugs, there's probably some panel modes that I didn't test).

Something similar may be possible for the PC560 but since KeybusReader isn't decoding the data correctly, the first place to start is with a logic analyzer (or an Arduino/esp configured as a logic analyzer) to figure out the data format, then once the data is accurate, building up all of the possible keypad light states and trying to correlate it to the system status. If someone works this out (without needing a new set of input pins), PRs welcome :)

At weekend-house I have PC2550 panel, surely I'll take the logs but is there something specifically you're interested into or just doing basic arm-disarm stuff and verifying it's recognized correctly?

Sounds great, all of the above would be useful. I haven't seen any info on the PC2500/PC2550/PC3000 protocol, it may be different than the PC1500/PC1550 with their support for partition-like sides A & B.

Oh BTW, in every .ino sketch example the section for enabling PC16-out module on PC1500/PC1550 is misspelled. It should be section 13, not 19. Section 14 for PC2500, 16 for PC2550 and 19 is for PC3000. And there's typo in readme.md, TinyGMS-SMS should be TinyGSM-SMS.

Thanks! Fixed.

[kricon]

I was finally able to do some experiments with PC2550 V1.3R. The protocol seems to be the same, even the PC1500RK keypad works fine with it so it seems that keypads are interchangable (except of lacking zone 7-8 and fire/program lights). I've opened both and internally PC1550RK and PC2550RK seems to have same quantity and same chips. I don't know for PC3000 though, im suspecting it to have more chips (as it have smaller FEP/FAP keys, so probably chips are populated PCB below it) and different protocol (one byte more)?

The things I noticed so far:

• Panel byte1 bit1 is fire light.
• Program light is bit 2.
• PC16 status bit 4 is Armed side B.
• When only one side is armed the armed light blink which lead to false-positive that system is armed with no entry delay.

Side A and Side B split arming works like it's described in manual, each side have it's own code for arm/disarm. And when only one side is armed, armed light blinks together with flashing zones that are associated to that side and are armed.

Also, the KeybusReader output is printed multiple times, often 2 or 4 times, even the pressed keys. I don't know if that's related just to PC2550, I'll test it with PC1550 v2 and v4 when opportunity comes up.

[taligentx]

I was finally able to do some experiments with PC2550 V1.3R. The protocol seems to be the same, even the PC1500RK keypad works fine with it so it seems that keypads are interchangable (except of lacking zone 7-8 and fire/program lights). I've opened both and internally PC1550RK and PC2550RK seems to have same quantity and same chips. I don't know for PC3000 though, im suspecting it to have more chips (as it have smaller FEP/FAP keys, so probably chips are populated PCB below it) and different protocol (one byte more)?

Hi @kricon - thanks for testing this! Good to hear that the PC2550 essentially uses the same protocol.

The things I noticed so far:

• Panel byte1 bit1 is fire light.
• Program light is bit 2.
• PC16 status bit 4 is Armed side B.

Great, updated the decoding for these bits.

• When only one side is armed the armed light blink which lead to false-positive that system is armed with no entry delay.

Side A and Side B split arming works like it's described in manual, each side have it's own code for arm/disarm. And when only one side is armed, armed light blinks together with flashing zones that are associated to that side and are armed.

Added to the TODO list, I'll have to see if there's a good way to distinguish between the PC1500 and PC2550 to be able to handle this. What happens when both sides A & B are armed?

Also, the KeybusReader output is printed multiple times, often 2 or 4 times, even the pressed keys. I don't know if that's related just to PC2550, I'll test it with PC1550 v2 and v4 when opportunity comes up.

Do you have logs for this? It should be possible to limit the panel data but the keypad data will show repeats, it's how the keys work for the classic series. The keypad sends the key data continuously as long as the key is pressed, the panel figures out if a new key is being sent if there's a time interval between key data.

[kricon]

What happens when both sides A & B are armed?

The system behaves normally, just like PC1500/PC1550 (trouble/bypass etc lights shut off and just Armed light stays on). Even if alarm triggers on one side you doesn't have any indication on that until you disarm any side. However, only when both sides are disarmed the system will automatically get you into 3 alarm memory menu. If you only disarm one side where alarm occured, and re-arm it again, memory status will delete (but as in PC1500, you can view alarm history for the last 3 armed periods). After disarming any side (when only one side is still armed), trouble status is back on (also the memory light if alarm happen - no matter on which side), zone lights of other (Armed) side will flash together with Armed led, Ready (and zone lights) will follow zone state on unarmed side, trouble/memory lights will be active and also 1, 2, 3, 4, 5, 6, 7, 9, 0 functions are available. *0 arm both sides no matter that master code is assigned only to arm only one side. When system is fully disarmed, and you bypass one or more zones, bypass light will turn on. When partially (only one side, no matter which) armed, bypass light shut off and never appear again (even if you then bypass zones on another side and fully arm the system). When system is fully armed, both side A and side B bypassed zones will stay bypassed. PC16out will correctly show zones bypassed status for 5 seconds after side with bypassed zones is armed.

Also keep in mind that PC16out correctly reports zone alarms only on zones 1 through 4. On PC2550, Zone 5 alarm is indicated for alarm on any of the zones from 5 to 8 and on PC3000 zone 6 alarm indicates that alarm occured on any of the zones 9-16.

Do you have logs for this? It should be possible to limit the panel data but the keypad data will show repeats, it's how the keys work for the classic series.

Sure, I have panel available and ready for testing/taking logs from. Here is sample of arming side A with bypassed zones then immediately arming side B and after was system armed, disarm side B and after disarming side A I got 20+ messages in less than second and half. In that example, I noticed that exit delay can be triggered only once, because Side A was armed 2 seconds before side B, and both sides get armed immediately together. And here is another sample of exiting *8 programming, arming side A then arming side B. Exit delay is 15 seconds, and there was no troubles/bypass active on system. Here I noticed that every other time when data is continuously send 4 times, Armed light doesnt follow zone lights status. Slight timing issue? Code 1234 is used for side A, code 5678 for side B. Zones 1-4 are assigned to side A, and Zones 5-8 to side B and it doesn't change four consecutive repeats (I tried to assign 2 zones on one Side, 6 zones to another and still got the same data repeat pattern of 4 lines in row).

When arming with bypassed zones, it says armed stay which is wrong and after any key press it immediately says Armed away. Zone open/close status doesnt change output:

22:45:21.066 -> Partition 1: Exit delay in progress
22:45:35.512 -> Partition 1 not ready
22:45:35.512 -> Partition 1: Armed away
22:45:50.523 -> Partition 1 ready
22:45:50.523 -> Partition 1: Disarmed
22:45:55.760 -> Partition 1 not ready
22:45:55.760 -> Zone opened: 7
22:45:57.773 -> Zone restored: 7
22:45:59.645 -> Zone opened: 7
22:46:00.113 -> Partition 1 ready
22:46:02.782 -> Partition 1: Exit delay in progress
22:46:17.554 -> Partition 1 not ready
22:46:17.554 -> Partition 1: Armed stay
22:46:17.554 -> Zone restored: 7

It seems that sketch is calculating only based on considerations of Side A arming state, as there aren't "armed with zone bypassed" status when both sides are armed together with common user code or *0. Messages "Partition Disarmed" or "Armed stay/away" is displayed only when Side A is armed. For that reason, "partition 1 (not)ready" message is many times wrong.

Added to the TODO list, I'll have to see if there's a good way to distinguish between the PC1500 and PC2550 to be able to handle this.

When Armed light is flashing, the zones corresponding to armed side flash together aswell - it's then obvious that only one side is armed so status should be something like "Split-armed zones: Zone 1, Zone 2..". When only armed light is flashing, you can distinguish that system is armed with no entry delay. Flashing program light should be also taken in considerations when updating partition status, because if it's blinking I'm doing programming and status sketch wrongly follows ready/armed light while programming light is flashing.

[sfossen]

PR #296 is tested against a PC3000 series, is anyone available to test on the PC2550 or PC1500?

[kricon]

I'll be able to test it with PC1550 v4 next week, and with PC2550 v1.3R and also PC1550 v2.x in a month or so. I've also got VPM1 Escort module for classic series, tested it and works fine, will see if I can get some useful messages from it.

[l33d]

Hi I have 2 pieces of PC2550 or one is PC3000 with a PC 16 OUT module if I remember correctly and a PC1550 v3.0 ( i don`t have keypad for it, only for PC2550). Maybe I'll test it in my free time. I've also been testing on PC 5020 for several years and it works great apart from the occasional virtual blynk system crashes (sometimes works without problems 3 months, or more) . I have to reorganize the system and upload version v 3.0 (actually i still use translate by me v1.2 version) + change the parametric resistors as I understood the description for version 3.0 correctly, Did they sometimes make the system hang that the keyboard in virtual blynk did not work? Now I will be mounting 2 such PC 5020 system elsewhere and I also intend to install it with virtual blynk or virtual keypad + pushbullet.

[jpmorrison]

PR #296 is tested against a PC3000 series, is anyone available to test on the PC2550 or PC1500?

I have a PC3000 to test. I'm not clear whether PC16-OUT is needed or not.

KeybusReaederIP is working (I think) - I can see output when I press the keypad and I can type in my code and it works. I don't see any zone activity but maybe that's not in this sketch.

Unlocker is not working for me - it never gets to print 'connected'. I see it doesn't use dscClassicInterface so I'll try changing that.

[jpmorrison]

Unlocker is not working for me - it never gets to print 'connected'. I see it doesn't use dscClassicInterface so I'll try changing that.

I found my issue - I cloned @sfossen's fork but the PC3000 changes are in a different branch

All I had to do was cd into the repo and run git switch DSC_PC3000 and edit to use dscClassicInterface. Found my installer code so now I can play a bit more with things.

[l33d]

I dug up the old pc2550 control panel from 92 version v1.1 and connected it to the arduino and to my amazement it flashes with the status sketch, i can arm, disarm the system, blindly programmed. I have a second year younger from 93 and pc1550 from 98r + pc16out module. I will test them in my free time. I quickly looked at other sketches and there was a problem with them, only status work`s ok. I didn't look exactly where it was, but it didn't work. Will virtual keypad or blynk work with it too?

I check virtualkeypad web (esp8266), and only works keypad and info about armed system, nothing else not working like zone or trouble status. This is normal?

Email sketch (esp8266) works preety well, like trouble status, zone status after alarm, etc.

[NebulaGazer]

I dug up the old pc2550 control panel from 92 version v1.1 and connected it to the arduino and to my amazement it flashes with the status sketch, i can arm, disarm the system, blindly programmed. I have a second year younger from 93 and pc1550 from 98r + pc16out module. I will test them in my free time. I quickly looked at other sketches and there was a problem with them, only status work`s ok. I didn't look exactly where it was, but it didn't work. Will virtual keypad or blynk work with it too?

I check virtualkeypad web (esp8266), and only works keypad and info about armed system, nothing else not working like zone or trouble status. This is normal?

Email sketch (esp8266) works preety well, like trouble status, zone status after alarm, etc.

Hi - I have the same system, PC2550 v1.1 - hoping you can shed light into any configuration changes you may have made. I am having issues getting status info (panelData from dscClassic.cpp) to my Arduino Uno. KeybusReader works correctly, and it appears pc16 does as well (I got the "Zone alarm: / Zone alarm restored: " printouts when tripping my system and running Status.ino, which seems to stem from pc16). I have options 16 and 30 properly set for PC16/PGM, but pretty stumped as to why I can't get status.

I reduced my setup down to just DSC Yellow and DSC Green wired up, but still only get Keypad readbacks.

Appreciate any help.

[agl1tch3dpir8]

Hello all!

I just moved into a house that has an existing PC3000 and I'm all for getting this thing integration operational. I've successfully connected with the DSC Keybus Reader and am getting correct readings. Really hoping this project isn't dead. I know that the PC3000 was only in production/installation for a couple of years but don't really want to replace it just yet.

kricon, as part of issue #303 you stated that a different library was needed: dscKeybusInterface_PC3000. I haven't been able to find this library and if this is the remaining piece to the puzzle then I'm all for it!

Thanks for any help you guys can give!

[jpmorrison]

Hello all!

I just moved into a house that has an existing PC3000 and I'm all for getting this thing integration operational. I've successfully connected with the DSC Keybus Reader and am getting correct readings. Really hoping this project isn't dead. I know that the PC3000 was only in production/installation for a couple of years but don't really want to replace it just yet.

kricon, as part of issue #303 you stated that a different library was needed: dscKeybusInterface_PC3000. I haven't been able to find this library and if this is the remaining piece to the puzzle then I'm all for it!

Thanks for any help you guys can give!

This works with PC3000: https://github.com/sfossen/dscKeybusInterface/tree/DSC_PC3000

[agl1tch3dpir8]

This works with PC3000: https://github.com/sfossen/dscKeybusInterface/tree/DSC_PC3000

You rock! Deleted old library files and recompiled with new libraries now everything is working properly! Thanks for the quick reply too!

[agl1tch3dpir8]

I've now had the ESP hooked up for a while and successfully reading zone data for a few days. Only issues I've noticed have been either strange wiring/jumpers in the control panel, or issues with sensors not updating that appear to be caused by static electricity (very low humidity this time of year). Finally got some kid free time to become familiar and test the alarm system. I have confirmed my master code operates the system at the keypad. Arming the system at the keypad constantly returns "Pending." Attempts to arm or disarm from the ESP have been unsuccessful. I've verified my circuit board was connected & wired properly. Anything I might be missing?

[jpmorrison]

I used Unlocker.ino to recover the master and installer codes so I know the keybus works. You can't arm the system if a zone is open so you'll have to resolve that first. The installer code and manual has a lot in it. You could disable a faulty zone through they keybus interface or disconnect and bypass it with a resistor.

My ESP is powered from the alarm panel 12V. It's convenient, battery backed and less chance of noise. The installer's manual has lots of troubleshooting - should make sure it's working OK without the ESP connected. If the alarm panel hasn't been used/monitored for a while it then check the battery and input power supply etc.

[agl1tch3dpir8]

Ah geez. Rookie mistake. When I wired up my transistor, and subsequently when I verified my diagram, I never noticed that my pinout for my 2N4401 transistor was "bottom view." Quickly desoldered and reoriented the transistor, and now I'm successfully arming and disarming the system with the ESP.

Still having trouble with it constantly saying "Pending" on the ESP. The DSC arms, bypasses, and alarms all normally.

Just to double check, I'm using the:

https://github.com/sfossen/dscKeybusInterface/blob/DSC_PC3000/examples/esp32/HomeAssistant-MQTT/HomeAssistant-MQTT.ino

along with the appropriate library. Thank you so much for your help so far jpmorrison!

[taligentx]

Hi all, after some time (insert montage of seasons changing, stars exploding and being reborn, etc) the develop branch is updated to handle PC3000, feedback would be great. The Home Assistant sketch and example configuration.yaml has also been updated as Home Assistant can now show different armed states and allows for switching between armed states while armed.

For now, the Classic series code doesn't handle split-armed systems - it will handle side A as partition 1 and ignore side B. I'm looking into treating side B as partition 2, this will depend on enough info being available from the panel, thanks to @kricon for the detailed notes and logs on this.

As the implementation is different, I've merged #296 to a separate pc3000 branch so it's also available, it would also be good to get feedback on how this works vs the develop branch.