Skip to content

Actually enable alarmdecoder to see open/close state of bypassed RF zones when armed#31426

Merged
MartinHjelmare merged 1 commit intohome-assistant:devfrom
melyux:dev
Feb 8, 2020
Merged

Actually enable alarmdecoder to see open/close state of bypassed RF zones when armed#31426
MartinHjelmare merged 1 commit intohome-assistant:devfrom
melyux:dev

Conversation

@melyux
Copy link
Copy Markdown
Contributor

@melyux melyux commented Feb 3, 2020

…"loop" specified can now "correctly show a bypassed RF zone as open or closed when the alarm is armed" as per specifications.

Proposed change

According to the AlarmDecoder integration documentation here, specifying the rfid and loop variables "allows Home Assistant to read open/closed status from the raw sensor data in addition to from the panel display" and that "it can correctly show a bypassed RF zone as open or closed when the alarm is armed". This was integrated with PR #18477.

However, once the alarm panel tells the integration that the zone is closed, that's that. It doesn't override this using the raw sensor data as it's supposed to. When a zone is bypassed and the alarm is armed, the alarm panel will falsely assert that all zones (even RF) are closed. Perhaps hours or days after the system is armed, when the RF sensor may send its periodic supervisory data, at which point (I assume) HA will recognize this zone as open and overwrite the fake panel off status for it. But that's pretty useless.

My solution that fulfills the specifications of the documentation is: if the loop variable is set, then HA should not listen to fault restorations from the panel for that zone. It should hold the RFID messages paramount. That's the whole point of setting loop, as the documentation says. Otherwise, just setting rfid without loop would provide the loop data without instructing HA to use it as the main state. If there is no loop data readily available like when HA restarts, my fix ensures that the system will default to the alarm panel's status for the zone. I only changed the fault restore logic since this is only relevant to zones falsely becoming restored upon bypassed arming, not the other way around.

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: alarm.yuksel
    port: 10000
  panel_display: false
  autobypass: true
  zones:
    01:
      name: 'Front Door'
      type: 'door'
    02:
      name: 'Back Door'
      type: 'door'
    09:
      name: 'Some Door'
      type: 'garage_door'
      rfid: '0283147'
      loop: 3

Additional information

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.

The integration reached or maintains the following Integration Quality Scale:

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

…"loop" specified can now "correctly show a bypassed RF zone as open or closed when the alarm is armed" as per specifications.
@homeassistant
Copy link
Copy Markdown
Contributor

Hi @melyux,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

Copy link
Copy Markdown
Member

@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds and looks good!

@MartinHjelmare MartinHjelmare merged commit ed3e161 into home-assistant:dev Feb 8, 2020
@lock lock bot locked and limited conversation to collaborators Feb 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants