Okay, yes possibly if it’s not synced. Once it is communicating you should get battery status.
Bring the keypad closer to the hub and remove / readd. After that, hit the configure button in the DH.
I checked mine and everything matches up except the serial of course and the number below it. Everything is exactly the same except the 2nd set of numbers, mine says 1008 032715 with the rest of the numbers matching. I’m not sure what that number is for but everything else matches.
@dross,
Here is the manual that may help
https://onedrive.live.com/redir?resid=586D1FA294807DA1!75035&authkey=!AJq87fyT1Xx4D0Y&ithint=file%2Cpdf
Thanks. I tried the reset.
Am I correct in thinking all I am meant to do is install the DH, install the SA, then reset the device, put the batteries in, search for a new device in the app, add the keypad - and then the keypad network light is meant to stay green?
I successfully add the device to my list of things but the light doesn’t go green. This is so painful!
In the IDE, when I install the device type and install it virtually in the IDE, I get the following error when I press the configure button:
16:14:17 BST: error java.lang.NumberFormatException: For input string: “vi” @ line 135
Could this be the issue?
In the live logs I get the following when i click on configure:
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug TEMP
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Device: read attribute response: catchall: 0104 0402 01 01 0140 00 A813 00 00 0000 01 01 00000029D708
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0104 0402 01 01 0140 00 A813 00 00 0000 01 01 00000029D708’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Received battery level report
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'read attr - raw: A8130100010A200000201D, dni: A813, endpoint: 01, cluster: 0001, size: 0A, attrId: 0020, result: success, encoding: 20, value: 1d’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0104 0001 01 01 0140 00 A813 00 00 0000 07 01 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0104 0001 01 01 0140 00 A813 00 00 0000 07 01 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0104 0402 01 01 0140 00 A813 00 00 0000 07 01 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0104 0402 01 01 0140 00 A813 00 00 0000 07 01 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1C 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1C 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1B 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1B 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1A 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 1A 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 19 00
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0000 8021 00 00 0040 00 A813 00 00 0000 00 19 00’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Unhandled profile-wide command: catchall: 0104 0500 01 01 0140 00 A813 00 00 0000 04 01 701000
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:06 BST: debug Parsing 'catchall: 0104 0500 01 01 0140 00 A813 00 00 0000 04 01 701000’
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:02 BST: trace Method: refresh(): [st rattr 0xA813 1 1 0x20, delay 100, st rattr 0xA813 1 0x402 0, delay 100, raw 0x501 {09 01 04 0000}, send 0xA813 1 1, delay 100]
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:02 BST: trace Method: sendStatusToDevice(): [raw 0x501 {09 01 04 0000}, send 0xA813 1 1, delay 100]
655786c0-6d3a-40eb-ad2a-9e472a1c57f9 16:21:02 BST: trace Arm mode: null
After messing around with this some more, if I take out the batteries and repair the device from scratch with my Hub then the device lights update (i.e. red when arrmed / green when unarmed). However, if I press any buttons on the device then this does not work again until I remove and repair the device. However, still no green network light - so the issue seems to be it is not properly pairing. Really odd, and frustrating!!
I wish I could help but I don’t know what is going on. It sounds similar to what @JH1 is having.
I am not a programmer so unless it’s something obvious in the logs I am lost 
It would have to be something for @mitchp to look at but since some peoples work fine an others don’t there has to be something slightly different with the keypads. I know @JDRoberts had wrote that Centralite does not sell directly to end users so each company they sell to can modify them to suit their systems even if it’s just a slight change. Is this the case…I don’t know.
I do know the new Iris brand keypad is due out soon and is Zigbee. ST said they are working on “official” integration with some of their devices so I don’t know if the keypad is one of them. At least with that keypad you know you will get the same keypad everytime so if they get one of them working all of them should work.
1 Like
@JH1: are you running this on hub v1 or v2? All of my development is being tested on v1. I don’t know that this would change anything, but I’m out of ideas as to why the same code would throw an exception for you with the same input, but not for me or others (this bug does not appear to be related to the physical device, but rather the code within the device type/smart app)…
As for the network light flashing: if it’s flashing rapidly, I believe it’s waiting for the enroll response. Try pressing the wall/tamper switch on the back of the keypad briefly as I believe this will cause it to send a new enroll request. That has usually worked for me.
Very interesting… I wonder if they are executing v2 stuff on a different version of the backend. Just speculation. I haven’t tried this on my v2 hub as I haven’t had the time to start my migration yet. I’ll have to pair this up to the v2 and test it out.
I am also on v2. Perhaps that is also the cause of my issue. I have tried pressing the wall switch etc. to no avail.
I am also on V2, but it worked just fine for me. I did have to replace the batteries. The batteries that came with it were enough to light the lights, keys, etc, but I could not get it to add. Once I put in one new battery, it added and has worked perfect ever since.
How strange! Was there any sign the batteries that came with the device were weak? My unit displays 88% so I wouldn’t think that would be the issue. I’ll buy new batteries tomorrow and re-add.
Also, is anyone else in the UK? Could the UK hubs process things differently?
I am on V2 and also had to replace the batteries, mine were totally dead
I’m not an expert but I did think UK used different frequencies that U.S.?
i think thats just for zwave, zigbee shoul be the same all over the world
Might have tried it already, but when you copy the code over from Github, did you use the Raw button? I know that sometimes copying it without using the Raw button can add or subtract characters and cause weird code errors that are difficult to diagnose/replicate.
groovy.lang.MissingMethodException: No signature of method: java.lang.String.acknowledgeArmRequest() is applicable for argument types: (java.lang.String) values: [0] @ line 105
Looks like the acknowledgeArmRequest doesn’t like getting a non-string value (0), not sure what it’s looking to get though, I’ll have to look into it later.
1 Like
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.
Not a big deal either way but it does happen.