Basic Home Alarm Setup with Zipato Keypad

@soul this is what is in my zwcfg file:

<Value type="list" genre="config" instance="1" index="5" label="Alarm Music Index" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="10" vindex="8" size="1">
					<Help>This parameter defines the alarm music index for siren play different music when alarm occurs. There are 10 different music for user selection</Help>
					<Item label="Doorbell" value="1" />
					<Item label="Fur Elise" value="2" />
					<Item label="Doorbell Extended" value="3" />
					<Item label="Alert" value="4" />
					<Item label="William Tell" value="5" />
					<Item label="Rondo Alla Turca" value="6" />
					<Item label="Police Siren" value="7" />
					<Item label="Evacuation" value="8" />
					<Item label="Beep Beep" value="9" />
					<Item label="Beep" value="10" />
				</Value>
				<Value type="list" genre="config" instance="1" index="6" label="Door Bell Music Index" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="10" vindex="9" size="1">
					<Help>This parameter defines the door bell music index for siren play different music when alarm occurs. There are 10 different music for user selection.</Help>
					<Item label="Doorbell" value="1" />
					<Item label="Fur Elise" value="2" />
					<Item label="Doorbell Extended" value="3" />
					<Item label="Alert" value="4" />
					<Item label="William Tell" value="5" />
					<Item label="Rondo Alla Turca" value="6" />
					<Item label="Police Siren" value="7" />
					<Item label="Evacuation" value="8" />
					<Item label="Beep Beep" value="9" />
					<Item label="Beep" value="10" />
				</Value>

I donā€™t quite remember but it could be that I had problems and set up the siren using ozcp and then copied the entry over to the HA zwcfg file. I can send you a full copy of my config entry if you want.

(otherwise letā€™s take this to a separate thread as weā€™re hijacking this one :-))

Yeah good point!

So Iā€™ve read the above, and Iā€™m still trying to understand what this syncing business is about or how to do it best.

Iā€™ve got automations running based on sensor.zipato_hallway_keypad_alarm_level being 0 or 255 and arming/disarming the HASS alarm control panel. This seems to work fine.

So why do I need to sync?

@Soul If I understand your question correctly this whole discussion was about the following scenario:

  1. Arm the alarm using the tagreader
  2. disarm using the web/phone

In this case the tagreader will still think the alarm is armed. If you now arm the system again using the tagreader the status of the reader will not change, and therefore the alarm will not arm. The syncing was to somehow try to persuade the tagreader that the system is disarmed in another way than via the tagreader.

If you only use the tagreader this will not be a problem anyway. What I do is some of what was described above, when I arm/disarm the system using something else then the tagreader I update the alarm_level to 0 or 255 (depending). But itā€™s trickery the tagreader itself will not be updated.

Makes sense?

Ahh I hadnā€™t tried the situation where I armed with the keypad then disarmed with my phone then tried to rearm with the reader again. Right I need to get this syncing to work then as Iā€™m planning to use all sorts of different methods to arm/disarmā€¦

Is the current best way to use those shell_commands above?

Thatā€™s what I use and seems to work.

One thing to watch out for (and I havenā€™t resolved yet) is that if you update the virtual state of the tagreader via a shell script to ā€˜disarmedā€™ (so the tagreader is still in armed state) and then reboot HA the automation to arm the alarm will trigger because of the state of the tagreader . This may result in a lot of noise :frowning:

Could you get the opposite as well - HA restarting (and I have an appdaemon app to put the alarm back to armed if it was before the restart) - but because the keypad is disarmed (because the arming was done by a phone) the keypad ends up disarming the alarm when you want it to be armed?

I guess, depends which one fires first. But ultimately should be possible to automate this to something working correctly.

Hmm but this further up

suggests the keypad will take the value from HA if different to itā€™s value after it wakes up?

Iā€™m not sure if Iā€™ve missed it, but is there a (short) how-to documented somewhere? Iā€™ve gone up and down this thread but not sure where to start.

Hi @soul suggest to test it and let us know. I have my (strong) doubts that actually happens :slight_smile:

1 Like

Yeah will do. Iā€™m a bit concerned as my HA install seems to hang randomly and I have a script to restart it. Going to cause some problems if having the device out of sync starts arming or disarming when it shouldnā€™t.

Itā€™s a bit annoying that the keypad has state at all - Iā€™d prefer it to be dumb and just sent the arm/disarm message when someone actually uses it. I guess it remembers the state so it can do things like exit beeps.

Iā€™m really unclear exactly how data is pushed/pulled and when with this deviceā€¦

So I think these two bits are the important ones

CLASS: 0X84 COMMAND_CLASS_WAKE_UP
The Wake Up Command Class is used at battery-operated devices.
This class allows the Mini Keypad RFiD/Z-Wave to wake up
occasionally to notify others devices, that the Mini Keypad RFiD/ZWave
is ready to receive commands. After receiving the commands
the Mini Keypad RFiD/Z-Wave will go into sleep mode again. The wake
up interval can be set using the WAKE_UP_INTERVAL_SET command.
The default value is 0x1C20 = 7200 sec = 2 hour
The default node is 0xFF = 255 (broadcast)
It is possible to send a wake up notification on user interaction.
Besides sending a Wake Up Notification automatically every 2 hours
(or any other time that is configured using the Wake Up Interval Set
command), the Mini Keypad RFiD/Z-Wave also sends a Wake Up
Notification when:
The tamper alarm state changes (Mini Keypad RFiD/Z-Wave is
mounted or removed from the wall)
A tag read
A code is entered using the keypad
When the wake up time is set to 0 a wake up notification is never send
periodically, only on user interaction

and

CLASS: 0X71 COMMAND_CLASS_ALARM_V2
In the Mini Keypad RFiD/Z-Wave, this Command Class has two
purposes:
1 | Identify the state of the tamper alarm. The device will send an
unsolicited report to the devices in its association group if tempering
is detected. The state of the tamper alarm can also be requested
by any other device.
2 | Report tags or codes that are entered. The Mini Keypad RFiD/ZWave
will send an unsolicited report to the devices in its association
group with the UID that belongs to the code or tag and whether the
alarm system should be armed (Away) or disarmed (Home).
Every other alarm type that is requested will be ignored by
application.

Well Iā€™ve got the shell commands running to set the state. Going to do some testing now to see how well it reacts.

Seems to be working, even through a couple of restarts were the pad should be in a different state to HA afterwards.

Itā€™s weird though. Sometimes after either arming or disarming via the keypad it beeps for 30s or something. It seems fairly random though. Like why would it beep for 30s after disarming? I can understand it after arming as itā€™s warning you to get out.

I understand the beeping is related to the ā€œswitchā€. In HA, the switch command can get queued as the device is asleep. When the device wakes up, it sees the switch command and beeps.

I wondered what that switch in HA was for. I wonder if it can be disabled?

Thereā€™s a Feedback Time config parameter set to 16. Maybe setting that to 0 turns it off.

Ugh so Iā€™ve wasted 2 hrs trying to exclude and then include in securemode, so have given up on that. But that process wiped my user codes / tags and HA canā€™t set them :frowning:

Massive faff but managed to get OZWCP running in another container so I could set my codes again.