Yeah, that’s how it looks. I was under the impression that typing was optional in Groovy in cases such as this. It’s weird that it doesn’t like it on some installs but is perfectly happy with it on others. It’s not consistent behavior. I’ll have to redo that using explicit variable types and see if that solves it.
Sometimes this isn’t because the original battery was bad, but probably just as often it means the device wasn’t awake during the previous configure And the process of taking the battery out and replacing it caused it to wake up long enough to then catch the configure the next time. So you likely would get the same result if you would just replaced the original battery again.
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
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
Zigbee Id 000D6F00055E5356
Device Network Id DD56
Hub Home Hub
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
Events List Events
In Use By
3400-X Keypad Manager