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’)
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.
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…
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 @Soulhere.
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).
@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.
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.
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
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.
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.
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)?
But it is interesting to find out how these systems are two-way syncing.