@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.
Now I’m trying to figure out where devices get their “type” set.
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.
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.
Tested, seems to be working fine. I wanted to take the time to thank you for going where this man couldn’t go!
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
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.
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
Perfect, saved me time. Thanks!
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.
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
I wish I knew, I don’t think so. I searched everywhere. Then I searched github for similar devices and happened to see one that used this capability. I was trying to find a different way to input the device as from @blebson posts I could see it wasn’t getting it properly. Go community!
I wonder if in the derivation of the device type, the object is being killed/changed in Android, and not iOS. That’s for someone better than me to figure out.
Edit: @mitchp, your SmartApp does look generic enough to apply to “things” with “lock codes” when I think about it. I could be wrong, but it seems like it could.
BTW, where is that documentation you are referencing, I couldn’t even find that either… sigh.
I wish the docs site was google searchable (using “site:” syntax). It would help.
Awesome! I’ll have to try this out once I get home from work. From there I’ll try to integrate it into the Lock Code Manager SmartApp in order to allow you to share codes with your Smart Locks!
It does call a few methods on the device that wouldn’t likely be part of another device, or would possibly generate a different behavior.
http://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html#input
It’s the second option in the table that defines the types of inputs.
Hopefully we do get some official support for this keypad as CentraLite did not reply to my request for additional/technical information 
I didn’t really expect a response, but it would have been nice…
Ok, I see where this is getting us there: “device.deviceTypeName Prompts for all devices of the specified type.”
But how do you explicitly know what “deviceTypeName” is? I’m questioning the thoroughness of the documentation in this specific area (not you, and not in general BTW, it’s pretty good documentation compared to what I have worked with at times).
That is a good question. I assumed that it had a similar syntax to the capabilities (“Lock Codes” becomes “capability.lockCodes”). I found a thread discussing it in the forums: Device preference
This should be included in the docs.
I think this post in that thread is the source of our angst…
It’s your device type, so no one else can select it.
Purely based on speculation, but I like to speculate, and I think I’m good at it… 
Edit: Maybe I’m not good at it because I forgot that iOS users could use the app… in any event, documenting this would sure be nice.
I suggest you guys take the capabilities discussion to the developers category on writing device types. Lots of people there have experience with these issues and may be able to help you further and at this level it’s getting kind of off topic for this thread. 
Yet it works for some… inconsistent behavior to say the least. The last post in that thread seems to indicate that you can do this with devices outside of your own namespace.
Agreed.