Basic Home Alarm Setup with Zipato Keypad

Share your Projects!
1

Zipato Mini Keypad RFiD/Z-WAVE

Setup Guide with Home Assistant

Below is a guide for how I setup the Zipato Mini Keypad in Home Assistant for an alarm system. When I was looking to buy this device I say several posts here e.g. asking for how it could be used with Home Assistant so thought it best to give it a try and document the process I will detail a minimalist setup with one sensor.

Minimalist Setup:

  • Raspberry Pi 3
  • Aeon Z-Stick Gen5
  • Fibaro Z-Wave Sensor
  • Zipato Mini Keypad
  • Home Assistant All-in-One Pi Installer
  • OpenZWave Control Panel

1: Add the device to the network

Open up Open Z-Wave Control Panel from its home directory:

./ozwp -p 8888

Point your browser to the location of HA host [hostIP]:8888

Connect your conroller as usual /dev/ttyACM0

Add the Zipato Mini Keypad to the network by selecting operation, add device, then putting the device in inclusion mode by holding tamper switch for 1 sec and releasing.

2: Add RFiD tags and/or codes

Once the device is correctly included the network, close the cover of the device.

It should show up as ‘Schlage Link Mini Keypad RFID’, select it and then “Current Values” on the left.

On the device, press home then place the RFiD tag close to the face of the device (within one second).

You should see “Enrollment Code” change to a 10 value hex. Copy this number and paste into “Code 1”.

Press submit. Now press home again placing the RFiD close and you should see Code 1 is set.

To set keypad code, the process is the same, with the numbers being simply 0x31, 0x32, 0x33 and 0x34 for 1, 2, 3 and 4 respectively. You must press “Enter” after the last key press.

3: Set Configuration of Device (OZWCP)

In "Configuration, set “Feedback Time” to 10 and “Feedback Timeout” to 10. This will allow us to setup Sound notification and acknowledgment in (Type 3 from the manual) in Home Assistant. This is important as it allows us to get confirmation from HA that it received the message.

Save changes (Backup Controller) and close OpenZWave Control Panel with the button.

4: HA Config file (.yaml)

The following are from my config:

Ensure you have ZWAVE:

zwave:
usb_path: /dev/ttyACM0
config_path: /srv/hass/src/open-zwave-control-panel/config

Get the HA alarm

alarm_control_panel:
  - platform: manual

Automations

automation:
  - alias: 'Trigger alarm while armed/away + sensor goes off'
    trigger:
      - platform: numeric_state
        entity_id: sensor.fibaro_system_fgms001_motion_sensor_burglar_4_10
        above: 7 
    condition:
      - condition: state
        entity_id: alarm_control_panel.ha_alarm
        state: armed_away
    action:
        service: alarm_control_panel.alarm_trigger
        entity_id: alarm_control_panel.ha_alarm

The automation below is triggered by the alarm level becoming 255 (away) and both arms the alarm
and turns on the keypad binary switch which informs the device the code has been received, allowing the user to get feedback.

  - alias: Set Alarm Armed
    trigger:
      - platform: numeric_state
        entity_id: sensor.schlage_link_mini_keypad_rfid_alarm_level_13_1
        above: 254
    action:
      - service: switch.turn_on
        entity_id: switch.schlage_link_mini_keypad_rfid_switch_13_0
      - service: alarm_control_panel.alarm_arm_away
        entity_id: alarm_control_panel.ha_alarm

Same as above but for setting home.

  - alias: Set Alarm Home
    trigger:
      - platform: numeric_state
        entity_id: sensor.schlage_link_mini_keypad_rfid_alarm_level_13_1
        below: 1
    action:
      - service: switch.turn_on
        entity_id: switch.schlage_link_mini_keypad_rfid_switch_13_0
      - service: alarm_control_panel.alarm_disarm
        entity_id: alarm_control_panel.ha_alarm

I have been testing the system the last few hours and it seems to be responding as expected. I guess there is better ways to set it up but hopefully this provides a start for a few people who were interested.

7 Likes
2

I love you. I saw the other posts months ago and so far its the final element to complete the setup, but I didn’t want to go buying it for £60 knowing it would not work, so hearing it does work is just amazing.

Finally I can finish off the alarm system !

3

@eperdeme No problem at all. My testing so far has been very positive!

I’m thinking of some improvements to keep the alarm state (in the device) alarm state of the HA manual alarm component in sync.

If you need any help just let me know. I have the Aeotec Siren arriving this week and looking to hook it up with different sound using zwave.set_config_parameter as shown in the post here.

Will keep this thread going with updates.

4

Hey.great news for the pad. May I ask how you mounted the pad on the wall as I plan to mount one outside my house for the main door but wanna be sure I can fix this with screws

5

I used some of the 3M double sided adhesive foam which I had spare from an IKEA Tradfri remote. Very solid stuff.

6

I’m interested to hear how you have done/are doing this. This was the reason I had to migrate the keypad from OZW to my Vera.

I have a household with wife, three kids, cleaning lady, nanny etc. All Home/away/arming is totally automatic and for a large degree dependent on phones.

Main main issue was that HASS does not (did not?) get a ‘last updated’ value. I described the problem here

So even if the alarm was disarmed and the cleaning lady would come in and she would use her RFID tag for coming in and leaving I wanted to make sure all was kept in sync. If I would do a RFID disarm while it already was disarmed I would have no way to catch that in HASS as the panel would not send anything to hass I could use to know there was a succesfull RFID tag used.

Anyway, curious to find out how you did this.

7

I assume you must have a switch in HA that gets activated when a command is sent from the keypad? Something like:

switch.schlage_link_mini_keypad_rfid_switch_XX_0

For me, this gets turned on when there is a state change. However I just did some testing you are correct, it is only activated when the state change is different from what is currently in the panel with the HA state as a sensor, something like:

sensor.schlage_link_mini_keypad_rfid_access_control_XX_9

For me this has not been a problem as it is only have myself and my wife, both with the same level of access and the alarm is either on or off. I had not considered your type of situation before but it would be nice to have a solution for it.

I will try out with ozwcp now to see if I can figure something out. O

On related note, are you using the values of these sensors?

sensor.schlage_link_mini_keypad_rfid_sourcenodeid_XX_2
sensor.schlage_link_mini_keypad_rfid_alarm_level_XX_1
sensor.schlage_link_mini_keypad_rfid_alarm_type_XX_0
sensor.schlage_link_mini_keypad_rfid_burglar_XX_10

I assume these use zwave associations/groupings (which I am very niave about).

I guess the associations must be set up with OZWCP but am not sure how.

8

Great to hear this is working. I’m building my alarm atm and I was missing the bit that would let me physically arm/disarm. We use location tracking and the iOS app for general arm/disarm but for things like guests etc you need another entry method.

You mention work required to keep things in sync better. Are you saying that right now if you set the alarm state via another method (phone, automation etc.) then the Zipato doesn’t correctly show that state though?

Did you get the walk-in/walk-out buzzer working? i.e. does that sync up with the Pending time on the HA Alarm component?

I’ve already got the siren and a couple of door sensors.

9

I don’t have a solution to the above questions, but thought I’d share my current config that I am using thanks to @skptic. It’s fairly basic config so most new starters in HASS will be able to understand it.

https://github.com/eperdeme/homeassistant-config/blob/master/automation/motion_notify.yaml

Works for the standard use case of tap when leaving etc method, integrated the Google Home to notify of being armed / disarmed etc.

Need to add some delays in motion detection so it’s warning prior to the siren firing.

10

You mention work required to keep things in sync better. Are you saying that right now if you set the alarm state via another method (phone, automation etc.) then the Zipato doesn’t correctly show that state though?

Yes, exactly. The state is not updated to the keypad itself as it is a battery device ie. it sleeps. This could be a problem if for example:

  1. The alarm state is armed in both (HA = armed, Zipato = armed)
  2. You disarm the alarm from HA (HA = disarmed, Zipato = armed)
  3. You go to leave home, arming via Zipato (HA = disarmed, Zipato = armed)

Because the state has not changed in Zipato, in step 3 the alarm will not arm.

However, with the automation, what saves this however is the different notification sound.

You can tell from the notification sound (emitted from the keypad) if the Zipato switch in HA was activated (see automations above). When changing state correctly (ie both Zipato and HA have successfully communicated in both ways), you get the long notification sound which you can configure via zwave parameters.

In the case above, you would not receive the notification sound, meaning you know you would have to press ‘Home’ + swipe RFiD, then ‘Away’+ swipe RFiD, upon which time you will receive the correct notification sound from the Zipato.

Sorry if my explanation is a bit convoluted. I am still working on this and tuning the parameters to make it more robust.

Did you get the walk-in/walk-out buzzer working? i.e. does that sync up with the Pending time on the HA Alarm component?

Still have not got around to implementing it but I see no reason as to why it would not work. I ideally want it to work with the Siren but have had a few problems get HA to send zwave params. Work in progress but I will update here with a full config and zwave parameters.

11

Thanks for the quick reply!

So you can’t set the state of the Zipato from HASS ever, or only when it’s awake? I was assuming HASS would see a switch or something indicating the Zipato mode, that you could set using HASS. My Neo CoolCam Siren is a battery device but the switch is always there in HASS for me to set it off.

Is it possible to set the config of the Zipato to never sleep perhaps?

12

Hmm from the manual there is an always-awake mode, but it will drain the batteries too fast. I wonder if it could be wired to a usb power source or something.

If it gets out of sync it’s going to cause problems as I can see my wife sometimes using the Zipato, sometimes her phone, sometimes forgetting. If HASS alarm has been armed automatically and she comes home, if she then tries to use the Zipato, is it not going to disarm HASS as it thinks HASS is already disarmed?

13

Is it possible to set the config of the Zipato to never sleep perhaps?

There is an option for that, but I believe it is only for config/debugging.

See here in “ALWAYS AWAKE MODE”.

So you can’t set the state of the Zipato from HASS ever

As I have set it up, no.

14

This guy has set it up for Smartthings, and seems to imply that he sets the Zipato state from his other automations. I wonder if he’s just been lucky and the Zipato has been awake when he’s set its status, or if he found some way to do it reliably.

15

I need to go back and read the manual very carefully,

Specifically need to look into the command WAKE_UP_INTERVAL_SET command described in COMMAND_CLASS_WAKE_UP section.

From this it should be possible to specify HA -> Zipato values. Even something like syncing every 10 min would be very nice.

16

So HASS does see it as a switch HASS can set, the issue is it might not set it as it’s asleep?

If so then yes don’t we need to just set the wakeup interval to something shorter (the default is 2hrs), so it wakes up, sees the message from HASS and sets itself to the right value? Something like 10/15mins would probably be fine.

17

Hmm HA Alarm has 3 states - disarmed/home armed/away armed - while the Zipato only has armed/not armed. According to the manual the ‘home’ button is used to disarm, not set home armed mode. I thought the home/away buttons were for the home/away arm modes and disarmed was just by entering a code.

I use all 3 modes so I wonder if this keypad might not fit all circumstances. Maybe it’s possible to use 2 different codes to arm the 2 modes in HASS. Alternatively I guess I could just use the Zipato for away arming and put it by the front door.

18

I have attached the Zipato to a USB charger and used a very small step down converter (5 to 3.2v). This works fine and can be put within the existing housing.

As mentioned earlier, I also did not find a way to set the state of the Zipato (also not by Vera). So I basically ignore the state. I just check if there was a valid disarm (even if it was disarmed) and use that to disarm hass. The same for arming. A valid arm on the Zipato will Arm HASS even if the Zipato already was in Arm.

19

@Tyfoon @Soul think I have some serious progress :grin:

Using appdaemon I can now keep the keypad synced with HA. The procedure is as follows:

1) Define the wake up interval of the keypad (using ozwcp for example):

This time (in seconds) will be the maximum amount of time that the alarm status in HA could be changed with the device not knowing (being out of sync).

For now I have set up mine to 5 min (360 sec).

2) Download and install appdaemon

From here install appdaemon.

I used the pip method on my Pi3 explained in the README.

3) Set up appdaemon as in the README

Set up the AppDaemon config with your ha_url etc… and test the hello_world app is working.

4) Create the appdaemon app

I wrote a small app based something similar from magnushacker here. Thnx @magnushacker!

In the conf/apps/ directory of appdaemon, create a new file called alarmsync.py.

Copy the following text to the file:

import appdaemon.appapi as appapi

#
# Sync alarm level and HA manual alarm so they are synced to have the correct
# status (on/off) when triggered by the remote from outside HA.

#
# Args:
# HA_alarm: entity ID HA manual alarm (state is either disarmed, armed or pending)
# Zipato_alarm_level: entity ID of the Zipato alarm level (state is either 0 or 255)
# Zipato_alarm_access_cntrl : entity ID of the Zipato alarm access_control
# app name: entity ID of manual alarm state to sync with

class AlarmSync(appapi.AppDaemon):

  def initialize(self):
    self.listen_state(self.state_change, self.name)
    self.log("AlarmSync to %s" % self.args["Zipato_alarm_level"])

  def state_change(self, entity, attribute, old, new, kwargs):
   if new == 'armed_away':
     self.set_state(self.args["Zipato_alarm_level"], state='255')
     self.log("Changed Zipato_alarm_level to 255")
     self.set_state(self.args["Zipato_alarm_access_cntrl"], state='5')
     self.log("Changed Zipato_alarm_access_cntrl to 5")
   elif new == 'armed_home':
     self.set_state(self.args["Zipato_alarm_level"], state='255')
     self.log("Changed Zipato_alarm_level to 255")
     self.set_state(self.args["Zipato_alarm_access_cntrl"], state='5')
     self.log("Changed Zipato_alarm_access_cntrl to 5")
   elif new == 'disarmed':
     self.set_state(self.args["Zipato_alarm_level"], state='0')
     self.log("Changed Zipato_alarm_level to 0")
     self.set_state(self.args["Zipato_alarm_access_cntrl"], state='6')
     self.log("Changed Zipato_alarm_access_cntrl to 6")

5) Create the config for the app

Add the following to the end of appdaemon.cfg (below # Apps) located in the conf directory.

[alarm_control_panel.ha_alarm]
module = alarmsync
class = AlarmSync
Zipato_alarm_level = sensor.schlage_link_mini_keypad_rfid_alarm_level_13_1
Zipato_alarm_access_cntrl = sensor.schlage_link_mini_keypad_rfid_access_control_13_9

Note that the following must correspond with your entity ids in HA:

alarm_control_panel.ha_alarm = HA manual alarm panel
Zipato_alarm_level = Zipato alarm level sensor
Zipato_alarm_access_cntrl= Zipato alarm access control sensor

6) Start the daemon or set to start on startup.

As described in the README.

How does it work?

The keypad to HA state updates worked fine with my initial setup, however as discussed above HA to keypad could get out of sync.

With this however, whenever the HA manual alarm state changes (to arm_home / arm_away or disarm), the app changes the values of the keypad sensor values to match.

Now the cool thing is that the wake up time defines how often the keypad checks on the status of the (now updated) sensor values in HA.

Anytime the sensor values are different in the HA sensors compared to the physical keypad, and the keypad wakes up (in my set up every 5 min), the keypad will take on the values defined in the HA sensors.

Going forward with HA

From this we see that the HA “sensor” type is not ideal for this type of device. The reason being is that HA does not allow us to define sensor values in automation, hence the need for appdaemon.

I am new to HA but maybe it would be good to get the opinion of others as to how these types of situations can be handled more easily in the future. Simply allowing the ability to set the state/value of a sensor (as can be done via the web UI) in an automation would be a great help. And I think this case/device makes a good point for doing so.

I plan to keep making improvements such as including in the app for edge cases (what to do whilst the manual alarm is pending etc).

I will keep testing this and let you know if there are any problems. If you have any questions then fire away. HA seems to have a great community and I have really enjoyed troubleshooting this. Thanks everyone for the motivation :+1:

1 Like
20

Sounds interesting!

I’m just surprised we need it - the Smarthings implementation doesn’t have the issue so are they doing something similar to what you’ve done? Do we need to build a proper Zipato Keypad HASS component perhaps, rather than using standard sensors and appdaemon?

And how would the walk-in buzzer ever work? If the Zipato is asleep and the alarm trips when you walk in the house, nothing could tell the Zipato to start the walk-in sound.

So many questions :slight_smile: Thanks for all the work so far @skptic