SmartThings Community

CentraLite Keypads

keypad
dth_security

(Bernie H) #213

I gave it a quick try before leaving for the weekend and it didn’t seem to work. I will have more time to play once I get back home.

Also I didn’t have time to remove the keypad manager app first so that may be the issue.


(Ben Lebson) #214

Thanks for trying it out. It was kind of a shot in the dark so let me know if you can get it working or not.


#215

Hi All,

I am looking to add a keypad to set up the appropriate SHM Modes upon enter/exit of the home. I skimmed through the thread but have the following questions:

Can this keypad be used to set SHM Modes and to also set up a security code for entry? Can this be used like a traditional security alarm to set the appropriate mode upon entry / exit?


(Stephen) #216

There is currently no delay option so when you open your door, the SHM will trip the alarm. You would have to put a keypad outside of your home


(Brian) #217

I’m getting this when I try to access the devicetype from the smartapp: groovy.lang.MissingPropertyException: No such property: supportedCommands for class: java.lang.String @ line 107

keypad is the input to the smartapp. This has got to be some dumb thing about groovy I don’t know yet, I’m a java hack (barely). Pick this back up tomorrow, but wouldn’t mind some public shaming about why I can’t do this in the smartapp:

def keypadCommands = keypad?.supportedCommands
log.debug "keypadCommands: $keypadCommands"

The root problem is the smartapp can’t seem to call methods in the device. I can’t see how that’s possible.


#218

You need both a custom device type and a custom smartapp to make this work. By any chance did you paste one into the other’s template?


(Brian) #219

Definitely didn’t paste one into the other, I’m thankfully long past making that error.

This is deeper. And yes, I’m using a custom app and device type. I’m troubleshooting the install problems with the Smartapp. It has something to do with calling this devices commands from the Smartapp.


#220

If this is the problem where it doesn’t install from android but it does stall from iOS, isn’t that just an issue with the install? That there some corruption problem in the initial publish?


(Brian) #221

Sort of…

I don’t actually see how this could only be Android, and it would be helpful for someone in iOS land to confirm that they have successfully installed the recent version of the SmartApp specifically.

The devicetype works fine for me (Android), but the Smartapp errors on install. It is not related to the Android app errors that I’m familiar with, it’s something else.


(Ben Lebson) #222

@JDRoberts, @bridaus,

Maybe my experience with this issue will help. This is currently an issue with Android installs only. Multiple users have confirmed that they can install the SmartApp successfully using an iOS device, even some users who’s install failed initially using Android.

The root of the issue is that the Android App is not pulling the Device Type and Device Name correctly when assigning a keypad to be used in the SmartApp. Where it should be pulling a Device Type of ‘device.centraliteKeypad’ it’s pulling one just named ‘device’. Where is should be pulling the actual name of the device it’s pulling the device ID (used in the Device page URL). See below:

What it should be:

Name	Type			Value
keypad	device.centraliteKeypad	Centralite Keypad

What it is:

Name	Type	Value
keypad	device	46931c78-9bce-4b13-8416-c355c1d39346

ST is aware of this issue and have acknowledged that it’s on their side and that it’s being worked on but they have no timeline on a fix.

Hope this sheds some light.


(Brian) #223

@blebson, perfect summary, I should have read your previous posts closer, I rushed. I believe this explains the issue. Where did you find the Type/Value that you are pasting here?

Edit: Found it. Now I’m checking on work arounds. Weird that it’s Android only.


(Brian) #224

Now I’m trying to figure out where devices get their “type” set.


(Brian) #225

Fixed. Pull requests sent to @mitchp (totally assuming I know what I’m doing, otherwise just cut and paste my edits, first real pull request for me ever). I believe it will work for iOS too, since the fix is not device specific.

Here are the raw files for those who want to get it working on Android.

SmartApp: https://raw.githubusercontent.com/bridaus/SmartThingsPublic/patch-2/smartapps/mitchpond/3400-x-keypad-manager.src/3400-x-keypad-manager.groovy

Device Type: https://raw.githubusercontent.com/bridaus/SmartThingsPublic/patch-1/devicetypes/mitchpond/centralite-keypad.src/centralite-keypad.groovy

Edit: For those interested, I just added the lock codes capability to the device, and then used that for the input in the SmartApp. It appears the Android app doesn’t like “centralitekeypad”. To be honest I don’t either, because I can’t see where that value is set for that device. Lock code capability seems very reasonable for this device.


(Will) #226

Tested, seems to be working fine. I wanted to take the time to thank you for going where this man couldn’t go!


(Mitch Pond) #227

Interesting. I wonder why checking for the specific device breaks on Android.

This was done to ensure that only devices using my DTH would get picked up by the App, because things will break if someone was to try to use a door lock or some other lock code supporting device.

Has anyone submitted a ticket to support to correct this? Is this the issue that was referenced (and support is aware of) earlier in the thread? Edit: never mind. Saw the previous post by @blebson


(Brian) #228

Just edited my post with more specifics as you were posting. I will submit a ticket on this issue, I could see where selecting a different device could be a problem. I hope that users taking a device type and smartapp from the same place would use both together only, I also wonder if the keypad does truly have the capability “lock codes”, because it seems it does. If it does, then apps that leverage that capability will benefit from the device type update.

The problem is that the abstraction for this device may not be complete. There really isn’t a way to define new capabilities, and there isn’t a keypad capability yet.


(Will) #229

I have an open ticket for this issue, it referenced this forum and I’ve provided updates the entire time up to now (I haven’t replied with the fix yet).

Ticket #149608


(Brian) #230

Perfect, saved me time. Thanks!


#231

It’s pretty common for security key pads to be implemented as locks without locks for both zigbee and Z wave. A lot of the capabilities are the same as a lock’s keypad would be. Basically the keypad is viewed as a subset of the lock category.


(Mitch Pond) #232

Is the “Lock Codes” capability documented somewhere? If there’s a better way for me to be handling these codes that is supported by the platform, I’d much rather do it that way.

That’s the documented method for requiring only devices of a specific Device Type in an input field. It’s not a value that is set, but rather derived from the name of the Device Type