Wrong data format mi-like with encryption

[Ernst79]

I'm the developer of the Passive BLE Monitor integration and we received an issue that a user's sensor didn't work when he set the sensor to advertisement type Mi with encryption enabled. I checked it and came to the same conclusion.

So I compared a HCI dump message from stock firmware (first line in the table below) to a message from ATC firmware with advertisement type Mi and encryption enabled (second line in the table). As you can see, three bytes are missing (01 06 1A). Is it possible to fix/change this.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HCI  Evt Len Sub Num Evt  Peer -------MAC-------   Len Len Type Val Len  AD  Xiaomi Frame Product Frame     MAC (LE)        ----------------------PAYLOAD------------  RSSI
type code    evt rep type addr                             flag         type  UUID   ctrl  type    cnt                          cypher            ext.cnt     MAC tag
 A    B  C    D  E    F    G          H            I   J    K   L   M    N     O      P     Q      R           S            
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 04   3E 2A  02  01   00   00  C7 A8 D9 38 C1 A4   1E  02   01  06  1A   16  95 FE  58 58  5B 05   90   C7 A8 D9 38 C1 A4   2D E3 2D 7B 49        00 00 00  EF 49 D6 2E  CE   LYWSD03MMC (default firmware)
 04   3E 27  02  01   00   00  B2 18 8D 38 C1 A4   1B  1A                16  95 FE  58 58  5B 05   2C   B2 18 8D 38 C1 A4   A1 BA 47 2B 4C        00 00 00  1A 7D A5 6F  CD   LYWSD03MMC (ATC, mi-like, encrypted)

Possibly related to #73 where they also seem to have issues with the encryption?

[pvvx]

Ver 2.9 - Added additional id flags to advertising packages
Perhaps this will help if your program does not parse BLE Advertising Packages into blocks.

[0x02,0x01,0x06] is inserted at the beginning of the packet:

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/

Data Type Value	Data Type Name	Reference for Definition
0x01	«Flags»	Bluetooth Core Specification:Vol. 3, Part C, section 8.1.3 (v2.1 + EDR, 3.0 + HS and 4.0)Vol. 3, Part C, sections 11.1.3 and 18.1 (v4.0)Core Specification Supplement, Part A, section 1.3

BLUETOOTH SPECIFICATION:

The Flags AD type contains several flag bits interpreted as boolean values.
Flags used over the LE physical channel are:
• Limited Discoverable Mode
• General Discoverable Mode
• BR/EDR Not Supported
• Simultaneous LE and BR/EDR to Same Device Capable (Controller)
• Simultaneous LE and BR/EDR to Same Device Capable (Host)
The Flags AD type shall not be included in the scan response data. The advertising data shall not contain more than one instance of the Flags AD type. The Flags AD type shall be included in the advertising data if any of the bits are non-zero. The Flags AD type may be omitted from the advertising data if all of the bits are zero. The format of Flags AD type is defined in Table 18.1.

---

18.1 FLAGS
The Flags field may be zero or more octets long. This allows the Flags field to
be extended while using the minimum number of octets within the data packet.
All octets that are 0x00 are not transmitted as long as all other octets after that
octet are also 0x00.

Value	Description	Bit	Information
0x01	Flags	0	LE Limited Discoverable Mode
		1	LE General Discoverable Mode
		2	BR/EDR Not Supported (i.e. bit 37 of LMP Extended Feature bits Page 0)
		3	Simultaneous LE and BR/EDR to Same Device Capable (Controller) (i.e. bit 49 of LMP Extended Feature bits Page 0)
		4	Simultaneous LE and BR/EDR to Same Device Capable (Host) (i.e. bit 66 of LMP Extended Feature bits Page 1)
		5..7	Reserved

Possibly related to #73 where they also seem to have issues with the encryption?

Encryption does not include this block. This is just an additional heading.
The program should split BLE advertising packages into blocks and analyze mijia flags, and not take values from the package by offset from the beginning of the package.

[pvvx]

Mijia Telink samples
mi_release_version_4_1_1\ble_sdk_multimode\vendor\common\mijia_ble\libs\common\mible_beacon.c

[Ernst79]

Thanks, I’ll check tomorrow.

BLE monitor is splitting the message up, but it first does a check on this 02 01 06 part to be present. As it was missing, parsing of the message failed. I could have worked around this, but it seems better to have the exact same format as the original stock firmware.

Anyway, thanks for the fast response, I’ll test it tomorrow.

[pvvx]

I could have worked around this, but it seems better to have the exact same format as the original stock firmware.

The project does not aim to make a fake Xiaomi LYWSD03MMC.

The inclusion of extended advertising is also possible. Then the length of the data in the packet will be kilobytes ... :)

Anyway, thanks for the fast response, I’ll test it tomorrow.

These three bytes now increase battery consumption by 5%. This is what the 'users' wanted. :)

[Ernst79]

I can confirm it's ok working now. Thanks

The project does not aim to make a fake Xiaomi LYWSD03MMC.

I do understand. I just noticed a difference in the BLE advertising format, which made BLE monitor not parsing the message (due to the check on 02 01 06 (or 15 16 95) being present in the message). This check works for all other Xiaomi MiBeacon sensors, so my thought was that it would be the easiest to fix in your firmware.

These three bytes now increase battery consumption by 5%. This is what the 'users' wanted. :)

Hmmm, that's significant. Only by adding these three bytes? I'll leave it up to you, to decide on whether you keep the change or not. It can also be fixed on the side of BLE monitor, if you decide to reverse.

[50494554524F]

i was testing too... now packets are decrypted but read randomly 5-15 minutes by homeassistant, while i have set the firmware to send the packets every minute

if i can, as it's permitted by the protocol, i would go back to firmware 2.8 and correct ble_monitor component...

thanks both

[pvvx]

I exaggerated that 5%.
More precisely, then:
the length of the message is about 40 characters + preamble
Increase in TX duration no more than 3/40.
TX has the highest current, which is more than two times than all other operating modes of the chip. This is at +3 dB.
Reducing TX power has a stronger effect on average consumption, levels over 0 dB.
As a result, these 3 bytes affect the level of energy consumption of one percent.

if i can, as it's permitted by the protocol, i would go back to firmware 2.8 and correct ble_monitor component...

In version 2.8 there are errors in the mode of working with encrypted advertisements in alternation by count.
The change time for encrypted advertisements is 16 measurements from the sensor
For LYWSD03MMC, this is 160 seconds = 16 * 4 ad interval periods with default settings..
Temperature, voltage and battery values are rounded off, recorded and broadcast in the next 64 advertisements.

This is due to the fact that the coding of the package requires energy. It is necessary to encode 3 types of packet - with temperature, with humidity, with battery. This is done once on 64 advertising.

[Ernst79]

@50494554524F In addition, let me explain how BLE monitor works. These 64 advertisements are all the same, with the same frame counter (message number). BLE monitor checks this frame counter and only uses one message. If another message is received with the same frame counter, it will ignore it (as it is the same data). So, update interval will be about 160 seconds in HA (which is already faster than the stock firmware, which has a 10 minute interval. If you want more/faster updates, use the custom advertisement type instead.

[pvvx]

These 64 advertisements are all the same, with the same frame counter (message number). BLE monitor checks this frame counter and only uses one message.

64 Advertisings -> 4 message from different data recurring 16 times. 16 Temperature, 16 humidity, 16 battery + 16 empty message for compatibility with the original. All 64 have the same Frame Counter (Message Number).

[pvvx]

So, update interval will be about 160 seconds

The update interval depends on the settings:

1. Advertising interval
2. Number of Advertising Intervals until the next measurement by the sensor

As a result, the data update time will be equal to 16 measurement intervals from the sensor.

Minimum:

Data update time (next Frame Counter)= 62.5 * 1 * 16 = 1000 ms = 1 sec

Maximum:

Data update time (next Frame Counter)= 10000 * 25 * 16 = 4000000 ms = 4000 sec

[50494554524F]

really clear now, thanks