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.
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.
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.
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.
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.
@Tyfoon @Soul think I have some serious progress 
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 Like
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 
Thanks for all the work so far @skptic
Did not check but looks like great piece of work! Just like Smarthings it also syncs by default in the Vera hub.
I think the key point is that we would not need to use the appdaemon if in the automation we could do something like:
trigger:
- platform: state
entity_id: alarm_control_panel.ha_alarm
to: 'disarmed'
action:
- service: homeassistant.set_value
enitiy_id: sensor.schlage_link_mini_keypad_rfid_alarm_level_13_1
data: 0
For some reason there is no way (I know of) to do this in HA. The strange thing I would like to stress is that you can set sensor values from the web UI.
This is how I figured out this would work even before installing appdaemon (which I had never used before today). So it should be a whole lot easier than it is. Maybe time for a feature request. Or a good opportunity to write a new component.
Iām not too keen write over 500 lines of groovey right now 
But it is interesting to find out how these systems are two-way syncing.
So in HASS the Zipato only gives us sensors, not switches where we can set the value of that switch and the Zipato state changes?
Youāre managing to set the state via appdaemon (Iām not sure how you figured that out since I canāt see a way to do that from the user manual) but the fact that you can do that but not via HASS makes it feel like we need a zipato-specifc implementation in HASS. Or the zwave DB xml youāve got is incomplete and isnāt giving us access to all the functions?
This is what I can see in the zwave config for the device. Is it me or are a lot of the command classes missing?
hass@server:/srv/hass/src/python-openzwave/openzwave/config/zipato$ cat MiniKeypad.xml
<?xml version="1.0" encoding="utf-8"?>
<!--http://www.pepper1.net/zwavedb/device/302-->
<Product xmlns='http://code.google.com/p/open-zwave/'>
<!-- Configuration -->
<CommandClass id="112">
<Value type="byte" genre="config" instance="1" index="1" label="Set to Default" value="-1">
<Help>Set all configuration values to default values (factory settings).</Help>
</Value>
<Value type="list" genre="config" instance="1" index="2"
label="Feedback Time" value="0" size="1">
<Help>To configure the time the beep is automatically turned off in seconds.</Help>
<Item label="Disabled" value="0"/>
<Item label="Endless" value="-1"/>
</Value>
<Value type="byte" genre="config" instance="1" index="3" label="Feedback Timeout" value="0">
<Help>To configure the timeout to wait for a WAKEUP_NO_MORE_INFORMATION before the error beep is automatically sound. The error beeps are fixed 8 beeps shortly after each other.</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="4" label="Feedback Beeps per Second" value="2">
<Help>To configure the number of beeps per second. Every beep is fixed about 10ms.</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="5" label="The Mode" value="1">
<Help>To configure the operating mode. If any mode other then 3, that value will be reported after a get but will be handled in SW as mode 1.</Help>
<Item label="Mode 1: Normal operating mode." value="1"/>
<Item label="Mode 3: Z-Wave chip is always on to request e.g. version or manufacturer id." value="3"/>
</Value>
</CommandClass>
<!-- COMMAND_CLASS_ALARM AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false" />
<!-- Association Groups -->
<CommandClass id="133">
<Associations num_groups="1">
<Group index="1" max_associations="5" label="Group 1" />
</Associations>
</CommandClass>
</Product>So only COMMAND_CLASS_CONFIGURATION_V1 and COMMAND_CLASS_ALARM_V2 are implemented?
Wouldnāt we need to implement the others e.g. COMMAND_CLASS_SWITCH_BINARY would give us a switch in HASS to be able to turn on the walkin/walkout buzzer?
The switch is implemented. This is how I am able to confirm to the keypad that the command was received.
I understand that the commands other than config are automatically found, but that may be incorrect.
Nevertheless, above I tried to explain how I use the switch with:
I donāt think the switch can push and wake the device but I again I could be wrong.
As for the walk-in/out, I think it is best to implement that on the HA manual alarm component side. It is not specific to the keypad and it can be a simple automation triggered when the manual alarm goes for disarmed to armed etc.
Hmm interesting - didnāt know that the zwave device provides the commands to the controller - thought it all came from the zwave DB files.
From the manual it reads to me that the switch just turns on the notification. So how are you actually setting the state of the device via appdaemon? The manual doesnāt seem to provide a command to set the status (home/away) on the device?
I can see you doing things like
self.set_state(self.args[āZipato_alarm_access_cntrlā], state=ā5ā)
but what COMMAND does that use?
I set the value in HA first. Then whenever the keypad wakes up (set with WAKE_UP interval), the keypad takes the value of home assistant. So the max unsynced time is set by wake up interval.
It is not documented like that but I figured out in the web UI using the āStatesā -> āSet Stateā and watching the values in the logs.
Ahh sorry I think I understand now
So the keypad wakes up and looks at its sensor value in HASS. The sensor value is not something HASS itself changes - it changes the value of the ha_alarm component. So the appdaemon is there to change the HASS sensor value, because HASS wonāt?
If so thatās interesting as I thought sensors were 1-way - the device set the sensor state not the other way aroundā¦
Exactly right.
This is why I think the HA sensor is maybe not the best structure for the alarm keypad values.
1 Like
Been thinking about this on my ride in to work and I see two clear things for improvements:
1) Feature request or git issue for setting state
This allows us to remove the need for the appdaemon hack as explained by @Soul here.
2) Integrate the changed by attribute of HA alarm
Shown here. This could allow automatons/logging/rules based on specific users as requested by @Tyfoon above.
See here for an example that uses state attributes in an automation template.
This would require getting the user code which is currently passed from the keypad to the z-wave controller but not currently captured by HA.
- ??
If anyone else has anything else then I would love to hear as it is looking like it may be best to create a new component (I have no experience with this however).
1 Like
At least we have a good workaround with appdaemon thanks to you @skptic
I might order one today so I can see how itās working first hand and perhaps help with making a better solutionā¦
Minor thread hijack.
Does anybody else find the RFID unit starts making its beeping noise at random (or possible timed events/wakesup?).
I can be sat down and hear it making its beeping noises for a few seconds every so often throughout the day.
1 Like