Linkind Keypad ZS130000078

[HASSHUN]

I'd like to ask you to help me integrating this keypad to the database. I planned to calibrate it to my alarm_control_panel, so make it able to follow commands like arm_away, arm_home and disarm.

First let's start with the configuration, cause that also can contain mistakes:
For examples, I used Xfinity and 3400-D keypads' inputs cause they looked similar (except for the fact that they are standalone devices). Here is my conf in device.js [1.17.1 (99274c7)]

    {
        zigbeeModel: ['ZB-KeypadGeneric-D0002'],
        model: 'ZS130000078',
        vendor: 'Linkind',
        description: 'Security keypad battery',
	meta: {configureKey: 1, battery: {voltageToPercentage: ['3V_2100'}},]
	fromZigbee: [fz.command_arm, fz.battery, fz.ias_sos_alarm_2], 
        exposes: [e.battery(), e.voltage(), e.battery_low(), 
            exposes.numeric('action_code', ea.STATE), e.action(['disarm', 'arm_all_zones', 'invalid_code', 'emergency'])],
    	toZigbee: [tz.arm_mode], 
        configure: async (device, coordinatorEndpoint) => {
            const endpoint = device.getEndpoint(1);
            const clusters = ['genPowerCfg', 'ssIasZone', 'ssIasAce', 'genBasic'];
            await reporting.bind(endpoint, coordinatorEndpoint, clusters);
            await reporting.batteryVoltage(endpoint);
        },
        onEvent: async (type, data, device) => {
            if (type === 'message' && data.type === 'commandGetPanelStatus' && data.cluster === 'ssIasAce' &&
                globalStore.hasValue(device.getEndpoint(1), 'panelStatus')) {
                const payload = {
                    panelstatus: globalStore.getValue(device.getEndpoint(1), 'panelStatus'),
                    secondsremain: 0x00, audiblenotif: 0x00, alarmstatus: 0x00,
                };
                await device.getEndpoint(1).commandResponse(
                    'ssIasAce', 'getPanelStatusRsp', payload, {}, data.meta.zclTransactionSequenceNumber,
                );
            }
        },
    },

I managed to get it interviewed succesfully, but the keypad only communicates to my Conbee II device if it's not connected to the Siren hub. Once it is connected, the traffic just disappears ( probably switches channel or endpoint? ).
Payloads like arm or disarm also can only be commited when it's connected.

All I can sniff is what happens between resetting the keypad and connecting to the hub. (see attached, filtered capture from Wireshark)

This issue seems very similar to Goodwin's case in #6174 with the Iris keypad. I'm trying to switch channels to be able to catch some communication between the keypad and the hub.

Any ideas or hints are welcome!

Information about the device + link

https://zigbeealliance.org/zigbee_products/linkind-keypad/
The device has a hub and it is only available in a kit.
https://www.linkind.com/product/smart-home-security-system-kit-ring-alarm/

data/database.db entry of the device

..

[HASSHUN]

Seems like the zip file is not uploaded properly. So here it is again.

Oh and about zigbee herdsmann debug here is capture as well.

Received Zigbee message from '0x680ae2fffee56c49', type 'attributeReport', cluster 'genPowerCfg', data '{"batteryPercentageRemaining":200}' from endpoint 1 with groupID null
Received Zigbee message from '0x680ae2fffee56c49', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":822935558,"imageType":2308,"manufacturerCode":4456}' from endpoint 1 with groupID null

and it doesn't find a converter for Panelstatus:

Received Zigbee message from '0x680ae2fffee56c49', type 'commandGetPanelStatus', cluster 'ssIasAce', data '{}' from endpoint 1 with groupID null
No converter available for 'ZS130000078' with cluster 'ssIasAce' and type 'commandGetPanelStatus' and data '{}'

linkind_keypad_0x0B(11).zip

[kloodhu]

I try to configure the same device, and went a little bit further.

A captured the communication between the original hub and keypad.
When i turn on the keypad (with the proximity sensor) it send a message to the hub:

The command "7" is the "getPanelStatus".

Then the hub after an ack message sent back to the keypad a response:

The command "5" is the "getPanelStatusRsp" with the payload "00 00 00 00".

I believe the keypad is waits for this response, but i don't know, how to write this into the tozigbee part.
The relevant code from the (original) toZigbee:

arm_mode: { key: ['arm_mode'], convertSet: async (entity, key, value, meta) => { const mode = utils.getKey(constants.armMode, value.mode, undefined, Number); if (mode === undefined) { throw new Error(Unsupported mode: '${value.mode}', should be one of: ${Object.values(constants.armMode)}`);
}

        if (value.hasOwnProperty('transaction')) {
            entity.commandResponse('ssIasAce', 'armRsp', {armnotification: mode}, {}, value.transaction);
        }

        let panelStatus = mode;
        if (meta.mapped.model === '3400-D') {
            panelStatus = mode !== 0 && mode !== 4 ? 0x80: 0x00;
        }
        globalStore.putValue(entity, 'panelStatus', panelStatus);
        const payload = {panelstatus: panelStatus, secondsremain: 0, audiblenotif: 0, alarmstatus: 0};
        entity.commandResponse('ssIasAce', 'panelStatusChanged', payload);
    },
},`

A put this code to the js:

`const ias_panel_status = {
cluster: 'ssIasAce',
type: 'commandGetPanelStatus',
convert: (model, msg, publish, options, meta) => {

        const panelStatus = msg.data.panelstatus;
        return {
            panelStatus
        };
    },

};`

I don't know this is necessary or just hide the error about no converter.

I can send the full capture with the key in private, if you think it is help.

[HASSHUN]

Hi kloodhu,

That was a scenario ( panel wake up by proximity) I didn't look into, but mine only produces this after interviewing. Anyways, it still does not explain what happens after the hub is synced with the keypad. I'm unable to register a single line after it. Can you reach out anything related to arm or disarm?

@Koenkk or @goodwin or anyone of the mighty Gods of Z2M, based on the info we provided, can you give us a hint?

[Koenkk]

The getPanelStatus can be done in the onEvent. The onEvent in the OP looks correct to me.

[HASSHUN]

The panelstatus is the same at my side as well, but I think it's not the main issue that we don't manage to get the panelstatus converted.
Seems like the configuration for Xfinity or 3400-D does not match this device's. And the main problem is that I can't catch a single command from or to the keypad after it's synced with the hub.(the panelstatus thing kloodhu mentioned is also "off-hub" communication)

Do you know how to find out where does the communication flow now?

[HASSHUN]

I see the device only under homeassistant in MQTT explorer. I tried to publish an action, but there is no identified topic for it. :I

I don't know if there's some added value to it, but here is the database input.

{"id":37,"type":"EndDevice","ieeeAddr":"0x588e81fffe23364b","nwkAddr":45091,"manufId":4456,"manufName":"lk","powerSource":"Battery","modelId":"ZB-KeypadGeneric-D0002","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":1025,"inClusterList":[0,1,3,32,1280,2821],"outClusterList":[3,25,1281],"clusters":{"genBasic":{"attributes":{"modelId":"ZB-KeypadGeneric-D0002","manufacturerName":"lk","powerSource":3,"zclVersion":2,"appVersion":2,"stackVersion":6,"hwVersion":1,"dateCode":"20200402","swBuildId":"3.13"}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":180,"batteryVoltage":29}},"ssIasZone":{"attributes":{"iasCieAddr":"0x00212effff067279","zoneState":1}}},"binds":[{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00212effff067279","endpointID":1},{"cluster":1280,"type":"endpoint","deviceIeeeAddress":"0x00212effff067279","endpointID":1},{"cluster":1281,"type":"endpoint","deviceIeeeAddress":"0x00212effff067279","endpointID":1},{"cluster":0,"type":"endpoint","deviceIeeeAddress":"0x00212effff067279","endpointID":1}],"configuredReportings":[{"cluster":1,"attrId":32,"minRepIntval":3600,"maxRepIntval":62000,"repChange":0}],"meta":{}}},"appVersion":2,"stackVersion":6,"hwVersion":1,"dateCode":"20200402","swBuildId":"3.13","zclVersion":2,"interviewCompleted":true,"meta":{"configured":1},"lastSeen":1613396644979}

[HASSHUN]

@kloodhu is there any progress at your side?

[HASSHUN]

@Koenkk Can you tell me please what does this mean below? I got this when the hub and the keypad are connected and I replace the batteries.

[HASSHUN]

Any chance that someone would answer my question? I mean it is a great product and easily accessible across Europe. I'm sure if we could integrate this keypad many would benefit from it.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[GSzabados]

Hello,

I would like to resurrect this topic. And make some further progress with some help from someone, who knows what has to be done.

I started from the OP's code, which had a typo, and I managed to reach some success, but I am confused and stuck.

So this is the OP's code with some minor changes, if you use it as an external converter. But unfortunately it is not working due to the onEvent's panelStatus part.

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;

module.exports = [
    {
        zigbeeModel: ['ZB-KeypadGeneric-D0002'],
        model: 'ZS130000078',
        vendor: 'Linkind',
        description: 'Security keypad battery',
        meta: {configureKey: 1, battery: {voltageToPercentage: '3V_2100'}},
        fromZigbee: [fz.command_arm, fz.battery, fz.ias_sos_alarm_2, fz.ias_ace_occupancy_with_timeout], 
        exposes: [e.battery(), e.voltage(), e.battery_low(), 
            exposes.numeric('action_code', ea.STATE), e.action(['disarm', 'arm_all_zones', 'invalid_code', 'emergency'])],
        toZigbee: [tz.arm_mode], 
        configure: async (device, coordinatorEndpoint) => {
            const endpoint = device.getEndpoint(1);
            const clusters = ['genPowerCfg', 'ssIasZone', 'ssIasAce', 'genBasic'];
            await reporting.bind(endpoint, coordinatorEndpoint, clusters);
            await reporting.batteryVoltage(endpoint);
        },
        onEvent: async (type, data, device) => {
            if (type === 'message' && data.type === 'commandGetPanelStatus' && data.cluster === 'ssIasAce' &&
                globalStore.hasValue(device.getEndpoint(1), 'panelStatus')) {
                const payload = {
                    panelstatus: globalStore.getValue(device.getEndpoint(1), 'panelStatus'),
                    secondsremain: 0x00, audiblenotif: 0x00, alarmstatus: 0x00,
                };
                await device.getEndpoint(1).commandResponse(
                    'ssIasAce', 'getPanelStatusRsp', payload, {}, data.meta.zclTransactionSequenceNumber,
                );
            }
        },
     },
];

But if I remove some of it and hardcode the panelStatus, the panel wakes up and accept codes.

const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;

module.exports = [
    {
        zigbeeModel: ['ZB-KeypadGeneric-D0002'],
        model: 'ZS130000078',
        vendor: 'Linkind',
        description: 'Security keypad battery',
        meta: {configureKey: 1, battery: {voltageToPercentage: '3V_2100'}},
        fromZigbee: [fz.command_arm, fz.battery, fz.ias_sos_alarm_2, fz.ias_ace_occupancy_with_timeout], 
        exposes: [e.battery(), e.voltage(), e.battery_low(), 
            exposes.numeric('action_code', ea.STATE), e.action(['disarm', 'arm_all_zones', 'invalid_code', 'emergency'])],
        toZigbee: [tz.arm_mode], 
        configure: async (device, coordinatorEndpoint) => {
            const endpoint = device.getEndpoint(1);
            const clusters = ['genPowerCfg', 'ssIasZone', 'ssIasAce', 'genBasic'];
            await reporting.bind(endpoint, coordinatorEndpoint, clusters);
            await reporting.batteryVoltage(endpoint);
        },
        onEvent: async (type, data, device) => {
            if (type === 'message' && data.type === 'commandGetPanelStatus' && data.cluster === 'ssIasAce') {
                const payload = {
                    panelstatus: 0x00,
                    secondsremain: 0x00, audiblenotif: 0x00, alarmstatus: 0x00,
                };
                await device.getEndpoint(1).commandResponse(
                    'ssIasAce', 'getPanelStatusRsp', payload, {}, data.meta.zclTransactionSequenceNumber,
                );
            }
        },
     },
];

Indeed the panel starts to accept codes, when { "arm_mode": { "mode": "disarm" } } like messages are passed to it with the non-hardcoded values as well, but I am not fully convinced what is the logic behind this panel, or how it really should work.
I am missing from the states of the device the panelStatus/armMode.

If someone has a better understanding how the panel should work, and what are the messages which should be passed from the coordinator to the panel when wakes up, that would make development a bit easier.

So far looks like, once awakes, it needs a panelStatus/armMode, in response to commandGetPanelStatus, but I don't know what is stored under panelStatus, as I cannot see it anywhere.

@Koenkk, could you re-open this issue please, and if you have any input, that would be appreciated.

[GSzabados]

It really looks like, when paired a panelStatus 0x00 has to be sent first.

[kloodhu]

The device is working almost perfect with ZHA now.

[GSzabados]

The device is working almost perfect with ZHA now.

Can you share some details what do you mean "almost"?

I will have a look how the code works there.

It would be nice to make it work with Z2M as well. Just need to understand the quirks.

[HASSHUN]

Hi @GSzabados / Szia GSzabados!

In fact I just tried ZHA and everything works perfectly (no "almost" for me ), although I have to use a separate Zigbee receiver (CC2531) for that purpose, cause Z2M and ZHA cannot work in parallel on the same device.

Nevertheless If you can find the right way to get your configuration pulled in, I'd switch back to Z2M with the keypads. So this issue is still not solved @Koenkk and as I see more users tends to be interested about the product.

GSzabados, If I can help with anything please let me know, I have all the means for it now,.(but lack the knowledge :P)

[GSzabados]

@HASSHUN, I have a spare CC2531 as well, but I do not want to build another Zigbee network. I have already three of them, Z2M, Hue and SmartThings, and yesterday I redone my Z2M network with a CC2652P dongle after struggling for weeks with another firmware on the dongle. I reflashed to Koenkk's last firmware and re-paired everything. So no intention at the moment to have another for just the keypad.
But by looking at the ZHA solution, the keypad is recognised as an Alarm Panel as I can see from other posts, correct me if I am wrong. And the requirement for that is to hold a panel status or alarm status, I believe.
And I think that is missing from the Z2M setup.
As I can see the panel requires that and initial disarmed status is passed to it and then it needs to sync with the coordinator later on.
I cannot see in the current code that how is the initial disarmed is passed to the keypad. I cannot see from where it gets the panelStatus value for the onEvent response, unless a disarm command has passed first to the keypad, but I have not succeeded with that neither.

I saw an ongoing PR and issue for the Xfinity keypad which has had the panel status handled in some different way, but that PR hasn't been fully merged. Koenkk/zigbee-herdsman-converters#1873
I have a guess, that method would be the right one. And Z2M should persist a state for the panel status, and not just the action what the button press provides.

I really need some help to understand what messages are passed to the device and what it is sending to the coordinator. And how to output that to a log. I turned on herdsman logging and debug for Z2M, but that didn't provide enough information. I would love to get some information how I can add some debug to the external converter. @Koenkk can you advise on that please?

[HASSHUN]

@GSzabados. I have a sniffer set , I'll look it up tomorrow morning what's happening through ZHA.

[GSzabados]

I really need some help to understand what messages are passed to the device and what it is sending to the coordinator. And how to output that to a log. I turned on herdsman logging and debug for Z2M, but that didn't provide enough information. I would love to get some information how I can add some debug to the external converter. @Koenkk can you advise on that please?

@Koenkk, Never mind, I just realized, that the zigbee-herdsman debug is working, but it outputs only to the log (file), but not to the web interface's Log view. I think, I have now what I need to look at. :)

@HASSHUN, if you can provide some info how the pairing happens and what information ZHA passes to the keypad, when it wakes up, that would be the best.

[GSzabados]

@Koenkk, Never mind, I just realized, that the zigbee-herdsman debug is working, but it outputs only to the log (file), but not to the web interface's Log view. I think, I have now what I need to look at. :)

Actually, I have to correct myself. I see it in the Supervisor 's Add-ons' Log Tab, but I cannot see it in the log of Zigbee2MQTT in /share/zigbee2mqtt/log. Is it logged to file? Or just STDOUT? Or is there any way to save it to file?

[Koenkk]

@GSzabados only logged to STDOUT.

[GSzabados]

@GSzabados only logged to STDOUT.

Thanks, then I will try some different way. I have already installed Z2M on a Windows machine a few days ago, just to be able to erase the NVMEM of a CC2652. I will try to do the work with that.

[GSzabados]

@GSzabados only logged to STDOUT.

How is this command should be used on a Windows installation?

DEBUG=zigbee-herdsman* npm start

I got only this:

'DEBUG' is not recognized as an internal or external command,
operable program or batch file.

[GSzabados]

@GSzabados only logged to STDOUT.

How is this command should be used on a Windows installation?

DEBUG=zigbee-herdsman* npm start

I got only this:

'DEBUG' is not recognized as an internal or external command,
operable program or batch file.

I should have Google a bit first. If anyone comes along here to find it, the command is this for a Windows environment:

setx DEBUG zigbee-herdsman*

[HASSHUN]

Hi @GSzabados ,

Seems like I've been a bit early stating everything is perfect with ZHA and the keypad.

It might be a general ZHA-raspbian issue, but by yesterday the CC2531 dongle had lost its signal and I was unable to repair it ever since then, no matter how I tried ( disabling / removing modem manager, reconfiguring ZHA integration ) . So no luck yet. I'll let you know when I manage to record something.

@Koenkk I know it's off-topic here, but I wonder does the CC2531 has newer firmware than the 20201127 one?

[pannal]

This behavior is correct and normal. Doing this while the keypad is blinking green solves the issue: https://www.zigbee2mqtt.io/devices/ZS130000078.html#armingdisarming-from-the-server

@robertalexa Since this question has already come up several times, we should perhaps add to the documentation that a status must initially be sent to the device in order for it to work. Is this also the case with the Hive keypad?

Hey, unfortunately this doesn't work for me. I pair the device (configuration fails the first time, then works a second later), it's fully shown in z2m, and it slowly blinks green.

I spoke too soon. After fully re-pairing the device and immediately sending the payload to the original friendly name, without renaming it, it initializes successfully.

[pannal]

I'm having trouble arming the keypad from the keypad itself. I'm trying to use code "123", so I press Arm Away, then 1 2 3, then the accept button.

What it sends to z2m is:

Received Zigbee message from 'Keypad', type 'commandArm', cluster 'ssIasAce', data '{"armmode":3,"code":"123","zoneid":23}' from endpoint 1 with groupID 0

MQTT publish: topic 'zigbee2mqtt/Keypad', payload '{"ac_status":false,"action":"arm_all_zones","action_code":"123","action_transaction":78,"action_zone":23,"battery":100,"battery_low":false,"linkquality":93,"occupancy":true,"restore_reports":true,"smoke":false,"supervision_reports":true,"tamper":false,"test":false,"trouble":false,"voltage":3300}'

Shouldn't the zone always be 0?

Edit: I'm using these automations for the manual alarm panel: https://gist.github.com/evilpie/ce3d7b90b0584202b5efc4fe39d1d663

[robertalexa]

The zone is whatever the manufacturer gives the keypad. In the case of Linkind is 23.

You just need to send the appropriate response... See documentation:
https://www.zigbee2mqtt.io/devices/ZS130000078.html#armingdisarming-from-the-keypad

Also make sure you read that whole section before you jump to doing stuff :)

With regards to how to hook this up into HA natively, I do not know because i don't do it myself. @stefangries made this work in his setup and is in the process of writing a "how to" guide for HA. Might be worth keeping an eye open. When this will be ready, it will be included in the z2m documentation too.

LE: i suggest you see this working using mqtt only and confirm operation before you jump into HA integration. This way you know where and how to ask for help. You, like many others, have come asking for help but in their process failed to follow the instructions first. Once you do it a few times via mqtt only, then you can plan ahead what else needs to happen between z2m and your automation platform :) have fun with your setup

[pannal]

Thank you for the pointers, I actually got it working now.

I wasn't understanding the action codes in the gist correctly. 9998 and 9999 are actually pin codes I have to replace with mine.

[robertalexa]

Personally I would suggest keeping it simple and using the same code for all operations. Then you just compare the code inputed with the one you expect, and decide if it is valid or not.

If it is valid you need to send 2 commands, 1 to confirm the operation to the keypad, and another to actually set the arm_mode (that may be disarm, exit_delay etc)

If it is invalid you need to send 1 single command with an arm_mode of invalid_code.

All possible values are described in the documentation I have mentioned above

[swieprecht]

Hi, can I have a bit of help?
I can't get this to pair with my network properly.
I've got it to "pair" and it is being detected in Z2M if I lift it it will show tampared so the connection is real
The issue is if I try to type anything on the keypad it flashes as if its not connected and beeps.

[guerocp]

Hi, can I have a bit of help? I can't get this to pair with my network properly. I've got it to "pair" and it is being detected in Z2M if I lift it it will show tampared so the connection is real The issue is if I try to type anything on the keypad it flashes as if its not connected and beeps.

This behavior is correct and normal. Doing this while the keypad is blinking green solves the issue:
https://www.zigbee2mqtt.io/devices/ZS130000078.html#armingdisarming-from-the-server

[kvj]

Hi there,

I've made a custom hass component for the supported devices, to get rid of the automations.

Basically the I extended the manual alarm control panel integration with the support of MQTT, and added a few additional features.

If you're interested, please take a look: https://github.com/kvj/hass_transaction_alarm_panel

[robertalexa]

@stefangries also created a blueprint a while ago for this device. The link was posted as part of a different thread where we discussed some of the limitations and recurring questions.

https://community.home-assistant.io/t/zigbee2mqtt-sync-keypad-and-alarm-control-panel-states/345311

[normanr]

btw, I think it might make more sense to add separate toZigbee converters for armRsp (with transaction) and panelStatus (without transaction). That way it should be far more obvious to users that they need to send both messages.

I also found that sending a zoneStatusChanged message will cause the XHK1-UE keypad to chime (chimes must be enabled by holding down 8 for 3 seconds), so I will try and send a PR for that too.

[mrdago]

Hi, after several hours of try and error I need some help from an expert? The linkind keypad is paired and from zigbee2mqtt I got the message :
Zigbee2MQTT:info 2021-12-28 17:16:36: Successfully configured '0xec1bbdfffe715343'

Every 3 seconds I receive the following status message:

Zigbee2MQTT:info 2021-12-28 18:00:59: MQTT publish: topic 'zigbee2mqtt/0xec1bbdfffe715343', payload '{"ac_status":false,"battery":100,"battery_low":false,"linkquality":123,"occupancy":true,"restore_reports":true,"smoke":false,"supervision_reports":true,"tamper":true,"test":false,"trouble":false,"voltage":3100}'

If I type a command on the keypad nothing is send to the MQTT broker. What is necessary to bring the keypad in communication with the server?
I'm using version:
Zigbee2MQTT:info 2021-12-28 17:14:21: Starting Zigbee2MQTT version 1.22.0 (commit #df0543d4)
Zigbee2MQTT:info 2021-12-28 17:14:21: Starting zigbee-herdsman (0.13.164)

[robertalexa]

4 comments above

#6242 (comment)

[mrdago]

@robertalexa , ok I dived a bit deeper into the exchanged comments of the topic and got it now to work. I stumpled upon the z2m device description https://www.zigbee2mqtt.io/devices/ZS130000078.html as it's not clear pointed out which mode value has to be published by the server after the device is paired. Imo it would help also other people if the description would have a section 'pairing' or 'setup' where this would be described more in depth.

The description of 'Arming/Disarming from the server' needs to be revised as the Linkind Keypad ZS130000078 does not support the 'arm_night_zones' mode (only 'arm_day_zones' and 'arm_all_zones').
Thanks for your support.

[robertalexa]

Glad it is all good.

The values specified are all the available values as per ZCL standard and not just device specific. So it would be a case of figuring out what works for it.

The reason is because when i have reviewed the whole code for alarms i only had the hive keypad, so i could not verify each device individually. With testing, people that own certain devices can confirm what values work and then submit PRs to remove them

As to better instructions after pairing i agree, i will try to find some time to put something together.

[VitanyLTD]

I've had the same pairing issues as described above, finally got my unit paired after reading this conversation.
There is however still one problem, zigbee2mqtt does not publish a message after armind/disarming the alarm.
Panic however seems to work fine?

debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandGetPanelStatus', cluster 'ssIasAce', data '{}' from endpoint 1 with groupID null
info MQTT publish: topic 'zigbee2mqtt/0x680ae2fffee558eb', payload '{"ac_status":false,"action":null,"action_code":null,"action_transaction":null,"action_zone":null,"battery":99,"battery_low":false,"linkquality":255,"occupancy":true,"restore_reports":true,"smoke":false,"supervision_reports":true,"tamper":false,"test":false,"trouble":false,"voltage":2900}'
debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandArm', cluster 'ssIasAce', data '{"armmode":0,"code":"123","zoneid":23}' from endpoint 1 with groupID null
debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandArm', cluster 'ssIasAce', data '{"armmode":0,"code":"123","zoneid":23}' from endpoint 1 with groupID null
debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandArm', cluster 'ssIasAce', data '{"armmode":0,"code":"123","zoneid":23}' from endpoint 1 with groupID null
debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandArm', cluster 'ssIasAce', data '{"armmode":0,"code":"123","zoneid":23}' from endpoint 1 with groupID null

Pressing panic produces the following logs

debug Received Zigbee message from '0x0015bc003100bb8d', type 'read', cluster 'genTime', data '["time"]' from endpoint 35 with groupID null
debug Received Zigbee message from '0x680ae2fffee558eb', type 'commandPanic', cluster 'ssIasAce', data '{}' from endpoint 1 with groupID null
info MQTT publish: topic 'zigbee2mqtt/0x680ae2fffee558eb', payload '{"ac_status":false,"action":"panic","action_code":null,"action_transaction":null,"action_zone":null,"battery":99,"battery_low":false,"linkquality":255,"occupancy":true,"restore_reports":true,"smoke":false,"supervision_reports":true,"tamper":false,"test":false,"trouble":false,"voltage":2900}'
info MQTT publish: topic 'zigbee2mqtt/0x680ae2fffee558eb', payload '{"ac_status":false,"action":"","action_code":null,"action_transaction":null,"action_zone":null,"battery":99,"battery_low":false,"linkquality":255,"occupancy":true,"restore_reports":true,"smoke":false,"supervision_reports":true,"tamper":false,"test":false,"trouble":false,"voltage":2900}'
info MQTT publish: topic 'zigbee2mqtt/0x680ae2fffee558eb/action', payload 'panic'

Do i still have to do something to make the arm/disarm produce a mqtt message?

[53RT]

Hi,

anyone else had problems with version 1.22.2-1? After upgrading I didn't received messages with the action and the action code included so I couldn't change states via the keypad. Pressing the SOS button did trigger the panic action.

Luckily downgrading to 1.22.0-3 brought the previous behavior back.

I couldn't find any comments in the changelog that this device has got some updates in the current version. Anyways I am curious if it worked for you.

[robertalexa]

I do not own any keypads anymore but this situation rings a bell.

If i remember correctly and it might have been @stefangries who discovered it , upon updating the server, in this case z2m, it loses the variable (which is in memory) of the alarm status. That being said after updating z2m you need to set the alarm state via mqtt command. See documentation about setting from server.

Once doing that the keypad geta informed of the current status of the alarm and behaves as expected.

PS. It might also be lost when restarting z2m, for some reason i dont remember. But you could create an automation that listens for z2m restart, see documentation for the message, and when that is received you set the alarm status to its previous state

LE: yes it does reset after restart. Here is the comment #6242 (comment)

LE2: here is confirmation of when it needs to be re-set manually: #8997 (comment)

And here is how to handle the automation to set the status on restart without manual intervention:
#8997 (comment)

[53RT]

@robertalexa Thank you for your answer and the links. I am not sure that it is one of the mentioned issues.

I use Node-Red to listen on the occupancy wake up messages from the keypad and answer them with the current state from the home assistant alarm. So it actually got the correct state and also displayed it.

In the mqtt history I used to get 3 messages when I change state

1. wake up message when the keypad is activated by the ir sensor {... "action":null ...}
2. message with the actual action {... "action": "disarm" ...}
3. another message right after message 2 with an empty string as the action {... "action":"" ...}

After the update the keypad did send only the first message. Which seems odd so I think z2m probably didn't processed messages 2 and 3 correctly.

[stefangries]

anyone else had problems with version 1.22.2-1? After upgrading I didn't received messages with the action and the action code included so I couldn't change states via the keypad.

I'm experiencing the same behaviour. action, action_transaction and action_code are always null.

[robertalexa]

@53RT Oh i might have misunderstood your situation :)

Are you by any chance using "debounce"? I know there was some work done recently on this but I am not familiar with the details nor the outcome.

I will have a look and see if there were any changes to the files involved in alarms, and see what i find.

[robertalexa]

1. wake up message when the keypad is activated by the ir sensor {... "action":null ...}
2. message with the actual action {... "action": "disarm" ...}
3. another message right after message 2 with an empty string as the action {... "action":"" ...}

After the update the keypad did send only the first message. Which seems odd so I think z2m probably didn't processed messages 2 and 3 correctly.

@sjorge Is this something that could be explained by the recent work around debounce? I think you took the lead on that one with @Koenkk ?

[stefangries]

1.22.1-1 is working for me, while 1.22.2-1 is not.

[53RT]

@stefangries good to have someone confirming that I am not the only one having this issue :-)

@robertalexa the debounce field in the settings section of the keypad device is empty. But I cannot say if the update to 1.22.2-1 changed the settings as I am now back to the older version.

[robertalexa]

Hey all,

Seems like this has already been raised and resolved, and the fix will come as part of 1 February release.

#10504

Personally I would suggest you have a test with the dev branch, and if you spot any unexpected behaviour leave your thoughts on that thread

[stefangries]

The edge version works for me. Thanks for the hint @robertalexa !

[vguna]

Sorry, just realized it's closed. Moved to discussions: #11453 (comment)

[dcjona]

Hi, i have a problem with this keypad. after pairing no problem everything works fine but after a few minutes the keypad loose config ? the action button doesn't blink when a touch them or activate the keypad by proximity. so i 'm not able to input the code.
some one has got this problem?
It's like the communication with z2m failed. the occupancy sensor stays at false
thanks