This blueprint is no longer supported, please switch to my new blueprint:
Hello,
Thanks for Sharing this kind of onfo.
Best Regards
First update today. Noticed the scripts werenât running when the mode changes. The logic has changed and the Scripts now run at the same time. So if you select one or multiple scripts, they all start at the same time. So keep that in mind when selecting scripts.
Also moved the Actions I used to this blueprint as well. So they should now work for all users.
I have tried several blueprints and automations for keeping the frient keypad in sync with the home assistant alarm, both with zha and zigbee2mqtt, and this is the only one Iâve come across so far that seems to work flawless.
One thing that would be nice to have, is to be able to specify which devices to send the notifications to.
Thank you for the great work!
Thanks for the feedback.
Many of the other Blueprints rely on Alarmo to do the logic of the multiple codes, which I didnât want to use. I am running my HA without any Custom Components so I can more easily do updates of HA without worrying about breaking changes.
Of course Iâm still checking the breaking changes for the integrations I do use and if there are changes to the internal structure of the Automations/Scripts I will update the Blueprint accordingly, as I am using it myself.
Iâve been running like this with my own Automations for some time which I have now translated into this blueprint.
I have thought about implementing a target selection for the notifications, but for me personally it is fine to send the Notification to all Mobile Apps I have in my Home Assistant install. Will check how to implement this.
Something I am working on first is adding the possibility to have an âAlwaysâ mode trigger, independent of Alarm state. For things like Smoke and Moisture alarms.
I have updated the blueprint.
It is now possible to select which device you want to send the notifications to.
Please keep in mind that due to this change, there is no default set anymore. As I was using notify.notify before which apparently can cause unexpected behavior.
Also implemented Always, Fire, Gas and Moisture modes for the Notification and Script system.
for me currently it does not work properly,
It tells me that the code used when disarming is incorrectâŚ
Executed: January 29, 2025 at 00:30:11
Error: Invalid alarm code provided
Result:
params:
domain: alarm_control_panel
service: alarm_disarm
service_data:
code:
- '1234'
entity_id:
- alarm_control_panel.home_alarm
target:
entity_id:
- alarm_control_panel.home_alarm
running_script: false
Are you using a Physical Keypad?
The virtual Keypad linked to the main alarm control panel has no code, only when interacting with the secondary (physical keypad), you can use multiple codes that are set with the Text Helpers.
There is no way to link multiple codes to the Manual Alarm Control panel directly, this is a limitation of HA itself. The blueprint handles the inputs from the Physical keypad to match the codes.
The Physical Keypad does need to have a code, which you set in the ZHA integration settings and use a text helper to store that code for the Blueprint. The ZHA integration itself also only supports one code, which I set to an 8 digit code myself, so it is not used by normal users, just for the sync between alarms.
If needed I can change the blueprint so the main alarm control panel can have a single master code like with the physical keypad. I am not using it like that as I donât want to put in codes to change the alarm modes when I have access to my HA app and control the alarm through HA directly.
After a bit of tweaks, I got it working.
I had to disable the password on the virtual keypad, the manual configuration.yaml one.
After I had done that, it works like a charm.
but yes,
I am also using the kepzb-110
Its a shame that there isnât such a setting as;
when arming > no code is needed > when changing armed mode> code is needed.
But that is something a firmware update (which I dont expect from the devs) could update.
I must say, other than that, the blueprint works like a charm
Good to hear it works for you now. I am not using a code on my Manual Alarm Control Panel. As I like to be able to change the modes easily when I have access to my HA Dashboard.
Anyone with access to my HA Dashboard has protected access.
It is sadly a limitation of how the Manual Alarm Control Panel works, itâs either one code or no code for all states. Same with the implementation of the ZHA Alarm Control Panel, which is even more limited.
The ZHA Alarm Control Panel doesnât even support the arming/pending states. So if you would use the ZHA Alarm Control Panel directly it would directly go to armed when armed and directly sound the alarm when you would trigger a sensor when entering your home.
The KEPZB-110 supports all the states and more features, but sadly those are not implemented into ZHA currently. So my blueprint is using the âtriggeredâ state of the Keypad when it is in arming/pending and triggered state.
Which is why I made this Blueprint 
, to fix those states and other things that are not present in the native implementation itself.
In an ideal implementation, you would have multiple code support in ZHA directly and all the states the Control Panel supports natively. All the GitHub issues about this have been closed due to inactivity in the past years.
Hi @danieldeni !
First of all - thanks for the most wanted blueprintâŚ
Can you give me an example on how to use this blueprint with a RFID tag?
Right now Iâve set a text helper with the code â+AA11C0CBâ (taken from the zha_event when scanned and the pressed disarm.)
Iâm using the frient panel.
Thanks!
Hi Daniel,
I found a minor inconvenience when a sensor is triggered,
the code was set to push alarm_notifications_armed_away rather than alarm_notifications_triggered, this prevented to actually get the âsensor X has been triggered!â
I send it in a fix to your github page.
Hi @Mikkelmoeller,
I am not using it with a RFID tag on a daily basis, as I need to find a nice one for on my keychain.
Did you put the " also inside the text helper? It should be just the value of the RFID tag itself.
The RFID tags I have tested with have a longer code on them when I tested it with the frient panel.
Hi @vankyvo
Thanks for the notification and suggestion. You are correct the wrong variable was put there.
I updated the Blueprint with this change.
1 Like
Iâm using it without the "
Ok, I just tested it to be sure.
When you want to use the NFC reader, you simply hold the NFC tag to the center of the frient keypad and it will give a short beep. Than you select the mode you want to set and it will change to that mode if the code is present in your codes.
In ZHA the keypad will gather all number presses until you press any of the arm/disarm modes. Not sure if there is a hard limit to the amount of numbers, but Iâve tested up to 16 digits without problems.
You can either use the numbers or the NFC tag for a single command.
For example I have a NFC tag and set the value with:
action: input_text.set_value
target:
entity_id: input_text.alarm_code_custom_1
data:
value: +047FC392F26C80
If I select this Text Helper as one of the allowed codes, it works with the NFC tag.
Maybe another idea,
When the alarm is triggered, the current notification does not go through if your phone is on silent or Do not Disturb,
Currently I set up a script to push an additional notification but perhaps its nice to be able to create a toggle that will allow you to force the notification sound.
action: notify.mobile_app_sm_s928b
data:
message: The alarm has been triggered.
title: Home Alarm
data:
actions:
- action: URI
title: Open Camerafeed
uri: lovelace/cameras
channel: alarm_stream
ttl: 0
priority: high
action: null
clickAction: /lovelace/cameras
It does on all our Apple devices. iOS, iPadOS and MacOS all work.
I donât have any Android devices, but I included the priority that should do the same on Android. You do need to allow the Companion app to be able to send those kinds of notifications.
push:
sound:
name: default
critical: 1
volume: 1
ttl: 0
priority: high
The name, critical and volume are used by Apple devices.
The ttl and priority are used by Android devices.
Oh, I just realized my mistake. The Android Critical notification is not put under the same push/sound command but under data/data. So I need to split the logic anyway to be able to work with Android as well.
Only the âAlarm Sensor Alwaysâ mode doesnât have the High Priority currently and the normal state changes are also only normal.
Iâll need to implement it in a way that you can select if you want normal, High Priority Apple and High Priority Android options. So you can select it yourself which you want per notification.
The options for Notifications on Android and Apple devices are completely different.
Will take some time as I need to change some logic and I have little time during the day till Sunday.
1 Like
Well, I found some time tonight and was able to implement the selectable notification options per mode. You can reimport the Blueprint for the latest version.
As I donât have any Android device I cannot test the Android part myself, so please let me know if it works correctly for Android.
1 Like
I just tested, it works like a charm!
1 Like