Zigbee Keypads Partially Stopped Working as of May 7, 2019

Not really a quick fix as it would require a rewrite of all smart apps using the DTH. I would wait till ST staff completes the investigation as to the change in the event processing and if they can support processing the events the way it was done earlier. That would be more compatible and wouldn’t require any changes or fewer changes depending on their decision.

1 Like

You’re referring to the SendEvent and CreateEvent commands?

My keypads stoped working!!! I need keypad coordinator to control my outdoor gates! I have 3 of them!

If any other device handler & ST combo exist that can make this work…please let me know. I need to have a switch toggled when the correct code is entered


I noticed on your facebook page that you were able to fix this issue by updating your DTH. Could you possibly share what ST told you in regards to what they did in regards to the keypad update? The community would be very appreciative.



The fix only works for apps using capability events. ST hasn’t fixed it yet, they’re still looking into it.

The issue is that ST doesn’t process events the same way it used to before so the data event being reported by the older DTH is being ignored. The SmartApps that use the older DTH are being impacted by it; which is what I said above, there’s no “quick fix”, the old DTH and related apps would need to be modified/rewritten, so I’ve requested ST to relook at if the functionality can be restored.

The Enhanced ZigBee keypad DTH reports events for apps which consume the data events directly from the older DTH (like SHM delay etc) and also for apps that use events linked to capabilities (like LUM, RLA etc).

The patch released yesterday to the Enhanced Zigbee Keypad DTH was to report these events separately (the old DTH style and the capability based) so that atleast the capability based apps can continue working.

When these events are reported together, due to the platform change, the platform was ignoring ALL the events including the capability events.

It won’t fix the issue with the SmartApps using the older DTH events. That can only be fixed by ST by accepting the older DTH style data events (or modifying the original DTH and all related SmartApps). Once they patch it, both the old and Enhanced DTH events will start working with SHM Delay etc.


Thank for the detailed explanation. I wish ST would post these details instead of us having to rely on you.



Mine stopped working yesterday.

It appears to be connected, but the Keypad (3405-L) will not change the alarm status.
The 3 Mode Buttons on the Bottom of the Keypad just flash back and forth like a Railroad Crossing.

  1. If you wave your hand in front of the Keypad Motion Detector, while watching the Keypad in the APP, it will show Motion Detected.

  2. in reverse, in the APP inside the Keypad Functions, if you press the Speaker Icon, the Keypad will Beep.

  3. In the APP, if you change the Alarm Status Mode from Home to Partial/Night, and wave your hand in front of the Keypad, it will show RED on top and the Bottom Button on Partial.

  4. This also works in reverse, use the APP to Activate Home/Off, then wave your hand in front of the Keypad, it will show GREEN on top and the Bottom Button on now on OFF.

In short… the System Hub will update the Alarm Status on the Keypad, BUT… the Keypad will NOT change any Alarm Status. On the Keypad, if you press the Partial Button, it beeps different, and then the 3 Mode Buttons on the Bottom of the Keypad just flash back and forth like a Railroad Crossing.

I Tried Removing the Keypad Device, Rebooting the Hub, then Reinstalling it (4 times now), with no results. I also tried to update all Device Handlers and/or Smart Apps, also with no improvement.

Further, I also had a brand new unused Keypad which I installed as a New Device, with all the same results.

Now I’m to the conclusion Samsung changed something last night.

The “codeEntered” event is no longer work.

For all SHM Delay users using Mitch Ponds DTH. There is a mandatory update that reinstates normal keypad operations.

Anyone using Rboy’s DTH with SHM Delay should expect a DTH update from Rboy, but must install the updated SHM Delay module V2.2.9 at the same time.

Link to mandatory SHM Delay update notice follows

1 Like

I switcher over to the new DTH from @RBoy (thanks for the help) and everything is working again. Keypad operations feels faster as well.

1 Like

For the record the issue was having a data field that was not in a map format.

This fails:

createEvent(name: "codeEntered", value: keyCode, data:  armMode as String, 
	isStateChange: true, displayed: false)

This works:

createEvent(name: "codeEntered", value: keyCode, data: [armMode: armMode as String], 
	isStateChange: true, displayed: false)

On receiving side the data info becomes JSON formatted data

log.debug "buttonHandler $evt value: $evt.value data: $evt.data"
def datacodes = new groovy.json.JsonSlurper().parseText(evt.data)
log.debug datacodes.armMode

Results in the following
7:12:57 AM: debug 0
7:12:57 AM: debug buttonHandler value: 0000 data: {“armMode”:“0”}

What occurred is ST no longer accepts createEvent and sendEvent commands that have data fields not formatted as Map data. To make matters worse, it’s done silently without throwing an error.

The createEvent documentation

1 Like

They may be doing that, but it appears they were simply doing more and better editing on some data fields for createEvent, sendEvent, and possibly other commands. The main downside is they did not tell this to anyone, nor did they bother to throw an error when bad data was found, it’s much easier to simply ignore the command. Idiots!

My system is now functioning as it was before this all began. However, that’s only until I complete porting a few more devices, mainly keypads, to Hubitat.

1 Like

Arn: could you please explain how to find, install and publish those two modules. Thanks for the help.

The linked release notice has the information you need. Should you not be using the IDE’s github facility, the release notice includes links to the raw files for manual update

1 Like

We’ve disabled the change that caused the Keypads to stop working and will investigate better error handling options to prevent it from happening again. That being said it would be a good idea to update to the latest code that @arnb posted.


Arn: I have updated the device handler for the keypad via the raw files for manual update that you provided, but my IRIS keypad V2 is still not working properly. I do not use SHM Delay APP because I do not use the delay function when arming / disarming using the keypad. There is no need to have delay as my keypad is in the garage. I only use the device handler and ethrayer’s Lock Manager for User PIN.

I tried, deleting the Keypad from the Smart App and re-pairing the keypad, as well. I also deleted the original Mitchpond Device Handler and added the updated file for the keypad device handler, too. I am not sure what I am doing wrong. I have no trouble arming / disarming using the Smarthing APP on my phone but the keypad is to no avail.

This is the link file that I used for the keypad device handler:


Can you please provide some guidance? Thank you!

  1. Provide warning to the community a few weeks in advance of the change.
  2. Modify the Save, compile phase to throw an error when the data appears wrong
  3. Throw an error when an error is caught, rather that tossing the command into the ozone

Regarding the code reversion: Perhaps it will help some, and confuse others, who knows. Those of us who were severely impacted have moved on.

The updated DTH is not compatable with ethayer’s Lock Manager, or an any version of SHM Delay before v2.2.9. Either move on to use the SHM Delay or reinstall Mitch Pond’s DTH.


1 Like

Hi ,

I’m facing same issue. The keypad just doesnt respond to codes. I reinstalled Mitch Pond’s DTH, but still nothing. Nothing happens when you key in any code Any help ?