Add alarmdecoder brand specific arming sequences

[ajschmidt8]

Breaking change

Previously the autobypass configuration option only worked for home and away arming. It now works for night arming also. Review the alarmdecoder integration docs to make sure the autobypass option is configured to your preference.

Proposed change

This PR replaces AlarmDecoder's AlarmDecoder class with the extended AdExt class from adext. This enables more arming options for the AlarmDecoder integration. It also enables the code_arm_required option to work with DSC alarm panels. Previously, it only worked for Honeywell panels.

The new arming sequences are spelled out in the new docs (home-assistant/home-assistant.io#13725).

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml
alarmdecoder:
  device:
    type: socket
    host: <ip>
    port: 10000
  code_arm_required: false
  autobypass: true

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: Add missing features for AlarmDecoder #35728
• Link to documentation pull request: Add AlarmDecoder Arming Key Sequences documentation home-assistant.io#13725

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[ajschmidt8]

@MartinHjelmare, I've removed the new config parameter for the time being. I've also converted the PR to a draft because I want to test this change locally to make sure everything is still working as expected. Are there any other changes that would need to be made before this could be merged?

[MartinHjelmare]

Looks good now!

[ajschmidt8]

@MartinHjelmare, tested and ready for official review.

[ajschmidt8]

sorry, testing one more quick thing. i was hoping to finish before you saw my comment.

ready!

[MartinHjelmare]

Thanks!

[MartinHjelmare]

Please extend the breaking change paragraph with what the user needs to do to cope with the breaking change.

[ajschmidt8]

Please extend the breaking change paragraph with what the user needs to do to cope with the breaking change.

@MartinHjelmare, I'm not sure there's anything to do to cope with this change. It's mostly just a functionality change to be aware of. I reviewed the original autobypass PR #30002 and didn't see a reason why autobypass wasn't included in night mode originally. I added it to night mode in my new logic just so it's consistent across all arming modes. Let me know what you'd like me to do here.

I also have a question about the requirements field in manifest.json. I replaced alarmdecoder with adext, however there are still items imported from alarmdecoder in this integration (like here). alarmdecoder is listed as a dependency in my adext package, so I don't foresee this being an issue, but I wanted to double check.

[MartinHjelmare]

How will users be affected by the breaking change?

[ajschmidt8]

@MartinHjelmare updated!

[MartinHjelmare]

I would advice users to review the autobypass config option to make sure it's set according to their preference.

[ajschmidt8]

I would advice users to review the autobypass config option to make sure it's set according to their preference.

@MartinHjelmare done!

can you check this 3-line PR also? #36695

[ajschmidt8]

@MartinHjelmare, according to your comment from this thread, I don't believe it's possible to fully convert AlarmDecoder to Config Flow yet. I can't figure out a way to get the zones config option shown below to be configurable through Config Flow. Is there a way to do this currently? If not, can I get an exception to add the feature we discussed above into the existing yaml configuration for AlarmDecoder?

# Example configuration.yaml entry
alarmdecoder:
  device:
    type: socket
    host: 192.168.1.20
    port: 10000
  panel_display: false
  zones:
    01:
      name: 'Smoke Detector'
      type: 'smoke'
      rfid: '0123456'
    02:
      name: 'Front Door'
      type: 'opening'