2 Zigbee keypads regularly going non-functional

Hi, I am having problems every couple of weeks with my Zigbee keypads (2x XHK1-UE) going non-functional. They are used to activate Zwave relays connected to electric strikers. These keypads and the Tradfri backbone supporting them are the only Zigbee devices I have.

Sometimes I am able to get them functional again by rebooting the hub. How can analyse further to determine what piece of the system is failing?

Potential additional questions depending on what the analysis shows:
Will I get better results switching to a Zwave Ring keypad to go with the Zwave relay?
Will I get better resutls switching to a Zigbee relay to go with the Zigbee keypad?

Any suggestions on a good way to reboot the hub on a schedule as a fallback?

Update: I should have said that I’ve been having Zigbee specific problems for the last couple of months. It was working better before that.

No to both because remember these devices “talk” through the hub, which then coordinates the messages between devices. There is no device to device communications with ST.

What do you mean by non-functional? Going offline?

1 Like

By “backbone” I’m assuming you are talking about a Zigbee Router device? In this case, the Keypads are Zigbee HA 1.2 and the Tradfri control outlet is not.

1 Like

I was hoping it might help to get all communication local even if it had to go through the hub. Being that I don’t know what the specific problem is I don’t know if it would help or is even possible.

Fundamentally, the keypad stops triggering the the striker. The usual cues when it is working is for the keypad to beep on each keypress, beep when a good code is entered, then the striker will buzz. I believe when the process is non-functional the keypad does not beep when a good code is entered.

And yes, sometimes some of the Zigbee devices go offline. I have device monitor setup to tell me when the keypads and Tradfri plugin outlets go offline. I have seen every permutation of online/offline and working/not working that I no longer see it as a reliable indicator. I very rarely have problems from 5 of 9 of the Zigbee devices, all 5 are Tradfri plugin. I see the most trouble from the keypads at the end of the line.

I should have said that I’ve been having Zigbee specific problems for the last couple of months. It was working better before that. I will update the OP.

Interesting! Do you know of zigbee devices that will relay better for me? I can compare that with replacing the keypads with Zwave.

Yes, I built a path from the keypad to the hub. Tradfri about every 20 ft from the front and back of the building and up the center to upper floors.

Trouble is that I don’t think Tradfri control outlets will serve as Zigbee Routers for the Keypads given they are a different Zigbee protocol version. @JDRoberts is this correct? This was not correct.

If this is the case it sounds like you are experiencing issues aside from just Zigbee communication. Would definitely be worth double-checking this.

1 Like

It shouldn’t matter in this case. Zigbee 3.0 devices can repeat for zigbee 3.0, zigbee ZHA 1.2 , or ZLL. The exception would be devices using the Green Power clusters, but that’s not involved in this setup.


While zigbee doesn’t provide the same level of backwards compatibility that Zwave does, ZHA 1.2, Zigbee 3.0, and ZLL all play pretty well together, although there may be a few features which are only available within the profile, like touchlink commissioning.

Anyway, the IKEA Tradfri plug-in pocketsockets are generally good signal repeaters for a smartthings setup. They can handle ZHA 1.2, most zigbee 3.0, or ZLL messages without any problems. :sunglasses:


Thanks JD. Agreed they’re one of my recommendations for Zigbee pocket outlets because of that…

Well if OP specifically built that chain to reach im assuming they’re all parent child to each other all the way to the keypad. So interrupted comms for any of the three devices exhibits as a failed keypad.

Id probably treat it as an interference issue?

1 Like

It sounds like the keypad may be falling asleep, something which can happen with battery powered devices.

@rboy Is an expert on keypads and may know if this is a common symptom with that device.


What DTH are you using for the keypad?

Also, what’s the brand and model of the Z wave strikers? There might be something you could do with Zwave direct association and a new zwave keypad, but as always, the first rule of home automation applies: “the model number matters.”

1 Like

It could be interference, definitely. Particularly if there’s a boosted Wi-Fi signal in the area that only gets heavily used some of the time, like when gaming or watching streaming video.

But that shouldn’t stop the keypad itself from beeping. That sounds more like either a defective device or the keypad falling asleep. That’s why I wondered if @rboy had heard of anything specifically about that model, I know he’s familiar with it.

And for those who like technical documentation, here’s some on zigbee interoperability:

Long story short: if you can add the Zigbee device to your smartthings zigbee network, it should be interoperable with the other zigbee devices on that network. That is it can send and receive messages, and if it is capable of repeating, it should be able to repeat the Zigbee messages for other devices on the network.

But there may be some devices, specifically those that require touchlink commissioning or that use the green power clusters, that will not be able to be added to the smartthings zigbee network. And again, those don’t apply in this specific situation.


Two (front and back) exterior doors use the same device chain of keypads, zigbee core, hub, Zwave relay. Alkaline Batteries.

I remembered that I could verify the route: This Device (752F) ↔ Keypad TRÅDFRI (1E08) ↔ Basement Front TRÅDFRI (644D) ↔ Basement Rear TRÅDFRI (DD7A) ↔ Hub

Keypad DTH: @RBoy Enhanced ZigBee Keypad Lock
Relay triggering the striker: FortrezZ MIMOlite
Relay DTH: FortrezZ MIMOlite

We have both powerful wifi and cordless phones. The wifi is used more often than the phones. Is there a way to tell if a device is experiencing interference? Through the IDE i’d imagine.

1 Like

I’m not sure if this is helpful to anyone.
Street keypad

  • Last Hop LQI: 80
  • Last Hop RSSI: -80
  • Received Messages From Device: 21
  • Received Messages From Device (Duplicates): 4
  • Messages Transmitted to Device: 21
  • Messages Transmitted to Device (Failures): 2
  • Updated Time: 2021-06-04 12:13 PM EDT

Back keypad:

  • Last Hop LQI: 48
  • Last Hop RSSI: -88
  • Received Messages From Device: 27
  • Received Messages From Device (Duplicates): 3
  • Messages Transmitted to Device: 33
  • Messages Transmitted to Device (Failures): 4
  • Updated Time: 2021-06-04 12:13 PM EDT

The RSSI Values in the IDE may help, but ultimately best way to check is to see what:

  • Zigbee Channel your Hub is using (IDE > My Hubs > Zigbee > Channel)
  • The 2.4Ghz Channel of your Router (Generally is Log into Router > Wireless > Channel in 2.4Ghz section)

You’ll want these two separated to minimize interference. More on that here: ZigBee and WiFi Coexistence — MetaGeek

The RSSI values you just posted definitely look pretty bad, to be honest. Either range, interference, or both could explain that.

1 Like

I use to have those too. Just out of curiosity, how many Zwave devices do you have? Also, have you done a Zwave repair lately? Are your issues timed with that?

Where I’m going with this is that when I use to have Mimolites they behaved badly in my environment when I went over around 25-30 Zwave devices. The Mimolites would also lock up every single time I did a Zwave repair. This didn’t happen with just 1 Mimolite, but all 3 that I had.

I went round and round with FortrezZ support, and that got me nowhere despite being able to reproduce the issue anytime I wanted by just running a zwave repair.

That, plus Zwave woes with ST back then (and maybe even now), got me to get rid of the Mimolites and purely focus on Zigbee.

It’s good to check for the interference, but again, interference isn’t going to cause the keypad itself not to beep. :thinking:

Agreed. :sunglasses:

Generally, anything -60 and above ( meaning -50, -40, etc.) would be considered a very strong signal. -75 is usually OK for zigbee home automation transmissions.

Anything at -80 and below ( meaning -85, -90, etc.) is mostly noise and you risk losing messages,

That said… It’s a little more complicated for these specific devices because they’re battery operated. If they go to sleep, the signal strength is usually reduced. So it depends on where you hit them during the sleep cycle.

I don’t know what scale smartthings uses to report at LQI. If it’s the 0 to 255 scale, then those LQI values are terrible. :disappointed_relieved:

If it’s a 0 to 100 scale, then they’re not good, but maybe not horrible, since message transmission failures are about 10% .

Do you know or can you find out how LQI is reported in the IDE?

i have several of the zigbee keypads and a bunch of the ring zwave keypads, both using @RBoy dths. plugin outlet router/repeaters help. let me tell you the zwave ring keypad work oh so much better. just remember to pair it using S2 QR pairing.

1 Like