Pin Arming and Panic keys do nothing on Iris V2 and Centralite V2 keypads, temperature works, output commands such as beep and panic siren work. No code changes, no errors in log, no input messages show in log,pulling device batteries and rebooting hub did not change anything. Started sometime after 1AM EDT on May 7, 2019
Anyone else experiencing this issue?
I just tried to “arm/stay” on the UEI and am seeing the same thing as you.
Everything else seems to be working, temp, motion, etc., and the keypad responded to the disarm request sent by the “I’m home” routine when we got home an hour or so ago but it does not seem to respond to any keypad pin requests.
I don’t have panic set up to test it.
Which device handler are you using?
Maybe @tpmanley knows of any cloud side changes that may have affected this.
I see it and it appears to be a change with the platform, they seem to be processing events differently. Checking with the ST team
Maybe they’re preparing to release a stock DTH for the iris keypad and changed some stuff in preparation for that.
Or maybe they’re just getting ready for this:
Technically the original Mitch Pond DTH wasn’t exactly compliant with the ST standard in the way it was sending some events. I think ST made a change and it’s processing it more strictly now and so is rejecting it. So it’s really a bug in the original DTH but ST was a little lax in allowing it.
Discussing the options with the ST staff
Hello RBoy
Is there anything that can be done as a quick workaround or fix to get this working?
Tag: @mitchp
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.
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).
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.
Yes.
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.
If you wave your hand in front of the Keypad Motion Detector, while watching the Keypad in the APP, it will show Motion Detected.
in reverse, in the APP inside the Keypad Functions, if you press the Speaker Icon, the Keypad will Beep.
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.
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
I switcher over to the new DTH from @RBoy (thanks for the help) and everything is working again. Keypad operations feels faster as well.
For the record the issue was having a data field that was not in a map format.
This fails:
In DTH
createEvent(name: "codeEntered", value: keyCode, data: armMode as String,
isStateChange: true, displayed: false)
This works:
In DTH
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
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.
