[Device Support Request] Xfinity XHK1-UE Keypad

[master4g]

Is your feature request related to a problem? Please describe.
I have ZHA hooked up to a Sonoff Zigbee Bridge. I am unable to find my my Xfinity keypad when trying to add a device

Describe the solution you'd like
I would love for ZHA to support this keypad like Zigbee2Mqtt does.

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
The Device doesn't appear when trying to add it. I put the keypad into pairing mode, and I put ZHA into search mode but no connection was made.

Additional context
I found information about this device on this link:
https://old.reddit.com/r/homeassistant/comments/k1hg4w/physical_zigbee_alarm_keypad_integrated_into_home/
The poster mentioned what he did to get it to work with Zigbee2MQTT

Thanks.

[dmulcahey]

Keypads (IAS ACE) devices aren't supported by ZHA in HA yet. I am working on support for them but I haven't spent much time on it lately. I'll try to pick this back up soon.

[peng1can]

I have a variety of Iris zigbee keypads (Centralite, Iris, and Xfinity keypads are supposedly all the same basic hardware), and I'd be happy to pull whatever info is needed to get support for these added at the same time. If there is somewhere else that makes more sense for me to "follow," please let me know, and I'll gather whatever info will help.

As a side note, for my use case, the chime, alarm, and panic buttons are actually more useful than the keypad itself.

[prigal]

Hello, love to see this coming to ZHA too :)

[Hedda]

FYI, looks like dmulcahey is working on alarm control panel support to ZHA for Home Assistant core -> home-assistant/core#49080

dmulcahey development branch for it is found here -> https://github.com/dmulcahey/home-assistant/tree/dm/zha-ias-ace-support

( Comments if testing that branch before the PR is merged into HA should go into the pull request -> home-assistant/core#49080 )

Btw, see zha-device-handlers discussion about Centralite 3400-G which is a similar or even the same rebranded keypad -> #838

Also see the discussion about Centralite 3405-L / Lowes Iris Keypad V2 which too is similar to it as well -> #87

PS: There is also a broader zigpy discussion about Zigbee IAS and ACE (for "Alarm Control Panel" support) here -> zigpy/zigpy#419

[master4g]

FYI, looks like dmulcahey is working on alarm control panel support to ZHA for Home Assistant core -> home-assistant/core#49080

Btw, see zha-device-handlers discussion about Centralite 3400-G which is a similar or even the same rebranded keypad -> #838

Also see the discussion about Centralite 3405-L / Lowes Iris Keypad V2 which too is similar to it as well -> #87

PS: There is also a broader zigpy discussion about Zigbee IAS and ACE (for "Alarm Control Panel" support) here -> zigpy/zigpy#419

Thanks a lot. Unfortunately, I'm not too familiar with decoding what is going on at the link you provided. Does this mean its already working at the moment, or might work soon? Thanks

[Hedda]

I'm not too familiar with decoding what is going on at the link you provided. Does this mean its already working at the moment, or might work soon?

It is not working yet but when the pull request home-assistant/core#49080 gets merged (if it is merged) into Home Assistant core then the next release after that will have initial support in ZHA for generic Zigbee alarm control panel keypads. However, that in turn does not mean that all Zigbee alarm control panel keypads (Zigbee IAS ACE devices) will fully work from day-1 and there is where zha-device-handlers quirks comes in to the picture as some individual models might still need custom tweaks to fully work.

[Hedda]

FYI; Home Assistant 2021.5 (planned for release May 5, 2021) Beta release notes: "ZHA now has support for alarm control panels".

https://rc.home-assistant.io/blog/2021/04/28/release-20215/ -> home-assistant/core#49080

[master4g]

FYI; Home Assistant 2021.5 (planned for release May 5, 2021) Beta release notes: "ZHA now has support for alarm control panels".

https://rc.home-assistant.io/blog/2021/04/28/release-20215/ -> home-assistant/core#49080

Nice! Looking forward to it. Thanks for the notice.

[aleck011mi]

Looks like this from my notes would help OP pair his keypad with ZHA:

To reset Xfinity keypads do the following:

1. Remove the cover and batteries
2. While keeping the tamper/pairing button pressed, insert batteries and then release the tamper/pairing button
3. It should make the pairing LED start flashing
4. Press the tamper/pairing button 5 times to reset keypad.

To pair it after resetting it, you need to remove the batteries again and then just reinstall. The green light by the tamper/pairing button should start flashing indicating it is ready to pair.

[thecobra666]

Is there a way to delay the arming?

[Hedda]

Is there a way to delay the arming?

Feature request for ZHA as a 30-second delay before arming is probably wanted by default on all alarm control panels as standard?

I understand that the industry standard on the commercial security alarm system is to beep for 30-seconds to warn before arming?

https://github.com/home-assistant/architecture/discussions

https://community.home-assistant.io/c/feature-requests/

Looks as if Home Assistant manual alarm control panel platform delay_time integer is optional and defaults to 60 seconds if set:

https://www.home-assistant.io/integrations/alarm_control_panel/

https://www.home-assistant.io/integrations/manual

https://www.home-assistant.io/integrations/alarm_control_panel.template/

[t0ny-peng]

@Hedda I'm having a pretty hacky automation to use this keypad as an extension of the builtin manual alarm control panel.

When you press a mode on the keypad and enter 4 digits, a message will be published to MQTT

{"action":"arm_day_zones","action_code":"1234","action_zone":23,"battery":100,"battery_low":null,"contact":null,"linkquality":78,"occupancy":true,"presence":null,"tamper":null,"temperature":25,"voltage":5800}

This could be used as the trigger of entering the arm mode of HA alarm(though you need a mapping between the Xfinity arm mode and HA arm home, e.g., arm_day_zones => arm_home).
When the HA alarm entered the arm mode, you can then send a confirming message to MQTT topic zigbee2mqtt/[DEVICE_FRIENDLY_NAME/set with this payload to inform the keypad that the the alarm mode has entered.

{
    "arm_mode": {
    "transaction": 99, // Transaction number (take this value from the (dis)arm attempt property `action_transaction`)
    "mode": "arm_all_zones" // Mode "arm_all_zones", "disarm" or "exit_delay" (take this value from the (dis)arm attempt property `action`)
    }
}

Though I don't know what the transaction mean, it seems to decide if a chime will be played.

Similarly, while the alarm is armed, entering 4 digits will trigger an MQTT message and you can use it as the automation trigger in HA to disarm the alarm. If the passcode entered is wrong, you can trigger the HA manual alarm and do whatever fancy alarm you want.

[thecobra666]

@Hedda I'm having a pretty hacky automation to use this keypad as an extension of the builtin manual alarm control panel.

When you press a mode on the keypad and enter 4 digits, a message will be published to MQTT

{"action":"arm_day_zones","action_code":"1234","action_zone":23,"battery":100,"battery_low":null,"contact":null,"linkquality":78,"occupancy":true,"presence":null,"tamper":null,"temperature":25,"voltage":5800}

This could be used as the trigger of entering the arm mode of HA alarm(though you need a mapping between the Xfinity arm mode and HA arm home, e.g., arm_day_zones => arm_home).
When the HA alarm entered the arm mode, you can then send a confirming message to MQTT topic zigbee2mqtt/[DEVICE_FRIENDLY_NAME/set with this payload to inform the keypad that the the alarm mode has entered.

{
    "arm_mode": {
    "transaction": 99, // Transaction number (take this value from the (dis)arm attempt property `action_transaction`)
    "mode": "arm_all_zones" // Mode "arm_all_zones", "disarm" or "exit_delay" (take this value from the (dis)arm attempt property `action`)
    }
}

Though I don't know what the transaction mean, it seems to decide if a chime will be played.

Similarly, while the alarm is armed, entering 4 digits will trigger an MQTT message and you can use it as the automation trigger in HA to disarm the alarm. If the passcode entered is wrong, you can trigger the HA manual alarm and do whatever fancy alarm you want.

Jup I'm doing the same. Altough I moved from zha to z2m. In zha when pressing one of the zone buttons they stay lit when entering the code to arm. In z2m this doesn't happen. You wouldn't know how they do that in zha?

[t0ny-peng]

@thecobra666 No I haven't used this keypad with ZHA as I knew certain features are missing. Btw do you know the meaning of transaction in the message? According to the official page it should be something like an action identifier, but I don't see it in the MQTT box I received. Btw I'm using Zigbee2Mqtt as HA addon.

[thecobra666]

Normally the transaction is to confirm the "ask to arm" back to the keypad to set it to the required arm status. You select the zone, enter the code. That mqtt message should have the transaction ID in it. (It doesn't). Then you have to send that ID back to the keypad and the selected arm zone. Then the keypad should be armed. If I do not send the transaction ID at all, it doesn't work. So I just send 99. Would you know how to stop the keypad from beeping after using the entry or exit delay? The only way I'm able to do this is using the disarm action. That only works for the entry delay of course.

[t0ny-peng]

@thecobra666 You can set the alarm in in_alarm mode. Of course before that you have to use either arming_stay, arming_night or arming_away.

I still can't see transaction id in the reply, and I also plan to send an arbitrary value 99.

Another question is that I don't understand the different between arm_day_zones and arming_stay then in_alarm. They both seem to achieve the same state.

[thecobra666]

@thecobra666 You can set the alarm in in_alarm mode. Of course before that you have to use either arming_stay, arming_night or arming_away.

I still can't see transaction id in the reply, and I also plan to send an arbitrary value 99.

Another question is that I don't understand the different between arm_day_zones and arming_stay then in_alarm. They both seem to achieve the same state.

Yes I know but what I was saving is that in z2m when pressing the zone button, no mqtt message with that zone is send. That only happens when the code is entered. In zha they light up the zone which was pressed before the code gets entered.

I would like to know how they intercept that.

[mrmichaelrb]

I recently acquired a small lot of the Xfinity XHK1-UE keypads on eBay, and I have a few more than I need. I've tried to use them with ZHA, but it has become apparent to me that there are still a few quirks (pun intended) to be ironed out before these keypads are useful.

I'd be more than willing to donate a free keypad to anyone who can get these working. Just send me an email (see my profile) with your address, and I'll mail a free keypad to you. However, don't bother asking for one unless you are already experienced with Zigbee/zigpy/ZHA and can contribute a usable change to the codebase.

Currently, I cannot get arming and disarming to work from the physical keypad (only the UI card). And the battery percentage is "unknown". And, there's a binary sensor that I assumed was the tamper button, but it always remains "off" even if I push the tamper button. So, the only thing that works is the temperature sensor.

[normanr]

Note that when you set arm_mode with transaction, that is treated as a reply to the code entered, and triggers the "chime". You then need to set arm_mode again without a transaction, this changes the state of the lights to whatever you send.

For requests like arm_all_zones, I think you set with transaction and mode arm_all_zones, then set without transaction and mode exit_delay, then 30 seconds later set mode arm_all_zones (without transaction). I'm not sure where arming_away fits in.

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.