Immax Neo Keypad MS-K1AZ / MaxSmart MS-K1AZ

[MrAdam]

Device

• Product name: MS-K1AZ
• Manufacturer: _TZE200_n9clpsht
• Model identifier: TS0601
• Device type:
  • Other: Keypad

Screenshots

Basic

Groups

Scenes

Other clusters that are not mentioned above

Tuya specific

[MrAdam]

If it helps, I can post the deCONZ logs from when the alarm panel is locked/unlocked.

[Smanar]

Ok so I don't see what to do with this device ...

• the alarm system can't work with tuya keypad
• can't use a keypad type for this device else it will broke the alarm system

[MrAdam]

I'm not quite sure what you mean - maybe I didn't include enough information about the device?
The device exposes an alarm state and some functions.
From the manual, I can see that the following functions exists:

• Battery level: Battery level of the device
• Enable arm/disarm: Enable/disable arm/disarm function
• Arm delay time: Set arm delay time from 0 to 180 seconds
• Arm delay beeps: Enable/disable arm delay beeps
• Keypad beeps: Enable/disable keypad beeps
• Quick SOS: Enable/disable quick sos function
• Quick Disarm: Enable/disable quick disarm function
• Quick arm: Enable/disable quick arm function
• Reset: Reset to factory settings

Being able to configure the functions remotely would be nice, but the only thing that's really necessary for this device to work well with deCONZ would be to be able to read/write the alarm "state" - eg. "armed away", "armed home", "triggered".

I'm not sure what kind of "device type" I should have written to clarify this.

[Smanar]

The problem is the device working mode. It don't work at all like classic keypad.

Keypad are passive device, so there is an alarmsystem in deconz to mangage the "security stuff", and this code is not compatible with the tuya cluster.

To resume, there is too much work to do. The PR for TRV is still in waiting list, then after will be the covering, so keypad ...

[MrAdam]

Thanks for the information.

I assume that the right solution would be a way to synchronize the "state" of the keypad device with the "Arm mode" of a deCONZ Alarm System entry, as they are almost 1-1. This would of course need to work with the Tuya cluster as you mentioned.

I'm a developer myself, but mostly have experience with C#, but if there's any direction you can point me in where I can help out, please tell.

[Smanar]

I don't know what to say.
I can help you to locate code or explain how work deconz, but I already have a PR on the alarmystem core and one other to add the tuya cluster for TRV that are in waiting list since lot of time, so I don't want to be pessimistic but it s lot of work which will not be useful before long time.

The DDF core is able to read all tuya value wihout problem, but not write them, so can check if the device need both or not.

Here you have how work the IAS ACE cluster, it's the one used by classic cluster https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ias_ace.cpp
You will see the alarmsystem core is totaly "nested" with it. And the objective is removing all specific code to use only the DDF core #5733
So not sure your solution will be merged one day, because I think you will use too much specific code (me, that's what I would do, IDK if you see a better way)

[MrAdam]

Thank you, sounds like it's a ways into the future to get the alarm system moved to DDF.
I've just acquired a Tuya Zigbee Gateway so that I can map out the DPID's needed for the device - I was able to control the device via the Tuya cluster in the deCONZ VPN, so I guess that's progress.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[MrAdam]

Here's the data-point references I've discovered so far:

Settings

• Battery Level (percentage)
  • DPID=3
• Enable arm/disarm (boolean)
  • DPID=101
• Arm delay time (seconds)
  • DPID=103
• Arm delay beeps (boolean)
  • DPID=111
• Keypad beeps (boolean)
  • DPID=104
• Quick SOS (boolean)
  • DPID=105
• Quick Disarm (boolean)
  • DPID=106
• Quick Arm (boolean)
  • DPID=107
• Reset (boolean)
  • DPID=110

States

• SOS alarm
  • DPID=23
• Anti-remove Alarm
  • DPID=24
• Disarmed
  • DPID=26
• Arm
  • DPID=27
• Home
  • DPID=28
• SOS
  • DPID=29

Other/Unknown/Chinese

• User code
  • DPID=109
• Admin code
  • DPID=108
• ??? (user1)
  • DPID=112

[Smanar]

???
It's not the same dpid for arm and disarm ?
So its possible to send in same time a request to enable both in same time ? Tuya is a sample for logic ...

[MrAdam]

I agree that their logic is weird. But no, in this case it's because it's a state you can get - I haven't been able to trigger a specific state via the Tuya cluster, only receive state updates (which is where the DPID's here are from).

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.