This is an interesting idea indeed.
It might be “ugly” as workaround, but I would be happy to have it working. So I did try to install and configure it but without success. I’ve raised an issue here, hopefully you can help me!
Can you give more information about short hex codes problem. When I try to paste code from enrollment (or from logs) it always delete some zeros and the code is not the same than the tag.
Hi Denis, you should add the missing zero’s to the code manually, so \x4 should be \x04. Let me know if it works.
Hi Jean-Pascal,
I’ve been offline for a bit but thank you for this! I’m certainly going to check it out!
It doesn’t work, HA delete immediatly zeros when I set code.
I’ve been experiencing the same problem as you and it feels like I’ve tested everyting, even though I probably missed a lot of options, as I’m almost new to this.
I resorted to installing domoticz on my PC and getting the codes stored in the keypad from there. After moving the z-wave stick back in my rpi and restarting it, the codes showed up proprely in the keypad when accessing it from ozw app in hassio.
It was very straight forward in domoticz, but it would of course have been better to find a way to do it from hassio directly.
Does anybody have a working configuration, with home assistant alarm panel and the zipato rfid mini keypad, using the OpenZwave app (version 0.113+), that they can share their code from?
I’m currently trying to configure the code from anasazi in this thread to get it working with my setup. I managed to get the editor to accept the arm/disarm part yesterday after some minor tweaks, but I get a notification from hassio that the automation config couldn’t be set up.
What I ended up with after looking at previously integrated automations:
- id: alarm_armed_away
alias: Alarm Away Mode Armed
trigger:
platform: state
entity_id: alarm_control_panel.ha_alarm
to: armed_away
action:
- data:
title: Hemlarm
message: Larmet har blivit aktiverat för bortaläge!
- service: notify.mobile_app_e5826
- service: shell_command.set_keypad_away
- id: alarm_disarmed
alias: Alarm Disarmed
trigger:
platform: state
entity_id: alarm_control_panel.ha_alarm
to: disarmed
action:
- data:
title: Hemlarm
message: Larmet har blivit frånkopplat!
- service: notify.mobile_app_e5826
- service: shell_command.set_keypad_home
Edit: Perhaps I should add that the entities mentioned in the original post does not show up in hassio for me, so I figured shell_command was a way to work around this, as I see a lot more info from the keypad when I access it through the openZwave-app.
Edit 2: I found a few inactivated entities when looking through related entities in the configuration. Now I’ve got something that actually changes values when I interact with the keypad and maybe the manual can help me figure out which ones to use.
But still, if somebody has a working set up, using version 0.113+ of hassio, I wouldn’t get sad if you’d mind sharing the code for it, just to get some hints!
Edit 3: Managed to integrate it with ha alarm using node red, the key was to find those inactivated entities. Now on to the next problem: Getting it to trigger the siren function in my doorbell 6…
Going back to the syncing issue discussed by @soul and @skptic.
I am the original author of the SmartThings device handler for the Zipato keypad, which @soul and @skptic referenced earlier. I recently migrated to Home Assistant, and had to solve the syncing issue (i.e., not being able to disarm the Manual Alarm using the keypad if it had been armed via the app, because the state of the keypad is already ‘home’, and vice versa). I want to contribute my solution here, based on what worked in SmartThings and the work done by other contributors above. I think it was pretty straight-forward in the end, but it took me a while to understand the problem. If you just want my solution, jump to the end. The following paragraphs explain a bit about how this device works and my thought process.
@skptic mentioned that he didn’t feel like dealing with 500 lines of Groovy from the SmartThings device handler. Neither did I, and I wrote that Groovy code! Groovy is horrible, but I took one for the team 
and read back over the my Zipato SmartThings code, and also re-read the keypad’s Z-Wave manual.
The first thing to point out is that the keypad hardware does not know whether it is in ‘home’ or ‘away’ mode. It does not have a corresponding internal state that we need to try to sync with the armed_away / disarmed states of Home Assistant’s Manual Alarm integration, and therefore we don’t need to worry about waking the device up to try to sync it with HA. The ‘home’ / ‘away’ state exists in HA only, and is represented by the value of the “access control” entity associated with the device in HA, which is either 6 for ‘home’ or 5 for ‘away’ (which corresponds to the values emitted by the keypad in the Z-Wave ALARM_REPORT_V2 command).
I note that there is also an “alarm level” entity that is identical to the “access control” entity, but gets the value of either 0 or 255 instead of 5 or 6.
The problem is that if the value of the “access control” entity in HA is already ‘6’ when you tap your keyfob and press ‘home’ on the keypad, then it won’t get updated in HA, and it’s impossible to trigger an automation to arm or disarm the alarm.
The Zipato manual is a bit dense, but its normal operation is quite simple: every time someone presses the ‘home’ or ‘away’ button and taps a registered RFID tag (or enters a registered user code), then it will wake up and send a ALARM_REPORT_V2 Z-Wave command on the Z-Wave network that contains:
- an ‘event’ value of 6 if the ‘home’ button was pressed or 5 if the ‘away’ button was pressed
- a number representing which registered user code or RFID was used
That’s the end of the zipato’s job. The rest is up to us. In my original SmartThing device handler I dealt with the “alarmv2.AlarmReport” z-wave command (in around line 454) by firing off the SmartThings “switch” event with the value of “on” or “off” depending on the contents of the z-wave command. The SmartThings device handler was declared with the “switch” capability, which meant that SmartThings would see the Zipato as a switch, and it would turn on or off when I fired off those events. In addition, any automation could control the state of that switch, e.g., turning it on if the user armed the alarm remotely (remember that this switch is virtual and internal to SmartThings, and doesn’t requite the keypad to wake up or anything). I think this is why the syncing issue didn’t exist in SmartThings.
I think the key difference in Home Assistant is the reduced level of access to the z-wave commands that are received by the z-wave controller. With SmartThings, a community-provided device handler could receive the raw z-wave commands, and do something useful like set corresponding state in a virtual switch, against which 2-way automations could be configured.
In contrast, in Home Assistant, we don’t seem to have this level of access. I can see the ALARM_REPORT_V2 commands zipping by in the z-wave log, but I can’t find a way to respond in an automation or in code. According to the HA Z-wave docs, the closest event that can be listened for is the zwave.node_event, which is only works for the Z-Wave BASIC_V2 command (i.e., not for ALARM_REPORT_V2). In any case, I can’t seem to find any specimens of BASIC_V2 commands on my z-wave network, and I notice some community members think zwave.node_event might currently be broken (in this post).
The key workaround that @skptic identified above is to modify the value of the access_control / alarm_level entities when the state of the manual alarm is changed (his v1 uses a python script, and v2 uses the API from a shell command). This means that the next time a Z-wave ALARM_REPORT_V2 command is sent by the keypad, HA would actually change the value of the entity, which would cause HA events to fire and automations to trigger.
In other words, although we can’t get access to the ALARM_REPORT_V2 Z-wave command, we can make sure HA processes it internally, generating appropriate state change events to trigger our automations.
My solution
Instead of using a bespoke python script or shell commands, I installed the generic Python set_state script by @rodpayne discussed in this post. I then added the automations pasted below, which trigger when my alarm is armed via the app, and sets the zipato’s “access control” entity appropriately. And vice versa when the alarm is disarmed from the app. This fixes the problem, and I can now arm the alarm via the app and immediately disarm via the keypad, plus every other permutation.
- alias: 'Alarm: Arming updates RFID keypad'
description: 'Update value of RFID keypad entity if alarm is armed via the app,
to workaround the problem of disarming via the keypad not updating entity state
and therefore not triggering any automations. '
trigger:
- platform: state
entity_id: alarm_control_panel.home_alarm
to: armed_away
condition:
- condition: state
entity_id: sensor.rfid_alarm_keypad_access_control
state: '6'
action:
- service: python_script.set_state
data:
entity_id: sensor.rfid_alarm_keypad_access_control
state: 5
- alias: 'Alarm: Disarming updates RFID keypad'
description: 'Update value of RFID keypad entity if alarm is disarmed via the app,
to workaround the problem of arming via the keypad not updating entity state and
therefore not triggering any automations. '
trigger:
- platform: state
entity_id: alarm_control_panel.home_alarm
to: disarmed
condition:
- condition: state
entity_id: sensor.rfid_alarm_keypad_access_control
state: '5'
action:
- service: python_script.set_state
data:
entity_id: sensor.rfid_alarm_keypad_access_control
state: 6
2 Likes
One question @janpascal, is it possible to use your ha_lock_history component without installing “lock_manager” ? It seems that you can only install lock_manager if you have a z-wave lock which I do not, but I nevertheless use the zipato keypad to disarm my alarm system.
Never mind … implemented this using Node-Red, parse the z-wave log and create log book entry with the arming/disarming + name of the tag owner.
Raising an old thread perhaps but here goes nothing. So my issue right now is that the only things that pop up when including the keybad in HA is a switch (which doesn’t seem to do anything) and two sensors for battery level and low battery…nothing else.
Is this a Zwave js issue or a general thing…? Am I missing something crucial?
I have been using the same keypad for more than a year and it’s still working as expected - so maybe it would make sense to remove it and add it again?
I’ve removed and added it about 5 times now…same 3 sensors show up and that’s it
Which sensors do you see and which z-wave integration are you using? I am still on the old one. Do you see any error message in the logs?
I have this device using zwavwjs2mqtt. It sends events when a registered code/tag is used for “home” and “away” buttons. The automations I use are similar to these:
The node_id is the zwave node number for the keypad.
- alias: Set alarm armed
trigger:
platform: event
event_type: zwave_js_notification
event_data:
node_id: 55
event: 5
action:
- service: alarm_control_panel.alarm_arm_away
data:
entity_id: alarm_control_panel.alarma
code: !secret alarm_code
- alias: Set alarm disarmed
trigger:
platform: event
event_type: zwave_js_notification
event_data:
node_id: 55
event: 6
action:
- service: alarm_control_panel.alarm_disarm
data:
entity_id: alarm_control_panel.alarma
code: !secret alarm_code
Ok, so I guess that the zwavejs2mqtt is paired with the z-wave js integration (which I haven’t migrated to, yet).
If you go into the configuration → Integrations area in HA, what’s the name of the entities discovered by the z-wave js integration?
Finally, in the “log” area within the configuration menu, do you see any error reported about this integration?
AFAIK, zwavejs2mqtt is zwavejs plus the mqtt gateway (that one can disable if not needed) and a control panel that the former zwavejs integrations did not have (I do not know what’s going on now).
Regarding the devices, the integration creates:
-
A sensor and a binary_sensor for battery management (I changed the entity names, so the original are missing)
-
A switch (same comment)
-
Two sensors: sensor.keypad_with_alarm_activation_rfid_tag_alarmlevel_none and sensor.keypad_with_alarm_activation_rfid_tag_alarmtype_none
I do not use any of these entities, just the events the device sends.
I have not seen any error report regarding this device.
I hope that helps.
Do you use tags or codes? How to setup a user code? Where could I see the events sent?
And finaly, how do you arm or disarm on the keypad?
I am using zwavejs2mqtt too.
Sorry for so many questions and thanks in advance.
Do you use tags or codes?
Both.
How to setup a user code?
In the zwavej2mqtt control panel, expand the node information and then expand values->user code. You will find slots for enabling and entering codes or tags. I had problems with an older version of zwavejs2mqtt to send binary codes, but it is now possible. Maybe you have problems to send the codes since the Zipato sometimes go to sleep before the information is recorded.
Where could I see the events sent?
When a previously registered code or tag is used, HA receives the event “zwave_js_notification”. You can see the data sent when you enter/exit if you subscribe to this event in “dev tools”->“events”->“listen to event” and make some tests (may be the wording is not exact, I am translating on the fly from my Spanish-UI). Which this event and the associated data you can manage your automations for using the keypad events for entering or exiting.
And finaly, how do you arm or disarm on the keypad?
Just following the keypad instructions. The procedure is a little bit different for tags and user codes. Basically enter the code or present the tag and press the “home” or “away” button.
AFAIK the keypad is stateless. It is not in armed or disarmed state. It only sends events.
@janpascal - I’ve created a PR here to add a manifest.json in order to ensure the component to keep working once we reach HA2021.6.0