Same frequency, but the power of zigbee devices in the US is often boosted to almost twice that of the UK. (The EU has ceiling regulations which are much lower than those in the US.)
This is the reason why many devices made in the US cannot be sent to the UK, they would not be Legal to operate there.
So I would guess that the power output of the zigbee signal from the UK hub is lower than that of the US hub, which could cause some pairing issues at a distance but not if you were very close.
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.
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