CentraLite Keypads

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” :sunglasses: 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:

5c2f32f9-63e1-4a8d-b8e2-174c945c434b 8:18:23 AM: debug Parsing 'catchall: 0104 0402 01 01 0140 00 FAFE 00 00 0000 01 01 00000029D806' fe38346f-870d-4c75-b7d5-8c683b4b642b 8:18:17 AM: debug Keypad manager caught alarm status change: stay 5c2f32f9-63e1-4a8d-b8e2-174c945c434b 8:18:18 AM: trace Method: refresh(): [st rattr 0xFAFE 1 1 0x20, delay 100, st rattr 0xFAFE 1 0x402 0, delay 100, raw 0x501 {09 01 04 0100}, send 0xFAFE 1 1, delay 100] 5c2f32f9-63e1-4a8d-b8e2-174c945c434b 8:18:18 AM: trace Method: sendStatusToDevice(): [raw 0x501 {09 01 04 0100}, send 0xFAFE 1 1, delay 100] 5c2f32f9-63e1-4a8d-b8e2-174c945c434b 8:18:18 AM: trace Arm mode: armedStay 5c2f32f9-63e1-4a8d-b8e2-174c945c434b 8:18:18 AM: debug Sending status to device... 0be312fd-2871-43b0-b1fd-f543affaca15 8:18:17 AM: debug Armed/stay -> physicalgraph.app.EventWrapper@5df4c089 - away
No exceptions.

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?

1 Like

[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

1 Like

This is from the log when I try to arm:

0bda5e9c-b03a-4867-8ae5-5be9d85e6d42  9:39:35 AM: error groovy.lang.MissingMethodException: No signature of method: java.lang.String.acknowledgeArmRequest() is applicable for argument types: (java.lang.String) values: [1] @ line 106
0bda5e9c-b03a-4867-8ae5-5be9d85e6d42  9:39:35 AM: debug Correct PIN entered. Change SHM state to stay
0bda5e9c-b03a-4867-8ae5-5be9d85e6d42  9:39:35 AM: debug Caught code entry event! XXXX
46931c78-9bce-4b13-8416-c355c1d39346  9:39:34 AM: trace [name:codeEntered, value:XXXX, data:1, isStateChange:true, displayed:false, linkText:Front Door Keypad, descriptionText:Front Door Keypad code entered is XXXX]
46931c78-9bce-4b13-8416-c355c1d39346  9:39:34 AM: trace Method: handleArmRequest(message): [name:codeEntered, value:XXXX, data:1, isStateChange:true, displayed:false, linkText:Front Door Keypad, descriptionText:Front Door Keypad code entered is XXXX]
46931c78-9bce-4b13-8416-c355c1d39346  9:39:34 AM: debug Received arm command with keycode/armMode: XXXX/1
46931c78-9bce-4b13-8416-c355c1d39346  9:39:34 AM: debug Parsing 'catchall: 0104 0501 01 01 0140 00 DD56 01 00 0000 00 00 01043735333100'

And this is the log from when it sees changes in SHM mode:

0bda5e9c-b03a-4867-8ae5-5be9d85e6d42  9:41:42 AM: error groovy.lang.MissingMethodException: No signature of method: java.lang.String.setArmedStay() is applicable for argument types: () values: [] @ line 76
0bda5e9c-b03a-4867-8ae5-5be9d85e6d42  9:41:42 AM: debug Keypad manager caught alarm status change: stay

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

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

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

This is how it’s set up per IDE.

Is “46931c78-9bce-4b13-8416-c355c1d39346” the id for the device in the Devices page (it’ll be the last part of the URL)

Yes, it’s 46931c78-9bce-4b13-8416-c355c1d39346

Anyone else who has this working: what does the keypad settings line say in your SmartApp (in the IDE)?

If it doesn’t list the type as device.centraliteKeypad, then it’s likely that something went wrong during install.

1 Like

Mine works and:

   Name 	Type                      	Value
    keypad 	device.centraliteKeypad 	Centralite Keypad

Is there any way to ensure you install the device correctly or do you have to keep factory resetting and trying again until it shows the correct Type?

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.

Thanks for the help, I’ll give it a shot tonight when I get home from work.

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?