rafaelreis-r commented 2 years ago

Link

https://www.aqara.com/en/product/smart-door-lock-a100-zigbee

Database entry

"definition":null,"friendly_name":"0x54ef4410004c5112","ieee_address":"0x54ef4410004c5112","status":"successful","supported":false},"type":"device_interview"

Comments

Hey all. I just got my hands on a Aqara A100 Pro smart lock. Although I'm a competent sysadmin, I've never worked with zigbee devices. Wondering if I could provide info / be guided to dump information in order to add support to this family of door locks.

Hardware I own:

Conbee II stick on the latest firmware
Pi4 running HASSIO / Zigbee2mqtt
Aqara G3 Camera Hub (unfortunately non rooted)

I'm willing to purchase a CC2531 sniffer if necessary.

What have I done so far:

read the guide
Checked out lumi.lockentries on Xiaomi.js
Figured out a Pairing process explained below.

Pairing Process

The A100 series do not have a physical Zigbee pairing button / process. You need a compatible Aqara Hub to trigger the pairing on the lock. I figured out a way to do it:

Add the lock to the Aqara app (Bluetooth)
Add your zigbee hub to the Aqara app (wifi)
Permit Join All on Zigbee2mqtt
Still in the Aqara app, go to the lock settings and follow the prompts to bind it to your Aqara Zigbee Hub (in my case the G3)
As soon as you hear the audio / led prompt from the Aqara hub, cut it's power.
If you get the timing right, (took me 3 attempts) the lock will complete pairing process to Zigbee2Mqtt

A100 Pro vs A100 Zigbee

I read that both have Zigbee functionality, Pro version lacking remote unlock and remote passcode setup as compared to the Zigbee version. I couldn't find the Zigbee version at the time of purchase. Details here

Logs I collected over the pairing procedure

info  2022-07-06 18:29:44: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x54ef4410004c5112","ieee_address":"0x54ef4410004c5112"},"type":"device_joined"}'
info  2022-07-06 18:29:44: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x54ef4410004c5112"},"type":"device_connected"}'
info  2022-07-06 18:29:44: Starting interview of '0x54ef4410004c5112'
info  2022-07-06 18:29:44: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x54ef4410004c5112","ieee_address":"0x54ef4410004c5112","status":"started"},"type":"device_interview"}'
info  2022-07-06 18:29:44: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"pairing"}'
error 2022-07-06 18:32:10: Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genIdentify(["identifyTime"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
info  2022-07-06 18:32:10: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genIdentify([\"identifyTime\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"zigbee_publish_error"}'
error 2022-07-06 18:32:17: Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genIdentify(["identifyTime","identifyCommissionState"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
info  2022-07-06 18:32:17: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genIdentify([\"identifyTime\",\"identifyCommissionState\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"zigbee_publish_error"}'
error 2022-07-06 18:32:23: Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genGroups(["nameSupport"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
info  2022-07-06 18:32:23: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 genGroups([\"nameSupport\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"zigbee_publish_error"}'
error 2022-07-06 18:32:49: Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 aqaraOpple(["mode"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
info  2022-07-06 18:32:49: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 aqaraOpple([\"mode\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"zigbee_publish_error"}'
error 2022-07-06 18:32:53: Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 aqaraOpple(["mode","illuminance"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4447,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received)'
info  2022-07-06 18:32:53: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'read' to '0x54ef4410004c5112' failed: 'Error: Read 0x54ef4410004c5112/1 aqaraOpple([\"mode\",\"illuminance\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":4447,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received)'","meta":{"friendly_name":"0x54ef4410004c5112"},"type":"zigbee_publish_error"}'
info  2022-07-06 18:41:04: Successfully interviewed '0x54ef4410004c5112', device has successfully been paired
warn  2022-07-06 18:41:04: Device '0x54ef4410004c5112' with Zigbee model 'undefined' and manufacturer name 'undefined' is NOT supported, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html
info  2022-07-06 18:41:04: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":null,"friendly_name":"0x54ef4410004c5112","ieee_address":"0x54ef4410004c5112","status":"successful","supported":false},"type":"device_interview"}'
info  2022-07-06 18:41:04: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"friendly_name":"0x54ef4410004c5112","supported":false},"type":"pairing"}'
info  2022-07-07 14:56:39: Removing device '0x54ef4410004c5112' (block: false, force: true)
info  2022-07-07 14:56:39: MQTT publish: topic 'zigbee2mqtt/0x54ef4410004c5112', payload ''
info  2022-07-07 14:56:39: Successfully removed device '0x54ef4410004c5112' (block: false, force: true)
info  2022-07-07 14:56:39: MQTT publish: topic 'zigbee2mqtt/bridge/response/device/remove', payload '{"data":{"block":false,"force":true,"id":"0x54ef4410004c5112"},"status":"ok","transaction":"tpf8h-1"}'

External converter

No response

Supported color modes

No response

Color temperature range

No response

idomp commented 2 years ago

Would really like to see support for this lock!

kenchan97 commented 2 years ago

+1

rafaelreis-r commented 2 years ago

I'm from Brazil and BRL to USD exchange rates are atrocious, but I'm able to provide a 40 USD bounty to get this working.

@Koenkk maybe you would be able to take a look at this or point me out on a direction?

Koenkk commented 2 years ago

@rafaelreis-r could you make a sniff when pairing the device to the original hub? https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531

MaxD16 commented 2 years ago

+1

rafaelreis-r commented 2 years ago

@rafaelreis-r could you make a sniff when pairing the device to the original hub? https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531

Just received the CC2531 today. Flashed it and compiled whsniff. Files are attached below. I've also added the pairing process to a known device (Aqara Mini Switch - WXKG12LM) for reference.

Attachements:

Notes:

Transport Key is in the Device Announcement packet in the capture.
I performed most of the basic actions with the door lock after pairing. That is also included in the capture. I figured it might help with the converter.
This was more challenging than I anticipated. But I suppose everything was sniffed properly.

Koenkk commented 2 years ago

@rafaelreis-r

Could you also provide me a sniff when pairing it to z2m?
What command is send when the lock is locked/unlocked? (can you indicate the No. in wireshark?)

rafaelreis-r commented 2 years ago

@Koenkk

Could you also provide me a sniff when pairing it to z2m?

A100 Z2M Pairing.pcapng.gz
log.txt - Zigbee Herdsman debug log.

I tried using a converter based on lumi.lock.acn02, since the A100 reports itself as lumi.lock.acn01, but didn't seem to work (I don't discard having screwed up somewhere).

I had to spin up a separate Z2M instance since my network is very busy atm, and I needed to be close to the lock. All I had was a windows laptop, so the logs will reflect that.

What command is send when the lock is locked/unlocked? (can you indicate the No. in wireshark?)

This is the sequence of events reported in the door lock log. Note that it is from new to old, so reverse of what wireshark logged. "Me" refers to me. It reports the user which did the action. If it was my wife for instance, it would say her Name instead of "Me"

Unfortunately I'm unable to align No. with time. I could do a new dump paying attention to the No. if you need.

lock_log.jpg

Koenkk commented 2 years ago

So the first issue that needs to be tackled is that the device leaves almost immediately after pairing it to z2m (packet 71 in A100 Z2M Pairing.pcapng.gz). I've compared the z2m vs the xiaomi gateway sniff and everything is the same until the Node Descriptor Response (packet 117/67). In the z2m sniff the device leaves 2 seconds after this. In the Xiaomi sniff some encrypted commands are send after this (it seems Xiaomi uses a custom encryption key for this). My first suspicion is that the small differences in the node descriptor response may cause this but unfortunately I cannot change the adapter the node descriptor response because the Conbee firmware is not opensource. Do you also have access to a Texas Instruments based adapter?

rafaelreis-r commented 2 years ago

@Koenkk

I only own the Conbee-II and the CC2531 flashed for sniffing. Electronics are highly tariffed and expensive in Brazil. I usually import them directly from China (which is what I did with the door lock) but it takes 45 to 60 days for customs clearance.

I could purchase another TI device. The only options I could find in stock atm are:

Another CC2531
SONOFF Zigbee 3.0 USB Dongle Plus (CC2652P)

What would you technically recommend?

Koenkk commented 2 years ago

The SONOFF Zigbee 3.0 USB Dongle Plus (CC2652P)

rafaelreis-r commented 2 years ago

Hey @Koenkk

Device arrived. It came preloaded with Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"zStack3x0"}'

Let me know if it requires updating (I still have to learn the update process).

I took a sniff and debug logs from the pairing process to this device:

Interesting to note this time the lock looped trying to pair to the coordinator until it gave up after 4 or 5 attempts, as you will be able to see in the dump.

Let me know what else you need me to do!

Koenkk commented 2 years ago

So it seems the device stays connected for a bit longer and z2m is able to retrieve some data from it. It is important to use the latest firmware on your adapter; otherwise the node descriptor returns an incorrect manufacturer code for Xiaomi devices. There are some instructions on how to flash the fw here: https://www.zigbee2mqtt.io/guide/adapters/#notes (on this page you can also find the correct coordinator firmware).

What worries me a bit is that the device now leaves after it doesn't receive a reply to the encrypted magic command. With the Xiaomi gateway you see the the gateway replies:

With z2m it doesn't (which of course we cannot do since we cannot encrypt this message):

I think this causes the device to leave. Seems Xiaomi doesn't want this to be device to be used with other gateways. If the coordinator firmware update doesn't solve the issue I'm quite certain this is the reason the device leaves. So in order to be able to continue we need the encryption key. I see 2 scenarios to obtain this:

Xiaomi provides us with the encryption key
We do a brute-force; however this doesn't seem to be a realistic option. The key is 128 bits which results in the following computation time (source):

rafaelreis-r commented 2 years ago

Hey @Koenkk,

Updated the firmware to Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20220219,"transportrev":2},"type":"zStack3x0"}' and redid the sniffs / logs. For some reason, z2m and zigbee-herdsman debug logs were very verbose this time.

It looks like the sniff is void of the bad FCS packets!

I hope we aren't locked out due to the encryption key. There is a 3rd way to get them, similar to what this engineer did recently with the embedded linux embedded os fw in his car. We might be able to find the key inside the source files / update files to Aqara's hubs.

It is a pretty interesting read, despite offtopic.

Koenkk commented 2 years ago

Strangely enough I don't see the magic commands anymore in this sniff but the device still leaves. What I find interesting is that the Transport key message when paired with the Xiaomi gateway uses the non-standard TC link key (at least I guess this is the transport key because it comes right after the assocation response and there are not any other transport key messages).

I guess that we need the Xiaomi encryption key to continue further with this.

wifispray commented 2 years ago

Would love to see support for this device

rafaelreis-r commented 2 years ago

@Koenkk I was able to root my G3 hub after a bit of work, and dump some zigbee info from it. I'm working with the Aqara GW rooted HA integration devs on their rep. Thread is here

They have good knowledge of many Aqara hubs rootfs, and also stock and modified fw dumps for various hubs. They have coordinator fw for the Aqara hubs dumped there as well. I just asked them if they were able to extract a coordinator fw to any of those hubs. We might have luck finding something there.

NdR91 commented 2 years ago

Would love to use this device with z2m...

github-actions[bot] commented 1 year ago

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

IamMattM commented 1 year ago

Would love to use this device with z2m...

Same for me.

waterdrop01 commented 1 year ago

I encourage anyone interested into solving this issue to report it on the Aqara support page => https://static-resource.aqara.com/html/feedback.html,

Asking them to share the encryption key. Here is a message example:

A100 z2m support

Dear Aqara team,

Looking at the comments in this youtube video (https://www.youtube.com/watch?v=LBAfbBE9-Bo), you can see that A LOT of people WILL NOT BUY the Aqara A100 because it is NOT SUPPORTED by zigbee2mqtt.

The issue is that Aqara A100 firmware is using en encryption key to communicate over zigbee (see details about the issue here => https://github.com/Koenkk/zigbee2mqtt/issues/13087) and WITHOUT this encryption key, it's nearly impossible to support the A100 into zigbee2mqtt.

Could you please consider working out a solution to add support for the A100 into zigbee2mqtt? (like sharing the key with z2m devs)

Having an open system will definitely boost your sales ;)

Thanks!

NdR91 commented 1 year ago

Thank you @waterdrop01, I just sent the ticket.

I have another questione for who already own the Aqara A100: what about the integration in Home Assistant over HomeKit Controller? Is that possible?

rafaelreis-r commented 1 year ago

Thank you @waterdrop01, I just sent the ticket.

I have another questione for who already own the Aqara A100: what about the integration in Home Assistant over HomeKit Controller? Is that possible?

It is VERY limited in HomeKit. Not a viable solution. Best path so far has been AqaraGateway + rooted hub.

NdR91 commented 1 year ago

Thank you @waterdrop01, I just sent the ticket.

I have another questione for who already own the Aqara A100: what about the integration in Home Assistant over HomeKit Controller? Is that possible?

It is VERY limited in HomeKit. Not a viable solution. Best path so far has been AqaraGateway + rooted hub.

I'll probably go with that solution.

What's the benefits using the Rooted gateway instead of the stock one?

IamMattM commented 1 year ago

I think that it allows custom HomeAssistant AqaraGateway integration to take control over Aqara gateway connected Zigbee devices ? https://github.com/niceboygithub/AqaraGateway

I got the AqaraGateway M1S-CN myself for other purposes (to register some Mi BLE sensors and get BLE encryption key once registered to use with passive BLE monitor integration)

The M1S-CN is listed as compatible so I think it would possibly allow A100 Zigbee control ...?

rafaelreis-r commented 1 year ago

@IamMattM it should be. However, if you see https://github.com/AlexxIT/XiaomiGateway3/issues/808 we still have to map out actions to create a handler for the A100 in the integration code. Logs are there but it is quite a bit of work to separate each action and map it to its id. I haven't had the time yet.

So, currently, lock shows up in HA, but I can only get locked / unlocked status.

rafaelreis-r commented 1 year ago

@Koenkk

You should take a look at https://github.com/AlexxIT/XiaomiGateway3/issues/808#issuecomment-1246169859 and the logs attached here: https://github.com/AlexxIT/XiaomiGateway3/issues/808#issuecomment-1248235091

Since the Gateway is rooted, they get Zigbee information from within the gateway OS itself, past the encryption keys. You might be able to work backwards, since we have: Sniffs, network keys from within the gateway, and that action map which I believe refers to the encrypted payload we see in the sniffs.

rafaelreis-r commented 1 year ago

@Koenkk to simplify things, I collected, grouped and cleaned up the information for you.

I did a new sniff of G3 hub (rooted) to A100 lock. Unpaired, Paired, did some door lock / unlocking actions. The difference is that now we have a debug log from mqtt installed from the root in the G3.

a100-g3hub.pcapng.zip nwkey: 0c97780090155ca7b40c4881835b3145

g3-rooted-log.zip

Check out this section in particular:

 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/recv {"cmd":"write","did":"lumi.0","id":73,"params":[{"res_name":"8.0.2085","value":"efbebc24a46e03d18f51fd7bf12f15daCC45"}]}
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/recv {"cmd":"write","did":"lumi.0","id":74,"params":[{"res_name":"8.0.2109","value":60}]}
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/send {"cmd":"write_rsp","id":73,"time":1664909266756,"did":"lumi.0","zseq":0,"results":[{"res_name":"8.0.2085","value":"efbebc24a46e03d18f51fd7bf12f15daCC45","error_code":0}]}
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: gateway <= [{'res_name': '8.0.2085', 'value': 'efbebc24a46e03d18f51fd7bf12f15daCC45', 'error_code': 0}]
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/commands {"commands":[{"command":"lumi open-with-install-code 0x3c {efbebc24a46e03d18f51fd7bf12f15dacc45} {ffffffffffffffff}","postDelayMs":0}]}
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/send {"cmd":"write_rsp","id":74,"time":1664909266757,"did":"lumi.0","zseq":0,"results":[{"res_name":"8.0.2109","value":60,"error_code":0}]}
 2022-10-04 15:47:46  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/executed {"command":"lumi open-with-install-code 0x3c {efbebc24a46e03d18f51fd7bf12f15dacc45} {ffffffffffffffff}"}
 2022-10-04 15:47:51  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/devicejoined {"nodeId":"0x63F4","deviceState":16,"deviceType":"0x00FF","timeSinceLastMessage":0,"deviceEndpoint":{"eui64":"0x54EF4410004C5112","endpoint":0,"clusterInfo":[]},"firstjoined":1}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/MessageReceived {"sourceAddress":"0x63F4","eui64":"0x54EF4410004C5112","destinationEndpoint":"0x01","clusterId":"0x0000","profileId":"0x0104","sourceEndpoint":"0x01","APSCounter":"0x9E","APSPlayload":"0x184B0A01002001","rssi":-74,"linkQuality":104}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/commands {"commands":[{"commandcli":"zcl mfg-code 0x0000"},{"commandcli":"zcl global read 0x0000 0x0001"},{"commandcli":"send 0x63f4 1 1","postDelayMs":0}]}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/executed {"command":"zcl mfg-code 0x0000"}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/executed {"command":"zcl global read 0x0000 0x0001"}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/MessagePreSentCallback {"eui64":"0x54EF4410004C5112","destinationEndpoint":"0x01","clusterId":"0x0000","profileId":"0x0104","sourceEndpoint":"0x01","APSCounter":"0x79","APSPlayload":"0x1054000100"}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/executed {"command":"send 0x63f4 1 1"}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/MessageReceived {"sourceAddress":"0x63F4","eui64":"0x54EF4410004C5112","destinationEndpoint":"0x01","clusterId":"0x0000","profileId":"0x0104","sourceEndpoint":"0x01","APSCounter":"0x9F","APSPlayload":"0x184C0A0500421161716172612E6C6F636B2E61636E303031","rssi":-74,"linkQuality":104}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/MessageReceived {"sourceAddress":"0x63F4","eui64":"0x54EF4410004C5112","destinationEndpoint":"0x01","clusterId":"0x0000","profileId":"0x0104","sourceEndpoint":"0x01","APSCounter":"0xA0","APSPlayload":"0x1854010100002001","rssi":-74,"linkQuality":104}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/send {"cmd":"report","id":2000003389,"did":"lumi.0","dev_src":"0","zseq":0,"params":[{"res_name":"8.0.2084","value":{"did":"lumi.54ef4410004c5112","mac":"54ef4410004c5112","model":"aqara.lock.acn001","version":"0.0.0_0001","zb_ver":"3.0","joined_type":1}}]}
 2022-10-04 15:47:52  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/MessageReceived {"sourceAddress":"0x63F4","eui64":"0x54EF4410004C5112","destinationEndpoint":"0x01","clusterId":"0xFCC0","profileId":"0x0104","sourceEndpoint":"0x01","APSCounter":"0xA1","APSPlayload":"0x1C5F114D0AF3FF41413E86A6879DAB55D293E7947CD188A350F68A3B104B68D0A879FE0409846D6BEDF20D95DAA19921C3905C3352A7D668D103D0CA4341295E8585645345EDFE693546","rssi":-73,"linkQuality":108}
 2022-10-04 15:47:53  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/send {"cmd":"report","id":2000003390,"did":"lumi.54ef4410004c5112","time":1664909272956,"rssi":-73,"zseq":77,"params":[{"res_name":"20.8.85","value":"{\"encry\":\"1eeebfe53ee5438344ca1242692c6aff827d1105288ff1bee180a0e653ddf8e6540c5548fbf9a5b3531ea6469e226d450c18d03e0ea0a8db06c45f2184d14b89\",\"devcry\":\"86a6879dab55d293e7947cd188a350f68a3b104b68d0a879fe0409846d6bedf20d95daa19921c3905c3352a7d668d103d0ca4341295e8585645345edfe693546\"}"}],"dev_src":"0"}
 2022-10-04 15:47:53  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/recv {"cmd":"write","did":"lumi.0","id":75,"params":[{"res_name":"8.0.2109","value":0}]}
 2022-10-04 15:47:53  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/commands {"commands":[{"command":"plugin network-creator-security close-network","postDelayMs":0}]}
 2022-10-04 15:47:53  DEBUG  gateway  192.168.1.144: MQTT on_message: gw/54EF44100025A4E4/executed {"command":"plugin network-creator-security close-network"}
 2022-10-04 15:47:53  DEBUG  gateway  192.168.1.144: MQTT on_message: zigbee/send {"cmd":"write_rsp","id":75,"time":1664909272990,"did":"lumi.0","zseq":0,"results":[{"res_name":"8.0.2109","value":0,"error_code":0}]}

This is the APS handshake during pairing. Maybe you can line it up with the packets in the sniff.

It is way beyond my knowledge, but I was wondering there is any useful info in there? Maybe the APS Key?

rafaelreis-r commented 1 year ago

@Koenkk more discovery:

It is clear to me that the devices are communicating over ZigBee Smart Energy Standard (pdf).

According to the standard:

Smart Energy profile uses the same network layer security mechanism as HA, but has further APS layer security which uses a key transferred with certicom certificates which are very secure (as it is typically utility companies using this for metering and do not want the meter reading tampered with).

Here I found more details:

If the device is setup to use Smart Energy Security Full profile, it will generate a link by performing an MMO hash on its installation code (which is globally unique).
TC sends Network Key encrypted with the link key to the joining device
After generating the link key, the joining device sends an “Association Request” to the TC, which then sends out an “Association Response”. Following this, the TC sends out the Network Key to the joining device and encrypts it with the link key established in the first step.
If you capture the OTA traffic at the joining device, you will see that the activity stops at “Association Response”, there will be no record of “Transport Key (NWK)” transaction. - which matches the pcap sniff
Joining device starts CBKE (Certificate Based Key Establishment)
Once the joining device receives the network key, it will kick off CBKE process. In this process, it will do a Match Descriptor Request for Key Establishment Cluster on the TC and the TC will reply with appropriate Match Descriptor Response.
The joining device will then use the ECC library to generate a link key based on the Certicom security certificate loaded on the device and the device’s EUI64 and initiate key establishment by issuing an Initiate Key Establishment Request to the TC. After a few back and forth messages, the TC and the joining device settle upon a new link key and start communicating with it.
The link key established at the end of the CBKE process will be the only link key for messages between these nodes. It will replace the initial link key (the one generated from installation code) in the link key table of both the nodes.

Meaning, it is indeed a completely different endeavor.

Also, it looks like Wireshark does not support Smart Energy dissection:

https://www.wireshark.org/lists/wireshark-dev/201107/msg00438.html

It looks like part of the problem is that the Smart Energy Key Establishment cluster (0x0800) is not implemented yet in the packet-zbee-aps dissector (shows up as "Unknown" in APS data). Is anyone working on this? Alternatively, does anyone know of a reference implementation of CBKE for the SE Profile?

Concern:

After learning this, do you think the TC is on Aqara's / Xiaomi servers? My suspicion was raised because I can only trigger the paring / unpairing process via Aqara App, and both my phone with the app and the hub have to be online for it to work. Remember that there is no pairing button in the A100.

If that is the case, we are probably done. Aqara will never provide their private certs to us, rendering @waterdrop01 suggestion potentially useless.

github-actions[bot] commented 1 year ago

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

ChipWolf commented 1 year ago

@Koenkk can we destale this?

github-actions[bot] commented 1 year ago

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

Hobbit44 commented 1 year ago

Could this be reopened and pinned please?

Hobbit44 commented 1 year ago

@Koenkk

TerryRhodes commented 1 year ago

I assume there's nothing to update on this yet, eh? :(

rafaelreis-r commented 1 year ago

Zigbee Smart Energy is an entirely different standard as compared to standard Zigbee protocol. It would take:

Adding support to ZSE in Z2M
Find a workaround to obtain root certificates from manufacturer, be it shared by them or obtained by reverse engineering. Without those certificates, there is no way to derive the link key for the device.

Another way would be to have the community develop a custom firmware for the A100 (N100 and other locks in that family) that supports standard zigbee.

TerryRhodes commented 1 year ago

Zigbee Smart Energy is an entirely different standard as compared to standard Zigbee protocol. It would take:

Adding support to ZSE in Z2M

Find a workaround to obtain root certificates from manufacturer, be it shared by them or obtained by reverse engineering. Without those certificates, there is no way to derive the link key for the device.

Another way would be to have the community develop a custom firmware for the A100 (N100 and other locks in that family) that supports standard zigbee.

And I assume the custom firmware path is not currently being worked on by anyone? Shame if not.

alectogeek commented 8 months ago

The lack of support for HA stops me from buying their product, LOL. Shame on you, Aqara!

NdR91 commented 8 months ago

The lack of support for HA stops me from buying their product, LOL.

Shame on you, Aqara!

At the end of all I went for a very classical electromechanical lock. I'll connect it to a Shelly 1 soon and to an UPS. Afrer that with an ESP i will manage the fingerprint sensor.

All managed by HA.

Yes, this isn't the same prpduct but imho it will work even better.

vantuyen3103 commented 5 months ago

Is there any update on this?

rafaelreis-r commented 5 months ago

A100 Bluetooth integration on HA seems to be stable now. Requires Bluetooth range.

Pairing it to HomeKit controller also works.

Over zigbee the only way is through AqaraGateway on supported gateways.

sulliwane commented 5 months ago

A100 Bluetooth integration on HA seems to be stable now. Requires Bluetooth range.

Pairing it to HomeKit controller also works.

Over zigbee the only way is through AqaraGateway on supported gateways.

May I ask what type of sensors do you get with Bluethooth connection? Here is what I have using Aqara Gateway:

Also, what does the pairing method look like when using bluetooth? (My HA supports bluetooth so it may be more reliable than the Aqara Gateway integration that sometimes does not start properly).

Thanks :)

raarts commented 4 months ago

A100 Bluetooth integration on HA seems to be stable now. Requires Bluetooth range.

Does that mean I can now use the lock with all functionality on my HA? Any more info on how to set this up, or is it automatic?

JustAnotherPU commented 2 months ago

same question here guys, can we integrate the doorlock to HA now ? I have a D200I what about this one ?

Koenkk / zigbee2mqtt

[New device support]: Aqara A100 Pro Smart Door Lock #13087

Link

Database entry

Comments

Hardware I own:

What have I done so far:

Pairing Process

A100 Pro vs A100 Zigbee

Logs I collected over the pairing procedure

External converter

Supported color modes

Color temperature range

According to the standard:

Here I found more details:

Also, it looks like Wireshark does not support Smart Energy dissection:

Concern: