It looks no status change commands are working with the keypad. It looks like it’s throwing the error when it’s trying to update it’s state as well even though there are no commands passed through.
groovy.lang.MissingMethodException: No signature of method: java.lang.String.setArmedStay() is applicable for argument types: () values: @ line 76
Raw description is 01 0104 0401 00 07 0000 0001 0003 0020 0402 0500 0B05 02 0019 0501
Not sure if that will help at all… I’ve never dealt with a Zigbee device before so I’m really useless at this point. It’s a whole lot different than IP connected devices.
This is probably too obvious, but many times new devices required installing two separate pieces of code: a “device type handler” (or just “device type”) and a smartapp.
You do both in the IDE, but you go through a slightly different process for them.
The custom code FAQ covers how to do each kind. So it never hurts to go back and make sure that if, as in this case, there are two separate pieces of code required, that you did install each one following the two separate publication protocols.
I think pretty much everybody in the community at some point has copied in one, and then accidentally copied the same one into the other section as well. So it never hurts to check.
(The following is a clickable link)
In this particular case, the device type handler is the “centralite-keypad.groovy” and the smartapp is the “3400-X-keypad-manager.groovy” Links to both are in the first post of this thread.
You need both of those copied into your account to try using the keypad with smartthings, but again they have two different publication procedures.
Thanks @JDRoberts, I was more referring to debugging this error. Because I don’t have any clue how zigbee device handlers work I can’t figure out why it’s throwing errors when trying to set the status of the keypad.
Ok, this is really odd. It’s not being passed any parameters nor should it be expecting any. Either something isn’t copying correctly from Github or there are some shenanigans going on in the back end. Here’s what I get when changing SHM status:
Good call. it is possible. I had read in this post that other had to replace their batteries as well. Since this was “used” item from the same seller I went the route of changing the batteries. In my case I had removed the original batteries and reinserted them after a few minutes of being removed and even though the keypad lit and some of the lights were flashing it did not connect. Added new(ish) batteries and it added right away. I do find that odd, as well. Maybe it did not have quite enough power to fully connect?
[quote=“swindmiller, post:4, topic:25473”]
I did find one bug that it does not like zeros as the first digits of the code.
[/quote]This has been corrected in the latest commit. The UI will not show leading zeroes if you don’t type them in, however.
edit: I have also reached out to CentraLite to see if they would be kind enough to provide any sort of technical documentation
The only thing that I can think of is that maybe the app is not linked to a valid instance of the device type code. When you go to https://graph.api.smartthings.com/location/installedSmartApps/ and look at the entry for the keypad manager, what does it list in settings for the keypad entry?
It should look similar to: Name Type Value
keypad device.centraliteKeypad Centralite Keypad
That looks like the keypad has not been assigned the correct device type. It’s throwing exceptions because the methods it’s trying to call don’t exist. I guess the first step is to just verify that the device has been assigned the correct type. The app should not even allow the selection of devices that don’t match “device.centraliteKeypad”
Name Centralite Keypad
Label Front Door Keypad
Type Centralite Keypad
Version Published
Zigbee Id 000D6F00055E5356
Device Network Id DD56
Status INACTIVE
Hub Home Hub
Group Entryway
Last Activity At 2015-10-20 9:39 AM PDT
Date Created 2015-10-19 8:04 AM PDT
Last Updated 2015-10-19 11:04 PM PDT
Data No data found for device
Raw Description 01 0104 0401 00 07 0000 0001 0003 0020 0402 0500 0B05 02 0019 0501
Current States
temperature: 79
battery: 88
Events List Events
In Use By
3400-X Keypad Manager
You shouldn’t have to factory reset to get the platform to use the correct code. This seems like more of a cloud hiccup than something to do with the physical device. I know you’ve probably been through this, but I would delete the device and app, grab the latest code from Github (updated today), save and publish, then factory reset the keypad and re-add.
If that does not work, then I am out of ideas. Might need to ping support and see if they can tell why the device type doesn’t seem to be associated with the device correctly.
I guess a good question to ask is how exactly is the device type assigned? Is it supposed to be automatic once you assign it a devicetype or is it something that needs to be registered with the hub?