To use the Frient keypad (ZHA) efficiently with Alarmo I have created this custom quirk for the keypad and an automation blueprint that syncs the Keypad with Alarmo.
Since the standard implementation puts some logic (including responding to an arm command) to handle the kepad in its associated alarm panel it will never work well with Alarmo.
The custom quirk avoids this by suppressing the alarm panel (to rely on Alarmos panel) and forwards the arm command directly to Alarmo via the blueprint. The quirk also forwards the ‘Get panel status’ event which is fired from the keypad when it detects presence or a keypress.
The automation responds directly to ‘Get panel status’ by sending a command to update the LEDs based on Alarmo’s state.
It also responds to the keypads arm command by checking the response from Alarmo.
It will also track Alarmo’s state transitions and update the keypad’s LEDs and buzzer accordingly.
Through this approach, the keypad will always show correct states from Alarmo, including handling the entry and exit delays, fully driven from Alarmo.No handling of codes in the blueprint (except forwarding to alarmo) and no master code used from ZHA. All control stays in Alarmo.
This is the way you actually want a keypad and alarm system to work, no need for other logic to interfere.
The blueprint supports multiple alarmo and keypad instances, but I haven’t tested that functionality since I only have one keypad.
It has been tested to work with RFID badges.
The blueprint also supports 2 special ‘Action codes’. The blueprint will intercept these with an option to also forward the code to Alarmo.
When such a code is detected, the blueprint will call some other action instead of Alarmo. This can be used to e.g. open a garage door. If forwarding to Alarmo is enabled, arm/disarm can be done with the same code.
It also supports the SOS key. When pressed (3 times or long-press) the blueprint can run a defined 'emergency ’ action directly, no code required.
The blueprint has been updated to support mapping (static or dynamic) of any of Alarmo’s arm states to each keypad button.
Hello Hman,
Thanks for contributing to the community with a new Blueprint.
I have a suggestion for you. Many people who are not familiar with directory structures will have problems installing this without the Home Assistant MY tools.
Adding a MY link for this Blueprint to your top post would help them a lot.
Here is the link to make that. Create a link – My Home Assistant
Thanks for the suggestion.
I think some directory knowledge will be required because this not just a blueprint, it works together with a custom quirk that needs to be installed in the right place.
But to support, I have added detailed installation instructions in the readme
That works.
If you run into people having problems, using the my-tool in the blueprint install part of that would work as well. You can feel that out based on issues your customers might have.
Thank you for making this! I’m actually (maybe controversially) thinking of moving from Zigbee2MQTT to ZHA to simplify my setup, and it was actually this keypad that was putting me off as I had a lot of automations and scripts set up for synchronising the state of the alarm!
One thing I was wondering, is there any way I can configure which ‘alarm mode’ that the full arm away (padlock) button on the keypad arms to? I currently have it set to arm the custom/bypass mode rather than arm away as I more often than not leave the dog at home and use the custom bypass mode for that (and arm the full ‘arm away’ mode via my phone when we take her with us).
Thanks again!
EDIT: I just added a pull request to the GitHub to add an option to choose between the away and custom alarm modes when the padlock button is pressed!
Glad it helps, I wrote it since I saw no other way of making the keypad really usable.
The arm mode Alarmo will use can now be configured in two ways for each keypad button:
A default setting for each arm button in the blueprint. Changing this setting will arm alarmo to that mode instead. This is meant as a fixed setting.
An option to use an input select helper for each button. If this helper is defined in the blueprint its setting will override the blueprint setting. This is meant as an easy real-time way of selecting modes directly on the dashboard.
Example yaml for the helpers (or define them in the UI):
input_select:
keypad_arm_day_mode:
name: Keypad – Home/Day arm mode
icon: mdi:shield-home
options:
- home
- away
- night
- vacation
- custom
initial: home
keypad_arm_night_mode:
name: Keypad – Night arm mode
icon: mdi:shield-moon
options:
- night
- away
- home
- vacation
- custom
initial: night
keypad_arm_away_mode:
name: Keypad – Away arm mode
icon: mdi:shield-lock
options:
- away
- custom
- vacation
- home
- night
initial: away
@Hman did you make a pull request for a new custom ZHA device handler or submit a device support request to the zha-device-handlers repository to mke ZHA developers aware of it?
Currently in ZHA, this quirk needs the companion blueprint to do any good. The ZHA IAS implementation is bypassed so that Alarmo can act as the CIE. Installing this quirk will break functionality otherwise, so it shouldn’t be merged in zha-device-handlers without other measures.
Since I believe this is really an architectural thing in the ZHA IAS implementation, I have opened this feature request:
