Lock N100

[NikiHard]

Hey. Is there an instruction on how to connect Lock N100?

[Ernst79]

It should automagically connect, as it passively receives all messages. If not, check that you don't have reception issues. The FAQ gives some tips and tricks.

[NikiHard]

The fact is that temperature sensors are detected, but the lock is not.

[Ernst79]

Some things you can check are:

• Is it added to MiHome (preferably China region)?
• Is it within the (bluetooth) range of the dongle/bluetooth radio (possibly reinforced concerete walls blocking the signal?)
• Is discovery enabled in the BLE monitor options

[NikiHard]

I have it connected to the Aqara app, because this is the eu version of the lock

[Ernst79]

It could be that is sends different advertisements when connected to the Aqara app, compared to MiHome. Could you make a HCIDUMP of some messages. You can do this with the following command (does not work on Home Assistant OS though, due to OS limitations).

sudo hcidump --raw hci > dump.txt

[NikiHard]

dump1.txt

[Ernst79]

No "xiaomi" messages (it should contain 16 FE 95). Try again when locking your door for example.

Is is possible to get the MAC address from the lock (e.g. in the Aqara app or with hcitool lescan

[NikiHard]

dump4.txt 5 times opened closed, mac: E2:09:BA:81:CB:0C Notifications arrive on the ipad

[Ernst79]

I do see BLE advertisements of the lock

043E4C0202000146358D4CCBC6170201061309436F6E74726F6C20666F7220534231383330BC00010CCB81BA09E21F02010616FF4C0006310030D2CD925BE8060091020202A72B28020408536D61C0

But it's not in Xiaomi BLE MiBeacon format. I think that is due to the fact that it's connected to the Aqara app, and not to MiHome. We could try two things,

1. You could try to see if it is possible to connect it to MiHome (this will probably remove the connection to the Aqara app).
2. I can also try to see if I can make sense of the BLE advertisements. This will take some time, as I'm a bit busy at the moment and I cannot guarantee success, as it might be encrypted.

[NikiHard]

It does not connect to mihome, at first I tried on different regions

[Ernst79]

hmmm, too bad. I will have a look if I can make some sense of the BLE advertisements. I will add a note in the docs that the EU version seems to be not supported.

[Ernst79]

I just checked the Aqara website, but the EU version is a Zigbee version. BLE is only used to make a initial connection, as far as I understand. But I will check if I can make sense of the BLE messages anyway.

The docs already mention that only the Bluetooth version is supported.

[NikiHard]

No, I turned off the Internet on the tablet and notifications came via Bluetooth

[Ernst79]

But what version do you have, the N100 Zigbee Edition (with both Zigbee and Bluetooth) or the Mi Home edition (Bluetooth only). Or do you have a different version which isn't in the table above.

[NikiHard]

ZigBee edition, it works apple home via bluetooth

[Ernst79]

ok, clear. I'll look into the BLE advertisements, but apparently these Zigbee/EU sensors have a different format for the BLE communication.

[Ernst79]

I tried to understand the BLE advertisements, but it seems to be some strange format Below my first attempt to understand it

043E4C0202000146358D4CCBC617 normally contains the MAC, but not in this case

The following advertising data can be split up in Advertising Data (AD) elements. Each element is (normally) formatted as follows:

• 1st byte: length of the element (excluding the length byte itself) (in hex, so e.g. 13 in hex is 19 in decimals)
• 2nd byte: AD type – specifies what data is included in the element
• AD data – one or more bytes - the meaning is defined by AD type

020106 length 2, AD type 01 = flags, 06 means Bit 1 : “LE General Discoverable Mode” Bit 2: “BR/EDR Not Supported.” 1309436F6E74726F6C20666F7220534231383330 --> length 19, 09 means Complete Local Name = Control for SB1830 BC0001 0CCB81BA09E2 1F--> length 188???? This seems to be wrong, non-standard. It does however contain the MAC reversed 020106 length 2, AD type 01 = flags, 06 means Bit 1 : “LE General Discoverable Mode” Bit 2: “BR/EDR Not Supported.” 16FF4C0006310030D2CD925BE8060091020202A72B2802 --> this will be the useful data normally 0408536D61 length 4, 08 means shortened Local Name = Sma C0 --> RSSI = -64

So, we have a short name Sma, a long name Control for SB1830. We have a strange part starting with BC, which is normally the length but not in this case. And we have a long bytestring that contains the data probably. 16FF4C0006310030D2CD925BE8060091020202A72B2802

That's it for now. I'll look further later

[NikiHard]

This is not a lock, sma is a lock, and control for sb1830 is a sound card

[Ernst79]

All the above info is from one message, so has to be sent by one device. Not sure what it is. It contains the Mac you gave (reversed). Not sure what a sound card has to do with a lock.

[NikiHard]

Maybe you still need a log?

[Ernst79]

Not yet, I will try a different message. I just picked one.

[Ernst79]

But are you sure about the MAC address.?

[NikiHard]

He can change mac address?

[Ernst79]

Aha, that’s called randomized Mac. Unfortunately that wil make it impossible to implement, I’m afraid

[NikiHard]

As I understand it, it resets when you untie it from the apple homekit

[Ernst79]

Ok, that changes it, I’ll try further tomorrow.

[Ernst79]

Sorry for the long silence, but I still can't solve the puzzle. Unfortunately, the format is totally different compared to the normal MiHome (MiBeacon) xiaomi messages. Moreover, there are some strange things in the messages (bytes that should represent the length are giving weird lengths), which prevents me from splitting it up in the different parts.

[NikiHard]

Can send another log?

[Ernst79]

Sure, we can always try.

[NikiHard]

Sorry for taking so long, the command hcidump --raw hci> dump2.txt did not work for me mac lock address EF:47:E1:19:75:92 Sma EF:47:E1:19:75:92 Smart Door Lock N100 6F16 dump2.txt

[Ernst79]

Can't find any message from your device in the dump, unfortunately.

[Ernst79]

I think your version of the lock uses the following to communicate:

The lock even contains a certified Apple MFi chip, thanks to which it is possible to seamlessly connect with Apple devices.

So, I think the initial communication is done via BLE, but when everything is set up, it is using the MFi chip to communicate with Apple Homekit.

[Ernst79]

Closing this issue, as this version can't be supported unfortunately. See my previous post.

[almirus]

@Ernst79, Hi please explain how this version of the lock communicates with an Android phone, as it doesn't have HomeKit and Zigbee, so it must be using Bluetooth protocol.

[Ernst79]

There are two versions of the N100, one is Bluetooth only, the other is Bluetooth (for the initial setup) and Zigbee.

I don't know how the Zigbee version communicates with an android phone, don't have this lock myself.

[almirus]

@Ernst79 via Bluetooth

[Ernst79]

The first "device" is using the iBeacon format (company id 0x004C), the second "device" is using company id 0x4D4C which is not an official company id (as in, it is not registered at the Bluetooth organization). the strange this is that it isn't using the Xiaomi Mibeacon format. (the N100 that is implemented in BLE monitor was using the Mibeacon format with 0xFE95 as UUID.

When looking at the data of 0x4D4C in your screenshot (801E0F130100 B3C225F44DE2) you can see that the second part contains your MAC address (reversed per two characters E24DF425C2B3 The first part may contain data, but you will have to figure out which byte means what.