Add check for panel version for user access codes

[kricon]

I'm reffering to this part of code from dscKeybusPrintData.cpp:

void dscKeybusInterface::printPanelAccessCode(byte dscCode) {
  if (dscCode >= 35) dscCode += 5;

  switch (dscCode) {
    case 33: stream->print(F("Duress ")); break;
    case 34: stream->print(F("Duress ")); break;
    case 40: stream->print(F("Master ")); break;
    case 41: stream->print(F("Supervisor ")); break;
    case 42: stream->print(F("Supervisor ")); break;
    default: stream->print(F("User ")); break;
  }
  stream->print(F("code "));
  stream->print(dscCode);
}

Panel versions v1.0 - v1.2 use following scheme for user codes:
1-32: regular user codes
33: Partition 1 duress codes
34: Partition 2 duress codes
40: System master code
41: Partition 1 master code
42: Partition 2 master code

Panel versions v1.2 - v4.1 use following scheme for user codes:
1-32: regular user codes
33-34: duress codes
40: master code
41-42: supervisor code

Panel versions v4.2 - v4.7 use following scheme for user codes:
PC1616: User 1-48, with 40 being master code
PC1832: same as above, with addition of 49-72
PC1864: same as above, with addition of 73-95
Each user code can be set as duress or enabled/disabled for *1/*5/*6 access.

Source: dozens of PowerSeries installation manuals thru different versions.
EDIT: my pc1832 correctly accepts codes until access code 75, instead of 72 as manual says ?!? (I'll test how much codes PC1616 accepts).
I dont belive that PC1864 would be able to do 97 user codes (*5 section 98 is for partition assigment and 99 for attributes) as in array order is *5 user75 = 0x81 and *6 user1 = 0x96. So it perfectly fits 95 users as maximum in *5 range and then start with *6.

Or, if saving panel version and reading it afterwards will took memory space which can be useful for other things, maybe just leave master code and remove the othes ones? But having panel version loaded in memory will be nice addition, as for example DSC panels share same features thru panel versions (for example, every panel after version v3.0 use single group of 8 zones for PC5108 expander and have 16 zone definitions in section 001).

PS: access codes 33-39 and 43+ for newer panel versions are in different printPanelStatus, so no conflicts with 41-42 user codes.

EDIT: I did some user decoding, you can view it on my repo. Decoded *1, *2, *3, *5, *6 and *7/Access code for users 35..39 and 43..95 which panel version 4.2+ supports. It works fine but code is little messy, I need to clean it up and write some comments/notes. I tested only with user codes 1-75 which is supported on my panel (PC1832). About code optimizing, Im sure it can be done (like, to have printPanelAccessCode only one time per *action, not twice for range 35-39 and 43-95. I also decoded arming/disarming for same user codes, but didnt implement it yet. I have big problems with overlaping user codes 35-39 as printPanelAccessCode increases every user code by 5, starting with user 35. Only user code 43-95 is included in my repo, with user codes above 75 pending testing from someone with PC1864, but range matches fine.

[kricon]

I'll change void printPanelAccessCode(byte dscCode); to void printPanelAccessCode(byte dscCode, bool accessCodeIncrease = true);and using it true for printPanelStatus0-4 (0xA5, 0xAA, 0xCE) and false for printPanelStatus5+.. used for 0xEB, 0xEC commands.

When its true, it will increase user code by 5 starting with user 35, as its doing now, used for master (40), and supervisor (41-42) codes on older cmds.

When its false, it will increase user code by 3, starting with user 40. As codes are consecutive 35-95 except 40, 41 and 42 which will be skipped that way (so, only one user code range and one printPanelAccessCode for whole range 35-95).

I hope Im on right track doing the code right way, its my first coding in Arduino. It should fix issue of +5 user code addition and unable to use 35-39 range before because of it. If it can be more optimized/consolidated, or done the other (better) way, feel free to give me hints.

EDIT: all of the above just done in less than 5 minutes, works like charm! Im glad I learned a little about code structure and got some knowledge to be sure I can make pull requests without code breakup.

But still, Im not entirely sure if I would be able to do panel version check, I suppose I have to store byte panelVersion when 0x16 cmd send it, and then see if panel version is over 41, if it is then print only Master code = 40, and for others just print reguraly User code: 41. If Im correct it should be straigthforward, maybe I'll try to implement it but I really don't wanna to mess code structure or consume available memory unnecessarily.
Examples should then be updated aswell, to also check dsc.panelVersion before sending user code prefix (supervisor/duress). Atleast Status sketch, which currently lacks a lot of decoded code lately (for example, low battery statuses).

[taligentx]

Hi @kricon,

Or, if saving panel version and reading it afterwards will took memory space which can be useful for other things, maybe just leave master code and remove the othes ones? But having panel version loaded in memory will be nice addition, as for example DSC panels share same features thru panel versions

Thanks for going through the access codes! I've simplified the decoding as you mentioned to either master or access code and removed the duress/supervisor labels as they're not particularly useful.

I've also added dsc.panelVersion to access the panel version as a whole number - for example, panel version 4.2 would be 42 in dsc.panelVersion.

I hope Im on right track doing the code right way, its my first coding in Arduino. It should fix issue of +5 user code addition and unable to use 35-39 range before because of it. If it can be more optimized/consolidated, or done the other (better) way, feel free to give me hints.

Looks good and thanks for the code! I've updated the status processing code to match this so sketches will now see access codes up to 95 in dsc.accessCode[].

[taligentx]

(accidentally submitted the last reply too early)

EDIT: all of the above just done in less than 5 minutes, works like charm! Im glad I learned a little about code structure and got some knowledge to be sure I can make pull requests without code breakup.

Great to hear that looking at the code and working with PRs has been a good learning experience, I originally worked on this library mostly as an excuse to get familiar with microcontrollers and it's been a great learning experience as well!

Examples should then be updated aswell, to also check dsc.panelVersion before sending user code prefix (supervisor/duress). Atleast Status sketch, which currently lacks a lot of decoded code lately (for example, low battery statuses).

I've simplified the access codes display in the Status example sketches as well. As far as the decoding, while the goal of KeybusReader is to decode all Keybus data, the status data in the Status sketches is focused on the information that is useful to most of the integrations (Home Assistant, HomeKit, etc).

For example, I'll need to look into which software can use the low battery status. Ideally it would be a status flag that can be set on a contact sensor in the home automation framework and that is shown directly to the user, but if the software can't use the low battery information, there's no point in using resources to track this data.

[kricon]

@taligentx Thank you for the answer and supporting this project - I'm suprised how much protocol is decoded by now. There is just few common unknown messages which are still not decoded. This was great success, from initial idea just for alarm triggered notification to current project state.

Thanks for going through the access codes!
Looks good and thanks for the code! I've updated the status processing code to match this so sketches will now see access codes up to 95 in dsc.accessCode[].

No problem! I saw that status sketch wont process access codes more than 42, but as I don't have access to my main PC I didnt want to mess with the code and doing trials-and-errors on current setup with smaller resolution and screen - it isn't that comfortable for doing the coding stuff and debugging.

I've simplified the decoding as you mentioned to either master or access code and removed the duress/supervisor labels as they're not particularly useful.
I've also added dsc.panelVersion to access the panel version as a whole number - for example, panel version 4.2 would be 42 in dsc.panelVersion.

Thanks for including that! Having panel version in memory, it could be useful for other things, and its easy to revert back duress/supervisor labels only for older versions if needed.

Great to hear that looking at the code and working with PRs has been a good learning experience, I originally worked on this library mostly as an excuse to get familiar with microcontrollers and it's been a great learning experience as well!
As far as the decoding, while the goal of KeybusReader is to decode all Keybus data, the status data in the Status sketches is focused on the information that is useful to most of the integrations (Home Assistant, HomeKit, etc).

Being in lockdown because of current covid-19 situation, there isn't much other (better) things to do. And as I have few different panels/modules, I'm doing my best to help you out decoding keybus data.

For example, I'll need to look into which software can use the low battery status. Ideally it would be a status flag that can be set on a contact sensor in the home automation framework and that is shown directly to the user, but if the software can't use the low battery information, there's no point in using resources to track this data.

My goal with this project, except helping with testing and decoding stuff, is to be able of fully supervising and controling panel installed in my weekend-house remotely from the city. Sometimes I dont visit the weekend house for several months and often I saw wls low battery (especially in winter as house isn't heated) or rf deliquency occured (mostly when it's raining). Also, I have some PGM output integrations with outdoor lighting I wanna control. That's mostly why I want to use it with Blynk.