Disarming 2 partitions with one button

Configuration Frontend
,
1

Hi all,
I currently have 2 partitions configured as per diagram, giving me 2 sets of buttons to arm/disarm/etc the partitions,

I want to add a single third stand alone button to disarm both partitions with one button.

… thinking, I seem to remember I can create a third platform options name: “Alarm-Both” where I specify “all” instead of where I have Area_1 and Area_2. Is that valid ?

alarm_control_panel:
  - platform: mqtt
    name: "Alarm-Part1"
    command_topic: "paradox/my/control/partitions/Area_1"
    state_topic: "paradox/states/partitions/Area_1/current_state"
    payload_arm_away: "arm"
    payload_arm_home: "arm_stay"
    payload_arm_night: "arm_sleep"
    payload_disarm: "disarm"
    code_arm_required: false
  - platform: mqtt
    name: "Alarm-Part2"
    command_topic: "paradox/my/control/partitions/Area_2"
    state_topic: "paradox/states/partitions/Area_2/current_state"
    payload_arm_away: "arm"
    payload_arm_home: "arm_stay"
    payload_arm_night: "arm_sleep"
    payload_disarm: "disarm"
    code_arm_required: false

Screen Shot 2021-01-25 at 08.07.59
Screen Shot 2021-01-25 at 08.07.59694×702 30.8 KB

2

Create a script that disarms the two partitions. Make the button call the script.

3

How Do I add the button onto that card that can show a button to arm both night and disarm both similar to the current button design.

And how would it retrieve the current state ?

G

4

The screenshot you posted above is not “a button”. It’s two Alarm Control Panel cards.

What I suggested was to create a button, as in a Button card. However, it appears what you actually want is a third Alarm Control Panel card that controls the other two.

You can do that with a Template Alarm Control Panel. Configure it to arm/disarm the other two partitions. It will appear as a third Alarm Control Panel card in the UI.

The example in the documentation should be sufficient to get you started but let me know if you need help configuring it.

5

Don’t have any experience with templates, if you won’t mind sending me whats required would appreciate it.

G

6

Post what you have so far and I’ll help you with it. If you have nothing, start by copying the documentation’s example and begin adapting it.

It’s likely that it will only involve service calls to arm/disarm the two partitions and no actual templates will be required. However, we won’t know that for sure until you start the ball rolling.

1 Like
7

Those two cards as you will see above call mqtt topics, would the arm home, arm away, arm sleep have different service calls, I intercept the mqtt call and does some work with it before it is then send to the PAI mqtt monitored topic.

For this I might be able to intercept a card push also, onto a custom topic, which I then duplicate the marty message onto my 2 partitions, problem now comes in with the current state topic, I need read the current state from the panels 2 state topics and create OR condition that if either of my partitions are arm then show the card as armed.

G

8

Either you’re overthinking the challenge or I’m underthinking it. :slight_smile:

The following will probably require some adjustment but it’s a starting point:

alarm_control_panel:
  - platform: template
    panels:
      master_alarm_panel:
        value_template: >
          {% set p1 = states('alarm_control_panel.alarm_part_1') %}
          {% set p2 = states('alarm_control_panel.alarm_part_2') %}
          {{ p1 if p1 == p2 else 'pending' }}
        arm_away:
          - service: alarm_control_panel.alarm_arm_away
            data:
              code: !secret alarm_code
              entity_id:
                - alarm_control_panel.alarm_part_1
                - alarm_control_panel.alarm_part_2
        arm_home:
          - service: alarm_control_panel.alarm_arm_home
            data:
              code: !secret alarm_code
              entity_id:
                - alarm_control_panel.alarm_part_1
                - alarm_control_panel.alarm_part_2
        arm_night:
          - service: alarm_control_panel.alarm_arm_night
            data:
              code: !secret alarm_code
              entity_id:
                - alarm_control_panel.alarm_part_1
                - alarm_control_panel.alarm_part_2
        disarm:
          - service: alarm_control_panel.alarm_disarm
            data:
              code: !secret alarm_code
              entity_id:
                - alarm_control_panel.alarm_part_1
                - alarm_control_panel.alarm_part_2

It assumes alarm_code is stored in your secrets.yaml file and the same code is used by both partitions. If that’s incorrect, let me know and we can easily adapt it to use separate codes.

In a nutshell, if you arm this third “Master Alarm Panel”, it proceeds to arm the first partition followed by the second partition.

The automation I posted doesn’t work like that (but it can). I assumed the Master Alarm Panel is to ensure the two partitions work in unison (i.e. will always have the same state).

During the process of arming both partitions, there may be a moment when the status of the first partition differs from the second one. The Master Alarm Panel reports this ‘transition state’ as pending. In other words, when one partition’s state differs from the other, the assumption is it’s a temporary situation and they will soon be equivalent.

However, if my assumption is incorrect and it may be normal for one partition to be armed and the other to be disarmed (for long periods of time) then it’s up for debate as to what best describes this state. You said you would call it armed which, to my mind, is a bit misleading because the other partition is actually disarmed.

The only states recognized by Home Assistant’s alarm_control_panel are the following:

armed_away, armed_home, armed_night, arming, disarmed, pending, triggered and unavailable

In my opinion, the only one that adequately conveys the notion that the entire system (i.e. both partitions) are not fully armed/disarmed is pending. However, it’s your call and value_template can be easily adapted to whatever you see fit.

9

Hi there

Thanks, will give this a go. asap and see how it behaves.

G

10

Did you get an opportunity to test it?

11

not yet.

will see if i can today

G

12

… I changed code to:

you will see i removed the arm/disarm code, but when i go into the create card, it still shows the keypad ?

  - platform: template
    panels:
      master_alarm_panel:
        value_template: >
          {% set p1 = states('alarm_control_panel.alarm_part1') %}
          {% set p2 = states('alarm_control_panel.alarm_part2') %}
          {{ p1 if p1 == p2 else 'pending' }}
        arm_away:
          - service: alarm_control_panel.alarm_arm_away
            data:
              entity_id:
                - alarm_control_panel.alarm_part1
                - alarm_control_panel.alarm_part2
        arm_home:
          - service: alarm_control_panel.alarm_arm_home
            data:
              entity_id:
                - alarm_control_panel.alarm_part1
                - alarm_control_panel.alarm_part2
        arm_night:
          - service: alarm_control_panel.alarm_arm_night
            data:
              entity_id:
                - alarm_control_panel.alarm_part1
                - alarm_control_panel.alarm_part2
        disarm:
          - service: alarm_control_panel.alarm_disarm
            data:
              entity_id:
                - alarm_control_panel.alarm_part1
                - alarm_control_panel.alarm_part2
13

According to the documentation, the default value of the code_arm_required option is false. That means we shouldn’t need to include it in the Template Alarm Control Panel for Home Assistant to understand a code isn’t required for arming/disarming. However, as an experiment, add it to see if it makes any difference (I doubt it will but it’s a worth a try):

      master_alarm_panel:
        code_arm_required: false
        value_template: >
          ... etc ...

As for the Alarm Panel Card, I don’t see anything in its documentation that suggests you can manually determine if and when the keypad is displayed.

14

that did not make any difference.
with the 2 separate partitions it originally did show the keypad, but by removing the code section it disapeared. does not seem to be working the same now.

G

15

I didn’t think it would but it needed to be tested. What’s happening now is that the appearance of the keypad is governed by the Alarm Panel card. It appears to behave differently depending on the Alarm Control Panel’s platform (in this case, mqtt vs template). That’s odd and I know of no way to circumvent it.

Does it allow you to arm/disarm master_panel without supplying a code? Or does it remain grayed-out until you enter a code?

16

interesting, it works, no code needed…

now just to figure out how to get rid of the code panel.

G

17

I did some digging and discovered that the keypad is always displayed when using Template Alarm Control Panel even when no code is required. Someone reported it as Issue in the Core repository, back in April 2020, but it was never addressed (and is now marked as a stale Issue):

Another community member shared a way of suppressing the display of the keypad. The technique it uses relies on a custom card called card-mod.

Card-mod is used to enhance the appearance of other cards. In this case, it would be used to suppress the display of master_panel’s keypad.

You would need to install card-mod (refer to the link above) and then modify the configuration of your Alarm Panel card to instruct card-mod to hide the keypad. In the following example, all of the options shown are standard options for an Alarm Panel card except for the final style option. That one is understood by card-mod.

type: alarm-panel
entity: alarm_control_panel.master_panel
name: Master Panel
states:
  - arm_home
  - arm_away
  - arm_night
style: |
  #keypad, #alarmCode {
    display: none !important;
  }

Aside from the keypad issue, does the technique I proposed, to use a Template Alarm Control Panel, address your original requirement to control both partitions?

18

Taras, from a behaviour it seems to be doing what I want it to do… thanks, jsut the visual side of having that keypad there thats not liked. will see what I decide, I can do this by creating a 2nd panel in the configuration.yaml and then using some node to do what I want, as originally planned, just allot of moving parts. or the visually not like, but it works, easier.

as it is at the moment, it works, just have to separately manually arm the 2 partitions, and/or disarm them separate so this is trying to improve the user experience.

G

19

I think it would be less work to use card-mod to hide the keypad than attempting the lots of “moving parts” strategy.

If you feel your original requirements have been addressed, please consider marking my fourth post with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has an accepted solution. It will also place a link beneath your first post that leads to the Solution post. All of this helps other users find answers to similar questions.

On the other hand, if you believe your requirements have not been adequately addressed, hold off on tagging anything until a more acceptable idea is offered.

For example, one alternative would be to use Button cards and scripts:

  • Create four scripts, one for each of the four alarm_panel actions (arm_away, arm_home, arm_night, disarm). The service calls you need can be copied from the example posted above. Alternately, create a single script that accepts a passed variable (where the variable represents which action to perform).
  • Create four Button cards, one for each of the four alarm_panel actions. Configure each Button to call the appropriate script (or pass the desired action as a variable to a single script).
  • If you want to display the combined status of the two partitions, you will need to also create a Template Sensor. Simply use the template shown in value_template from the example posted above.

Let me know if you prefer this approach and I can help you implement it.

20

… battling to get the card-mod.js working. I posted in the card-mod.js thread…

installation was cd into config directory, create a www directory, cd into that and did a git clone.

then modified my alarm

type: alarm-panel
entity: alarm_control_panel.master_alarm_panel
name: Master Panel
states:
  - arm_home
  - arm_away
  - arm_night
style: |
  #keypad, #alarmCode {
    display: none !important;
  }