I had to take a hiatus from developing some HS110 code to work on this keypad. I’ve now got it working but it’s a troubling device. It is a keypad but it’s primary function seems to be to switch between home and away modes rather than do a specific lock / unlock.
I 100% have this working but I’m looking at where to add the functionality - to the device handler or the smart app. Ideally I wouldn’t like to require a smart app but programming this thing without one is a “pain” as device handlers do not support dynamic configuration parameters.
Does anyone know Is there such a capability type as a mode changer switch, or a presence detector with mode changing ability? Does anyone handle their security or away modes like this?
When I’m using this I’ll be switching on away mode and then would like a timeout before the mode change event is sent to smartapps - I can do this directly in the device handler and give some audible feedback on the pad. Does anyone think this should be done in the app instead of the handler?
Finally I toyed with the idea of enabling a “register” mode on the keypad by inputting a sequence defined in the device handler, thus doing away with the need for a smartapp but this is very clunky! Does anyone have any better ideas.
Nice to hear someone is working on this – – I know quite a few people have been interested in it.
As far as your questions, Mode is global-- from a platform architecture point of view, I would think it would best be changed in a smartapp rather than a device type handler. It’s not a characteristic of the device itself.
As far as a delay, I think that can go either way. If you consider it a device characteristic, you can put it in the device type handler, not dissimilar from an architectural standpoint in the way a double tap is handled.
@erocm1231 might have some more ideas, he’s done a lot with button type devices. Otherwise I’m sure some of the other master coders will chime in.
One more thought: if you add the capability.button for your device type handler, you should be able to make this compatible with core, and then Core can do a lot of the heavy lifting from the smartapp side. You might not need to write your own smartapp at all. Core could definitely do the delays.
What perhaps has thrown off all other integrations with this device is that it maintains an internal database of codes. it is not a simple keypad, you cannot access buttons.
It will let you know when a code is used and whether it is recognised allowing you to reply to it and confirm whether it should register it, it is then up to you to maintain your database against it’s database.
There is a bug with smartthings and rfid codes with this device which I believe I have worked around.
Keep us posted on how well this works as a keypad arm/disarm device for multiple users. I hadn’t seen this particular device before, but it looks perfect for what I’m looking for, its available in Canada, and the price point is not unreasonable…
Yes Lock Code Manager is an amazing app, very well written which helped me when trying to put together the device handler for the keypad. I’d love to be able to make the handler compatible instead of writing a smart app but I’m struggling conceptually to see how it would fit given the very slight difference in use.
I’ve taken the route of putting together a very rough smart app as way of an example (and also just to get it working in my setup!) Ideally once working I’d like to pass this to the Smart Lock Manager author to see if he has the time to integrate the little operational nuances.
If anyone can get hold of one of these they are a very solid build, I must have hit the buttons over a thousand times now and no signs of deterioration on the switches. The case is solid though may discolor over time but wouldn’t crack if hit. It’s a sleepy device and batteries are still reporting 100% after a couple of weeks of hacking away on it. Range is decent, working well in an old UK home (solid walls) at a distance of around 15 meters through a couple of walls.
What’s puzzled me at the moment is that given this is a sleepy device, do I recheck and sync the config when an event occurs or do I make the user hit a button on the their keypad(s) to sync them. I’m then ignoring the events this device should send UserCode and Alarm.
To add an RFID which has non ASCII characters I will need to switch the device handler into a learn mode any way. Be this via a code or a click in the smartapp. Scan your code then confirm in the app.
Does anyone have any ideas how we could make a wonderful user interface to bridge this device? I’ll have a dumb interface ready this week.
In case it’s useful, I just finished creating a device handler for this device. It’s working well for me so far. The device exposes the switch capability (home=off, away=on), which allows you to automate against it with regular SmartApps. Took ages to get it working right - the Zipato manual is fairly lacking, and the SmartThings IDE is pretty frustrating. Also, I hit up against a bug in ST’s setUserCode function, which blocked development for a while (it translates low value bytes in user codes into ASCII representations, preventing RFIDs from being recognised. I ended up manually forming the z-wave command).
You can register 9 RFID tags or user codes. Look in the readme file for more detail.
Wow, some cool progress made on this. I keep revisiting my implementation but looks like Sean already got to where I was and also spotted the same bug I did. Very frustrating, wonder if we both solved i the same way for the tags? (https://github.com/alexgrahamuk/zipato-keypad) - I totally needed to re-engineer this to make it not only work with other smart-things but I didn’t totally understand sleepy devices when I started.
Mpovolo, this is a sleepy device so you could only ever make it beep after it A) reported in [not often] B) some body keyed in a combination correct or incorrect. At this point you can make this beep forever if you wanted to but it would flatten the battery and while it’s beeping there’s not much you can do. You can tell it to beep / peep with some commands but if you want something just to beep I’d suggest maybe a zwave siren.
I wasn’t sure myself what to do with this as initially I wanted to use it when exiting the house to arm some set of routines but I’ve since looked at using it to supplement the Yale Connexis lock with the Zwave module to give another way of unlocking in case of emergency (you leave the house without your tag, card, phone) and was considering burying it in a bag with a spare battery in the plant pot next to the front door.
It’s a brilliant unit but isn’t a keypad!
NB: @seanblanchfield if there’s anything you can use in my device handler or app, please feel free to use it in your Zipato Keypad release no rights reserved. Hoping to use your release myself!
Is it possible to have the home and away buttons in here momentary. Let me explain why I am thinking that.
I find that if I arm my home in anyway other than using the keypad, the Key pad because its not synced will be on home, and the disarm code will not work. However if they were both momentary then either button runs the appropriate command regardless the true state of the home. I would stay with switch on/off route if the pinpad actually had an active LED identifying the current state, which it does not and the only way to know is via the app
Interesting idea. Technically I think it would be easy enough to write (however, testing these changes on smartthings is way harder than making them!). It would involve replacing the Switch capability (line 31) with the Momentary capability, removing the “homeaway” tile on line 67, and replacing the on/off functions (line 246) with a single function that to sends the “push” event to the “momentary” capability, and something similar when handling the AlarmReport command from the device on lines 376 and 381.
The practical problem I would see, at least in my case, is that sometimes I arrive home and I’m not sure whether the system is in home or away mode (sometimes it auto-disarms based on some automations I have set up, or sometimes I just forget to set it). If I tried to disarm the alarm in that situation, I would actually accidentally arm it, and then set off my siren when I pass the first motion sensor.
For what it’s worth, I haven’t actually had any trouble with the home/away state of the keypad falling out of sync with smartthings.
Can I implement this keypad as follow:
When somebody opens the frontdoor (with a sensor) and the SHM is in away mode, you need to put a code in 30 seconds, otherwise my alarm will be triggered?
At this moment I’m just using mobile phone presence. So when my GF or myself arrives at home the SHM is in disarmed, so we can open the door without alarm.