Centralite 3400 keypad

[BusinessClaes]

Hello everyone

I just got myself one Centralite 3400-G keypad (3rd-gen) and I am trying to get it working with HA. I write this post to keep track of my own thougths and hopefully get some help

I believe the G-version is pretty much the same as previous models (3400 and 3400-D) just with the double-key panic function instead of unsused A and B keys.

The keypad has paired well with ZHA but now the situation is as follows:

• No zha_event whatsoever, either when dialing arm/disarm code, activating proximity sensor or press&hold panic keys
• Battery entity doesn’t get any readings
• Binary sensor IAS_zone is allways off (not sure what this sensor is supposed to represent)
• Temperature entity seems to work well

Note - I use a tasmotized SONOFF ZBBridge as Zigbee coordinator

What I have managed so far:

1. When I activate tasmotas T2Z on the ZBBridge (module 75 instead os module 0) I get beautiful mqtt messages
   1.1 Arm/disarm codes
   1.2 Battery levels
   1.3 Proximity sensor trigger
2. Zigbee2mqtt seems to support the keypad, although I don’t have the required hardware to test it. Maybe there is a way to translate Z2Ms converter into the corresponding ZHA device handler but I am still trying to digest all the instructions for ZHAs device handlers…
3. I contacted Centralites support and they were kind enough to provide me with a list of clusters and attributes/commands for the keypad. Sadly no information about payloads/args to be sent with the commands.
   3.1 All the clusters in Centralites file seem to match with what ZHA discovers and configures. There seems on the other hand to be some mismatches when coming down to commands/attributes
4. I am trying three approaches for sending commands to the keypad. Sadly I don’t succeed in changing the keypad arm mode with any of them
   4.1 From ZBBridges console (with module 75 activated) and using ZbSend command
   4.2 From HA device page “manage cluster” option
   4.3 With node-red, zha.issue_zigbee_cluster_command

What I hope to get done:

• Get zha_events with the same messages that T2Z manages to capture
• Be able to send commands to the keypad to acknowledge arm/disarm codes and to change panel status in case of arming/disarming directly in HA

Does anyone have any suggestions?
Maybe someone is already using the keypad and have already managed to do all this?

[BusinessClaes]

@BusinessClaes

I contacted Centralites support and they were kind enough to provide me with a list of clusters and attributes/commands for the keypad. Sadly no information about payloads/args to be sent with the commands.

Just realized that Centralites support just gave me a link to the keypads Compliance Document at zigbeealliance.org and I felt so special, I thought I was provided with some secret information…

Anyway, now I know that, AND that all the information about clusters, commands and payloads/args are supposed to be used (as long as the manufacturer of the device doesn’t deviate from the standard) is in the ZigBee Cluster Library Specification.

So now I did myself some reading and I have managed to use zha.issue_zigbee_cluster_command and node-red call service nodes to successfully send following commands to the keypad!

• Make the keypad “beep-once” with hi-pitch or low-pitch (to indicate correct or wrong code)
• Change keypad status to Disarmed, Armed Home, Armed Night or Armed Away
• Start a beeping loop (to use as “countdown before arming” or “waiting for disarm code”
• Put the Armed Home/Night/Away keys into flashing red (to be used in combination with beeping loop to indicate “countdown before arming”). I’m not completely satisfied with the keypads behaviour, it goes to sleep after a couple of seconds, comes back still flashing if I wave my hand for the proximity sensor. I want it to be awake all the time during countdown. Maybe there is a command to keep the lights on?

Beep-once uses ArmResponse command, the other commands are with PanelStatusChanged.

Now I just have to manage to get ZHA to catch the messages from the keypad and start giving me zha_events.

Does anyone know if there is a way of listening to the “raw data” previous to zha_event? I guess it is described in the instructions for ZHA device handler but I wonder if there is some shortcut

[snel6424 (Colton S.)]

Looks great so far! Have you made any more progress?

[Shibboleth]

FYI, discussion is ongoing over here on the zigpy / zha device handlers github.

And here’s the history of the fabulous work done by dmulcahey on the pull request

[Hans_van_der_Drift]

I just purchased some of these. Are you able to shared your node-red flows please?

It looks like you have achieved all that I’m trying to do.

[BusinessClaes]

That will be my pleasure! I am on vacation now so I will not be at home for a couple of days though. Hopefully I’ll put the flows here some day next week.

On the other hand there’s been a great step forward since alarm panels have been integrated in HA, so I hope to be able to manage my alarm panels that way soon, instead of sending raw cluster commands.

[Hans_van_der_Drift]

In my investigations I found that node red’s new node ‘Device’ can send and receive most of these commands without any cluster or call service nodes.

[SamJWard (Sam Ward)]

Has anyone been able to get these keypad’s to work?

I have my sync’d with Alarmo and the keypad is able to arm and disarm alarmo, but the keypad never shows it’s armed when it is indeed armed. It always shows the green lights" and none of the armed modes are red either.

Anyone know what I’m doing wrong?

I have it paired with Zigbee2mqtt.

[Journeymnn (Michael)]

I have great synchronization with this clever automation.

Automation to syncronize a Zigbee Xfinity Keypad/PIN Pad (ZHA) and Alarmo

Hi all, I bought a used Zibee Xfinity Keypad/PIN Pad and wanted to use it with Alarmo. I found a few solutions when you are using Zigbee2MQTT but I use ZHA, so I wrote an automation that would sync the Keypad and Alarmo using Alarmo built-in MQTT capabilities. Pre-requisites: Alarmo Custom Integrations installed and configured: MQTT Enabled and configured to require a code Armed away, Armed home, and Armed night Modes configured A Pincode configured Mosquito broker installed and configure…

[GLehnhoff (Gerhard Lehnhoff)]

Centralite 3400-D works with ZHA.

I can confirm that my Centralite 3400-D security keypad now (12 July 2023) works with ZHA. I could not get it to work with Zigbee2MQTT.

During pairing I was asked for the PIN. The keypad returns armed_home, armed_away and disarmed. It has the correct color and beeps correctly after arming/disarming and wrong PIN.

There are only a few entities available:

• alarmcontrolpanel → returns the status of the alarm panel (armed_home, armed_away, and disarmed),
• iaszone → seems to be off all the time (I don’t know what this is for),
• temperature.

There are two more entities, but they are not available:

• identify,
• battery.

As I only use the alarm control panel and the device shows the correct colors and beeps, I consider the unit to be working. As I was unable to pair the unit weeks ago, someone seems to be working with it and other entities such as battery may work in the future.

Side notes:

1. PIN: The PIN is entered in ZHA → Integration Entries (this is my USB ZigBee Antenna) → Configuration (translated from German language)
   

   

2. Colors: The unit shows when the alarm is armed or disarmed. If it is armed, it is not able to show if it is armed_away or armed_home. It always shows armed_home.

3. Integration: While I was integrating the device, ZHA said that the integration failed. However, it works fine. However, it may still be in a beta state and behavior may change.

4. Alarm system status changed from another device: If the status of the alarm system has been changed from somewhere else, e.g. another device, the keypad does not know. In this case a message must be sent to the device. This can be done via the service (for example: alarm_arm_home) to the alarm_control_panel. The PIN code has to be transferred, too. In Node-RED this looks like:
   

   

I call this service not only when the alarm status changes, but also when it is arming (hence, the one minute or so until the system is armed). Programming Node-Red is that easy (sorry it’s not in English and you can only see the flow, not the details):

5. Count down beep when arming: I could not set this.

6. The control panel in HA has four states (armed_home, armed_night, armed_away and disarmed) while the keypad itself has only three (armed_home, armed_away and disarmed). In my programming I treat armed_home and armed_night the same.

[KJB55]

Centralite 3400 keypad

Just realized that Centralites support just gave me a link to the keypads Compliance Document at zigbeealliance.org and I felt so special, I thought I was provided with some secret information… Anyway, now I know that, AND that all the information about clusters, commands and payloads/args are supposed to be used (as long as the manufacturer of the device doesn’t deviate from the standard) is in the ZigBee Cluster Library Specification. So now I did myself some reading and I have m…

@BusinessClaes - How do you get the keypad to change colors based on Armed or Disarmed status from Node Red? And to get it to beep? Please share. I’d like the keypad to use red or green on wake so I know the status of the alarm

[Solatech]

@BusinessClaes I would also like to know about your beep configuration. I just paired a Centralite 3400 to my HA instance using ZHA integration configured with a SkyConnect. Really enjoying it so far but zigbee commands are not my strong suit.

[KJB55]

@GLehnhoff

I can confirm that my Centralite 3400-D security keypad now (12 July 2023) works with ZHA.

Hi there @GLehnhoff - how do you get the Keypads to show actual colors and to beep? Do you have a node red flow or example?

I use this blueprint with Alarmo for my keypads, however the colors never change on the keypad. Nor do I know how to send beeps back to the keypad. Thanks for any help!

[GLehnhoff (Gerhard Lehnhoff)]

Hi @KJB55, as written above/below in my other writing, I connected the device via ZHA and the colors work automatically. It also beeps when the input is done, but I did not get the countdown beep working. I do not use a blueprint. It is important to know, what Centralite device you use. The last letter in the device name makes the difference. I have the 3400-D.
If the alarm-status is changed from another device or via HA, the keypad does not know. Only in that case I have a tiny Node-RED script who tells the keypad, that the alarmsystem status has changed, so that it shows the correct colors. See my other writing here above/below.

[KJB55]

@GLehnhoff - thanks for the reply. I have the 3400-D like you.

• I have it connected in Z2M so not sure if that is the problem.
• Also, when I try to put together a small Node Red script I find the device but don;t have an entity like what you have. Maybe a Z2M challenge?

[GLehnhoff (Gerhard Lehnhoff)]

@KJB55 , it did not work with Z2M when I tried it month ago. See my message from July 12th above. You have to use ZHA.

UPDATE: I’ve also informed the guys at https://zigbee.blakadder.com/ about the false information they’re giving, but they haven’t reacted. See also Centralite 3-Series Security Keypad (MSO) 3400-G Zigbee compatibility. The information here is misleading. But as I said, they didn’t react on my messages.

[GSzabados (Gábor Szabados)]

@GLehnhoff

3400-D

I do own a Linkind keypad. It is not a CentraLite one but the whole logic around any keypad should be the same, disregarding the manufacturer.

The keypad is a peripheral device. It is as dumb as it can be, because it has no other task just to report according the commands which it receives, the brain is always the central unit of the alarm.

Communication should be like this.

Wake up, reports wake up. In return central send current state, keypad shows current state.

Enter action and code on keypad, then send it to central. Central reacts on the information and sends keypad what to show.

The likelyhood that the keypad would store alarm state is zero, because the central unit has the alarm state. And that can be changed in many other ways, but the keypad. Like triggered alarm, or disarm with app, etc. The keypad is a sleeping end device, ot might wakes up every hour to report in that it is still there, but generally it communicates with the central unit when it wakes up.

That is the reason, why the keypad does bot function as an alarm panel with Z2M. The functionality of an alarm is not included.

Have a look at this Blueprint to get understanding of the logic: Zigbee2MQTT - Sync Keypad and Alarm Control Panel States

ZHA does create an alarm panel device as I remember, which is quite confusing as alarm control functionality is not provided behind that.

Z2M does not provide the alarm panel, you have to interact with the keypad to make it work, hence the necessity of the Blueprint, and it solves everything.

The difference between the -D or -X should be what color and logo is printed on the device for the convenience of the client mobile company.

[KJB55]

@GSzabados

Z2M does not provide the alarm panel, you have to interact with the keypad to make it work, hence the necessity of the Blueprint, and it solves everything.

I’ve been using a blueprint, and can get everything working on the 3400 can get everything to work on the keypads (I have three), except for the keypads showing any status color. Ideas?
Also, are there commands I can send from Node Red to the Keypad to test?

[GLehnhoff (Gerhard Lehnhoff)]

@KJB55

I’ve been using a blueprint, and can get everything working on the 3400 can get everything to work on the keypads (I have three), except for the keypads showing any status color. Ideas?
Also, are there commands I can send from Node Red to the Keypad to test?

1st question: I am not using a blueprint as most is working out of the box with ZHA and 3400-D. For all logic I use Node-RED.
2nd question: Yes. See my comments further back

[GLehnhoff (Gerhard Lehnhoff)]

@GSzabados

The difference between the -D or -X should be what color and logo is printed on the device for the convenience of the client mobile company.

I have a 3400-D and I had a 3400. 3400 (without “-D”) did not work in my case. However, this was with a different SmartHome server (not HA). Saying that, in that case, the device might have had a defect or they are different, at least to my former SmartHome system (which was Telekom Magenta SmartHome).