Basic Home Alarm Setup with Zipato Keypad

Tyfoon · May 9, 2017, 7:32pm

Did not check but looks like great piece of work! Just like Smarthings it also syncs by default in the Vera hub.

skptic · May 9, 2017, 8:14pm

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.

Soul · May 9, 2017, 10:32pm

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?

Soul · May 9, 2017, 10:41pm

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>

Soul · May 9, 2017, 10:44pm

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?

skptic · May 9, 2017, 10:49pm

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.

Soul · May 9, 2017, 10:53pm

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?

skptic · May 9, 2017, 10:57pm

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.

Soul · May 9, 2017, 11:03pm

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…

skptic · May 10, 2017, 6:15am

Exactly right.

This is why I think the HA sensor is maybe not the best structure for the alarm keypad values.

skptic · May 10, 2017, 8:51am

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).

Soul · May 10, 2017, 9:03am

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…

eperdeme · May 24, 2017, 8:45pm

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.

skptic · May 26, 2017, 9:17am

@eperdeme It happens occasionally for me too. Depending on your notification sound parameter it happens when the device wakes up and receives the switch from the controller. See issue 2 below:

I am still working away on perfecting the controller for all use cases.

Issue 1
Yesterday I found the cause of an issue in OZW regarding parsing of the ALARM_COMMAND_CLASS message and have raised it over at OZW. The TLDR is that OZW is not taking the additional ValueByte containing the user code id.

See here: https://github.com/OpenZWave/open-zwave/issues/1230

Issue 2
The final issue to solve regards the Wake Up command which I am also working on. The problem is that upon wake up and receiving of a message, the device gets sent a WakeUpCmd_NoMoreInformation before HA is able to send the signal to turn on the switch.

The difference in time between the two for my setup is approx 0.2 sec too late. The effect of this is the device does not receive the the turn on switch command and it gets queued. So next time the device wakes up, it receives the turn on switch command and makes the notification sound (depending on your notification sound setup).

Sorry for the horrible explanation, but it has been clear in my head for the last week what is going on but I haven’t quite found a solution.

It could be solved by simply having the controller wait a second before sending the WakeUpCmd_NoMoreInformation so if anyone has any ideas on how to do that they would be very welcomed.

Soul · June 9, 2017, 5:33pm

Got my keypad finally today, so will have a go at getting it working

Gilberto_Garza · August 7, 2017, 2:31am

Great work!
I would like to install this in my home, but what happens if you don’t have internet, have you thought about adding a GPRS/3G/4G backup system? If you do, what system would you choose?
Thank you!
Gilberto

frelev · September 23, 2017, 8:20pm

I´m about to get one of these.
Is the procedure still to use the guide in post 1 and then add the additional in 19?

ibennani · October 2, 2017, 7:30pm

Hello.

I have the Zipato Mini RFiD Keypad and I’d like to use it to set the different modes in my house alarm running Home Assistant 0.53. I.e. I’d like to change the value of an input selector by using this control panel.

I have read all the other posts concerning this device already posted in this forum, but as far as I can tell, these posts do not adress the issues I’m facing. I have no intention in syncing the state of this device, I just want to use it as a “dumb remote” for my house alarm.

So, here’s what I have achieved so far:

I have paired the Zipato keypad with my Aeon Z-wave stick and the Zipato keypad is visible within Home Assistant.
I have renamed the Zipato keypad in Home Assistant. Now it is called kontrollpanel_hallen.
In the Sensors-section, I can se these devices:

sensor.kontrollpanel_hallen_access_control
sensor.kontrollpanel_hallen_alarm_level
sensor.kontrollpanel_hallen_alarm_type
sensor.kontrollpanel_hallen_burglar
sensor.kontrollpanel_hallen_sourcenodeid
switch.kontrollpanel_hallen_switch
zwave.kontrollpanel_hallen

As far as I can tell, nothing happens when I press the buttons on the Zipato keypad and/or “blipp” the RFID badge. None of the states or attributes do change.

Question: How can I tell if and when the buttons on the Zipato keypad has been pressed and/or when I blipp any of the RFID-badges?

When I know how to detect these actions, I can write som automations using these actions as triggers.

smi · October 4, 2017, 8:03pm

I also can’t get this to work.

Tried “translating” the manual to 0.54 (so without ozwcp) but I can’t even read the codes from adding a tag / setting a user code or whatever.

Is it possible to pass the inputs directly to home assistant so everything can be set up in ha?
Easy speaking something like this in the log:
Home + 2 + 1 + 3 + 1 + Enter

If not, is there a way to use it with the ha-built in functions, without ozwcp)?

Thanks!

bellduck · October 6, 2017, 1:52pm

+1 on @ibennani and @smi’s post. Can’t figure out how to get RFID and pins in the HA GUI.