LYWSD03MMC support (implemented since 0.6.0)

Magalex2x14 commented 4 years ago

After a deeper study of the information available on the Internet, it seems that there is hope for the implementation of support for other sensors (as far as I understand, support for sensors with a method similar to ours is implemented in ESPHome). In addition to the already implemented work with LYWSDCGQ, I talk about:

~~LYWSD02~~ (rectangular body, E-Ink) - dump received, work is done, supported since v0.4.0...
~~HHCCJCY01~~ (MiFlora) - dump received, work is done, supported since v0.4.0...
~~CGG1~~ (round body, E-Ink) - dump received, work is done, supported since v0.4.0...
LYWSD03MMC ( square body, segment LCD) - ~~dump received, need some help, start reading from this post.~~ Collected tech.details summary. The decryption issue has been resolved, ~~only the time for implementation is needed. Testing~~ Released

ATTENTION! This topic discusses only questions regarding the operation of LYWSD03MMC sensors and methods for extracting encryption keys.

~~UPD. The dump didn’t help... Apparently, the advertisements are encrypted. But there is still hope!~~

JJussi commented 4 years ago

Have you checked: https://habr.com/ru/post/452558/ (if needed google translate do good work)

I have LYWSD02 and here is what it sending:

hcidump --raw | grep -v "3F 58 70" HCI sniffer - Bluetooth packet analyzer ver 5.50 device: hci0 snap_len: 1500 filter: 0xffffffff

04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 DF 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 D8 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C5 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 DF 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 CD 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 D9 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 CE 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 CF 04 3E 28 02 01 00 00 78 B8 72 7D 5B 3F 1C 02 01 06 03 02 1A 18 14 16 95 FE 70 20 5B 04 4F 78 B8 72 7D 5B 3F 09 06 10 02 4A 01 E1 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C4 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 CC 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C4 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 CF 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C4 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 C9 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 CE 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 DF 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 BF 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C3 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 CF 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 C5 04 3E 2B 02 01 03 01 20 AF 16 2D C1 2E 1F 1E FF 06 00 01 09 20 02 BE C7 A9 2E B4 17 E3 07 73 B4 62 81 C9 1F 5B 17 73 F8 3A F3 03 F7 75 C9 04 3E 2B 02 01 00 00 0B 32 AD 1A B1 CC 1F 02 01 1A 1B FF 75 00 42 04 01 01 6F CC B1 1A AD 32 0B CE B1 1A AD 32 0A 01 98 00 00 00 00 00 D4

JJussi commented 4 years ago

Sorry, this capture have this "all ready" supported (round one) sensor on the range... But you can easily filter it away...

https://www.dropbox.com/s/kbk98bzyue84fu5/dump.txt?dl=0

Values where 33% and 26,7C thru whole capture time.

Magalex2x14 commented 4 years ago

Russian is my native language ) Yes, I saw this article. The fact is that its author uses a connection to the sensor. This is not our method ) We parse broadcast data, which greatly saves battery power and gives other pluses as a result from processing a continuous data stream (look at the description of the use_median option in readme.md, for example).

JJussi commented 4 years ago

Yes, I know that you use a different method, but of course, received data should be at same format. So if you can "inject" those hcidump results to your code, you should see if your code works. Hopefully, my dumps help...

langerhans commented 4 years ago

I just found another model that seems to be fairly new: LYWSD03MMC Some shops have it for 18$ for three of them which is pretty cheap. Sadly seem to be sold out right now. Unsure yet if it broadcasts similarly to the other devices. I plan to buy some and will let you know when I get a chance to play with them. Also trying to find the MiFlora for cheap somewhere, but no luck apart from Amazon around here.

Magalex2x14 commented 4 years ago

I pushed pre-release with other sensors support. Installation in HACS is also available if you enable "Show betas" on the integration page. A MiFlora dump is still needed to implement support for other MiFlora sensor features besides temperature. Thanks @JJussi and Sergey Sazonov for LYWSD02 and CGG1 dumps!

Ernst79 commented 4 years ago

I can only confirm that the original sensor still works fine with the new code. I new attributes (rssi and sensor type are also available). I don't have any of the other sensors, so cannot test that.

If you are finished, I can do a final review if you want. But you have to make a PR than.

Magalex2x14 commented 4 years ago

There is still work to do after we have MiFlora dump - at least new classes for its sensors will be needed. While I would not like to do PR in the master. Plus there are a few more details that I would like to correct before being released to the master. After that, of course, we will do everything right.

JJussi commented 4 years ago

Thank you! I can confirm that LYWSD02 works perfectly!

Quppa commented 4 years ago

I just found another model that seems to be fairly new: LYWSD03MMC Some shops have it for 18$ for three of them which is pretty cheap. Sadly seem to be sold out right now. Unsure yet if it broadcasts similarly to the other devices. I plan to buy some and will let you know when I get a chance to play with them. Also trying to find the MiFlora for cheap somewhere, but no luck apart from Amazon around here.

I wonder if it's this model? If so, I have one on the way - happy to share a dump of its data once it arrives (unless someone else beats me to it).

JJussi commented 4 years ago

Looks like.. As it says there:

Brand | XIAOMI Mijia Model | LYWSD03MMC

Magalex2x14 commented 4 years ago

I noticed that the LYWSD02 and 03 sensors do not show the battery status on the display... And the fact is that 02 does not broadcast it. Curious, will 03 do it?

P.S. Tomorrow I expect to get a MiFlora sensor, and on the weekend I plan to finish with its full support.

Magalex2x14 commented 4 years ago

I just pushed v0.4.0-beta.2 pre-release with MiFlora full support. I found that MiFlora does not broadcasts battery status (googled it - people write that it was disabled in the latest firmware versions). Another strange thing is that MiFlora repeats the measurement data several times (the packets are different, rssi is different, but the packet_id is identical) - I had to check this before processing. Other sensors have never sent me packets with the same id. As a result, it turned out that MiFlora updates the data once a minute approximately...

ma-zal commented 4 years ago

Can you mention in documentation (in README), how often devices are broadcasting the sensors value? Based on your investigation you probably know it. :-) It will be also great to mention, that the broadcasting interval is fixed (cannot be changed).

I am asking for this info, because my LYWSDCGQ is reporting every minute - and I am confused if it is correct default behavior, or it will drain the baterry fast.

Ernst79 commented 4 years ago

Do you mean the interval the data is updated in Home Assistant? This is mentioned in the README and is a setting (period)

Period (positive integer)(Optional) The period in seconds during which the sensor readings are collected and transmitted to Home Assistant after averaging. Default value: 60

So, yes, 1 minute is default, but you can change it if you want.

Or do you mean the interval the actual sensor sends out it's data? I don't think you can change the interval LYWSDCGQ is actually sending data, am I right @Magalex2x14 ?

ma-zal commented 4 years ago

This is mentioned in the README and is a setting (period)

But as I understand, this period parameter is just filtering the incomming data to avoid too often updating (and storing) in Home-Assistant database. But this period parameter is not affecting, how often the Xiaomi device is broadcasting data via BLE. So Xiaomi device has no idea, that some period value is defined in integration script, and Xiaomi still reporting with same speed. Is it correct?

... I am asking for documentation of BLE data broadcasting intervals.

Magalex2x14 commented 4 years ago

It may still be worthwhile to clarify the sensor broadcast interval and the component measurement period (period option)... For example, my three LYWSDCGQs send 20-25 unique messages at RSSI -75 ..- 70 dBm. With the option period = 60, the component accumulates 20-25 messages received per minute, and after the period expires, averages them and updates the sensor status in HA. The period does not affect the consumption of the sensor. It only affects the HA sensor update rate and the number of averaged values.

P.S. Ernst is wright, we can't change sensor broadcasting interval. P.P.S. Yes, ma-zal, correct.

Magalex2x14 commented 4 years ago

I am asking for documentation of BLE data broadcasting intervals.

Why not... I'm sure of the broadcast interval LYWSDCGQ and MiFlora that I have. For the rest, statistics from users are needed (especially since the sensor attributes have the number of received packets for the measurement period - "last mean of" or "last median of").

Ernst79 commented 4 years ago

@Magalex2x14 In the README (first section), you mentioned the following:

this custom component is parsing the Bluetooth Low Energy packets payload that is emitted each second by the sensor

Not sure if this is correct

Magalex2x14 commented 4 years ago

Yes, that’s true, but not quite. In fact, it sends about every second, but not all packets contain measurements, and, as it turned out in the case of MiFlora, not all of them are unique... We need to change the wording, yes...

Ernst79 commented 4 years ago

I tried to check the "last mean of" value, but I now see I have the same issue as in #12. The sensor had stopped yesterday. Apparently not a dead battery, as I thought yesterday.

Ernst79 commented 4 years ago

Ok, did a check.

LYWSDCGQ Sensor at 20 cm from raspberry pi,
rssi = -58 dBm,
I get between 19 till 24 readings (varies a bit) per 60 seconds (last mean of).

Quppa commented 4 years ago

I got hold of a LYWSD03MMC device. Here's a dump - hope it helps: https://gist.github.com/Quppa/f3474a915ee6fd81df196bc4140d97c1

I think the temperatures ranged between 22.4 and 23.0 degrees and the humidity between 41% and 48%.

Disappointingly it doesn't have an e-ink display like the LYWSD02. It's also smaller than I expected - I thought it'd be like a half-size LYWSD02, but it's quite petite.

Magalex2x14 commented 4 years ago

Thank you, @Quppa . I'll look at it soon.

Magalex2x14 commented 4 years ago

I think the temperatures ranged between 22.4 and 23.0 degrees and the humidity between 41% and 48%.

@Quppa, for what period of time this dump? I do not see useful data in it. There are Xiaomi packages, but they are small in size, and do not contain data in the usual format. In addition to the service data, the remaining bytes are the same in all 102 packets (except for the last byte, which is RSSI, and which is quite high - apparently, the sensor was close to the host). I also see LYWSDCGQ 58:2D:34:35:95:0E.

I propose to do the following: connect to the new sensor using the official Xiaomi application (called the Mi Home in the Appstore for iOS), get the data, unload the application, place the sensor near your LYWSDCGQ, and take a dump of about five minutes.

Quppa commented 4 years ago

The format definitely seems to be different. The same packets get broadcast a lot.

I successfully connected the device to the Xiaomi Android app (after setting my region to China - the newer sensor models don't show up when the region is Singapore) and saw the historical data, which I gather is stored on these devices.

I dumped some more data and fed it through the existing parser (adding '585B05': ["LYWSD03MMC", 0] to XIAOMI_TYPE_DICT) and got a few more packets, but it's not clear to me what bytes might correspond to the temperature and humidity readings. The temperature was 27.2 ~ 27.7 degrees and the humidity 45 ~ 46%.

{'rssi': -43, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 137}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 89 C7 A8 D9 38 C1 A4 08 D5
{'rssi': -47, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 138}
> 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 8A C7 A8 D9 38 C1 A4 09 5B 0A 2C 11 00 00 00 BA D7 8D 0F D1
{'rssi': -62, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 139}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 8B C7 A8 D9 38 C1 A4 08 C2
{'rssi': -44, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 140}
> 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 8C C7 A8 D9 38 C1 A4 D9 2D 5F 24 A5 00 00 00 AE 9A 85 DD D4
{'rssi': -49, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 141}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 8D C7 A8 D9 38 C1 A4 08 CF
{'rssi': -49, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 142}
> 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 8E C7 A8 D9 38 C1 A4 25 B9 74 08 9D 00 00 00 11 F6 41 5C CF
{'rssi': -50, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 143}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 8F C7 A8 D9 38 C1 A4 08 CE
{'rssi': -50, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 144}
> 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
{'rssi': -50, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 145}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 91 C7 A8 D9 38 C1 A4 08 CE
{'rssi': -44, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 146}
> 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 92 C7 A8 D9 38 C1 A4 43 56 E2 51 BB 00 00 00 AC 12 98 1A D4
{'rssi': -45, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 147}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 93 C7 A8 D9 38 C1 A4 08 D3
{'rssi': -44, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 148}
> 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 94 C7 A8 D9 38 C1 A4 2F 8B 5F 69 02 00 00 00 2F 91 41 B7 D4
{'rssi': -41, 'mac': 'A4C138D9A8C7', 'type': 'LYWSD03MMC', 'packet': 149}
> 04 3E 1F 02 01 00 00 C7 A8 D9 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 95 C7 A8 D9 38 C1 A4 08 D7

Magalex2x14 commented 4 years ago

Thank you. Long packets look promising... There is definitely nothing in the short ones - there are only two bytes after the second MAC, one of which is always 08, and the second is RSSI.

Magalex2x14 commented 4 years ago

Hmm... Here are the payload from the even (long) packets:

09 5B 0A 2C 11 00 00 00 BA D7 8D 0F
D9 2D 5F 24 A5 00 00 00 AE 9A 85 DD 
25 B9 74 08 9D 00 00 00 11 F6 41 5C 
2D E3 2D 7B 49 00 00 00 EF 49 D6 2E  
43 56 E2 51 BB 00 00 00 AC 12 98 1A  
2F 8B 5F 69 02 00 00 00 2F 91 41 B7

I do not see any system except three zeros in the middle and always the same length. There is not a single identical byte (at least this indicates the absence of length info - the length should be the same). Bytes differ greatly, which is not like temperature and humidity, varying within small limits... There is also no type byte that must also be repeated. Encrypted?

Magalex2x14 commented 4 years ago

I’ll make a release from the current beta, because nothing is clear with the new sensor.

vdarios commented 4 years ago

Dump from four LYWSD03MMC devices.

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 4E FF C3 5C 38 C1 A4 65 54 A9 7E 0B 01 00 00 35 6F 5B C8 B5

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 50 FF C3 5C 38 C1 A4 3F 9F A4 CC 21 01 00 00 6C 3E 5F 15 C5

2.

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 4E 97 48 1F 38 C1 A4 CB 37 49 90 08 01 00 00 A8 E0 5A 44 AE

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 50 97 48 1F 38 C1 A4 68 B3 85 27 9E 01 00 00 40 D4 23 F9 AD

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 BE 97 48 1F 38 C1 A4 FC 25 81 BE BE 01 00 00 7C CD 04 FC AC

3.

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 C1 4C 53 07 38 C1 A4 E5 84 61 F6 CD 01 00 00 48 92 85 29 BA

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 C3 4C 53 07 38 C1 A4 2C AC D8 2D 0C 01 00 00 59 1D 1B E9 BA

4.

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 C4 8A FC F0 38 C1 A4 57 EB 19 19 A7 01 00 00 75 E0 8C CF B4

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 C6 8A FC F0 38 C1 A4 3C FA DB 79 A8 01 00 00 0D 02 77 F7 BA

Magalex2x14 commented 4 years ago

Quppa ...ranged between 22.4 and 23.0 degrees and the humidity between 41% and 48%. Intermediate packets contain only one byte as payload - 08.

09 5B 0A 2C 11 00 00 00 BA D7 8D 0F
D9 2D 5F 24 A5 00 00 00 AE 9A 85 DD 
25 B9 74 08 9D 00 00 00 11 F6 41 5C 
2D E3 2D 7B 49 00 00 00 EF 49 D6 2E  
43 56 E2 51 BB 00 00 00 AC 12 98 1A  
2F 8B 5F 69 02 00 00 00 2F 91 41 B7

 Xiaomi  payload   Sensor    packet        MAC                                                  RSSI
  UUID    type?     type        №

 95 FE     30      58 5B 05    89    C7 A8 D9 38 C1 A4    08                                     D5
 95 FE     58      58 5B 05    8A    C7 A8 D9 38 C1 A4    09 5B 0A 2C 11 00 00 00 BA D7 8D 0F    D1
 95 FE     30      58 5B 05    8B    C7 A8 D9 38 C1 A4    08                                     C2
 95 FE     58      58 5B 05    8C    C7 A8 D9 38 C1 A4    D9 2D 5F 24 A5 00 00 00 AE 9A 85 DD    D4
 95 FE     30      58 5B 05    8D    C7 A8 D9 38 C1 A4    08                                     CF
 95 FE     58      58 5B 05    8E    C7 A8 D9 38 C1 A4    25 B9 74 08 9D 00 00 00 11 F6 41 5C    CF
 95 FE     30      58 5B 05    8F    C7 A8 D9 38 C1 A4    08                                     CE
 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
 95 FE     30      58 5B 05    91    C7 A8 D9 38 C1 A4    08                                     CE
 95 FE     58      58 5B 05    92    C7 A8 D9 38 C1 A4    43 56 E2 51 BB 00 00 00 AC 12 98 1A    D4
 95 FE     30      58 5B 05    93    C7 A8 D9 38 C1 A4    08                                     D3
 95 FE     58      58 5B 05    94    C7 A8 D9 38 C1 A4    2F 8B 5F 69 02 00 00 00 2F 91 41 B7    D4
 95 FE     30      58 5B 05    95    C7 A8 D9 38 C1 A4    08                                     D7

vdarios:

65 54 A9 7E 0B 01 00 00 35 6F 5B C8
3F 9F A4 CC 21 01 00 00 6C 3E 5F 15

CB 37 49 90 08 01 00 00 A8 E0 5A 44
68 B3 85 27 9E 01 00 00 40 D4 23 F9
FC 25 81 BE BE 01 00 00 7C CD 04 FC

E5 84 61 F6 CD 01 00 00 48 92 85 29
2C AC D8 2D 0C 01 00 00 59 1D 1B E9

57 EB 19 19 A7 01 00 00 75 E0 8C CF
3C FA DB 79 A8 01 00 00 0D 02 77 F7

Interesting, but still not clear...

Magalex2x14 commented 4 years ago

I feel we need to look for a cryptographer )

Magalex2x14 commented 4 years ago

Updated post for clarity. For completeness of information, we probably need dump with the moment when the packet counter is reset to zero (maybe something interesting happens there)...

vdarios commented 4 years ago

Here is the dump with packet counter is reset to zero. If needed I upload full dump file. I hope this will help.

First device

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 FE 8A FC F0 38 C1 A4 76 F3 B1 35 9E 02 00 00 51 4D 37 81 B2

04 3E 1F 02 01 00 00 8A FC F0 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 FF 8A FC F0 38 C1 A4 08 B1 

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 00 8A FC F0 38 C1 A4 27 41 A9 4B 68 03 00 00 C7 2F F2 0D BB 

04 3E 1F 02 01 00 00 8A FC F0 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 01 8A FC F0 38 C1 A4 08 BB 

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 02 8A FC F0 38 C1 A4 2F DD DE 38 7D 03 00 00 7E 2A DA 91 BA 

04 3E 1F 02 01 00 00 8A FC F0 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 03 8A FC F0 38 C1 A4 08 B2 

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 04 8A FC F0 38 C1 A4 EE EE 1A 28 D2 03 00 00 B9 58 FE CA BA 

04 3E 1F 02 01 00 00 8A FC F0 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 05 8A FC F0 38 C1 A4 08 BB 

04 3E 2A 02 01 00 00 8A FC F0 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 06 8A FC F0 38 C1 A4 F1 6D 5B D0 D2 03 00 00 A9 48 05 CF B2

Second device

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 FE FF C3 5C 38 C1 A4 75 C6 A0 7D 05 02 00 00 1D BB DA 42 B8 

04 3E 1F 02 01 00 00 FF C3 5C 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 FF FF C3 5C 38 C1 A4 08 B7 

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 00 FF C3 5C 38 C1 A4 83 65 AB 58 7C 03 00 00 5A CC A0 31 B7

04 3E 1F 02 01 00 00 FF C3 5C 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 01 FF C3 5C 38 C1 A4 08 B2 

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 02 FF C3 5C 38 C1 A4 FA DB BF 47 3D 03 00 00 C8 F7 D5 78 B7

04 3E 29 02 01 00 00 FF C3 5C 38 C1 A4 1D 02 01 06 19 16 95 FE 58 58 5B 05 03 FF C3 5C 38 C1 A4 E5 51 8F 5C 03 00 00 52 B9 01 81 B7 

04 3E 1F 02 01 00 00 FF C3 5C 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 04 FF C3 5C 38 C1 A4 08 B7 

04 3E 2A 02 01 00 00 FF C3 5C 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 05 FF C3 5C 38 C1 A4 35 DC 2D 7B AB 03 00 00 AD 1F C0 A7 B7 

04 3E 1F 02 01 00 00 FF C3 5C 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 06 FF C3 5C 38 C1 A4 08 C7

Third device

04 3E 1F 02 01 00 00 4C 53 07 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 FE 4C 53 07 38 C1 A4 08 C7 

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 FF 4C 53 07 38 C1 A4 C6 0B 7F BE 56 02 00 00 4D 01 18 A0 C6 

04 3E 1F 02 01 00 00 4C 53 07 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 00 4C 53 07 38 C1 A4 08 C2 

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 01 4C 53 07 38 C1 A4 73 32 AB 70 73 03 00 00 ED 1F E5 6B C6 

04 3E 1F 02 01 00 00 4C 53 07 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 02 4C 53 07 38 C1 A4 08 C3 

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 03 4C 53 07 38 C1 A4 5D FB 68 2D 23 03 00 00 CC 77 09 46 C3 

04 3E 29 02 01 00 00 4C 53 07 38 C1 A4 1D 02 01 06 19 16 95 FE 58 58 5B 05 04 4C 53 07 38 C1 A4 B2 5E 3F B2 03 00 00 EE 34 84 F3 C6 

04 3E 1F 02 01 00 00 4C 53 07 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 05 4C 53 07 38 C1 A4 08 C7 

04 3E 2A 02 01 00 00 4C 53 07 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 06 4C 53 07 38 C1 A4 E7 D3 D9 7E CC 03 00 00 D1 48 7F A5 C7

Fourth device

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 FE 97 48 1F 38 C1 A4 15 75 69 35 E8 02 00 00 DD 51 F5 6F AF 

04 3E 1F 02 01 00 00 97 48 1F 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 FF 97 48 1F 38 C1 A4 08 AD 

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 00 97 48 1F 38 C1 A4 E9 62 A3 9C B6 03 00 00 0F FB A4 25 AE 

04 3E 1F 02 01 00 00 97 48 1F 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 01 97 48 1F 38 C1 A4 08 AD 

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 02 97 48 1F 38 C1 A4 E5 39 26 55 93 03 00 00 C7 7F 1E EA AD 

04 3E 29 02 01 00 00 97 48 1F 38 C1 A4 1D 02 01 06 19 16 95 FE 58 58 5B 05 03 97 48 1F 38 C1 A4 AD 80 56 0B 03 00 00 67 86 AB E2 AC 

04 3E 1F 02 01 00 00 97 48 1F 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 04 97 48 1F 38 C1 A4 08 AC 

04 3E 2A 02 01 00 00 97 48 1F 38 C1 A4 1E 02 01 06 1A 16 95 FE 58 58 5B 05 05 97 48 1F 38 C1 A4 1D 04 7B 78 4C 03 00 00 ED 2C FF AA AE 

04 3E 1F 02 01 00 00 97 48 1F 38 C1 A4 13 02 01 06 0F 16 95 FE 30 58 5B 05 06 97 48 1F 38 C1 A4 08 AD

anthony-hull commented 4 years ago

Hmm... Here are the payload from the even (long) packets:
09 5B 0A 2C 11 00 00 00 BA D7 8D 0F
D9 2D 5F 24 A5 00 00 00 AE 9A 85 DD 
25 B9 74 08 9D 00 00 00 11 F6 41 5C 
2D E3 2D 7B 49 00 00 00 EF 49 D6 2E  
43 56 E2 51 BB 00 00 00 AC 12 98 1A  
2F 8B 5F 69 02 00 00 00 2F 91 41 B7  
I do not see any system except three zeros in the middle and always the same length. There is not a single identical byte (at least this indicates the absence of length info - the length should be the same). Bytes differ greatly, which is not like temperature and humidity, varying within small limits... There is also no type byte that must also be repeated. Encrypted?

I opened the sensor up and found a TLSR8251 SoC powering it. According to the spec sheet there is onboard AES encryption and decryption and elliptical curve cryptography. http://wiki.telink-semi.cn/doc/ds/PB_TLSR8251-E_Product%20Brief%20for%20Telink%20BLE%20SoC%20TLSR8251.pdf

Magalex2x14 commented 4 years ago

Yes, it seems that we are faced with exactly this. By itself, this fact should not scare us, I think we need to understand the procedure of data exchanging between the sensor and the Xiaomi application. I am infinitely far from a crypto expert, but can a key exchange happen when a connection is established? Can I get these keys? If so, how long do these keys last? Or maybe this happens automatically at the hardware level, after the connection is established, and then everything is transparent? The sensor constantly sends broadcast advertisements, so it is assumed that they can be received, otherwise why spend the battery on this?

langerhans commented 4 years ago

The app will connect to the sensor to read the data as far as I understand. So I don't think there is any key exchange. As a matter of fact, if you use any Bluetooth utility that can connect, you'll be able to just read the value in clear. See this screenshot, where 0x087A is the temp (2170/100=21.7°C) and 0x35 is the humidity (53%).

The unit has a bunch of testpads on the PCB and I traced some of them already. At some point I'll see if any of them communicate so we could e.g. read the Firmware. If that doesn't work I'll intercept an OTA update through the app and then see what's to be found in there.

ijustlearn commented 4 years ago

I also have the same equipment : LYWSD03MMC , I hope you can complete the development, thank you!

theosnel commented 4 years ago

Do you still need dumps from sensors? I have several miflora and LYWSD03MMC devices at home. maybe offtopic, but the article https://habr.com/ru/post/452558/ seems to work for LYWSD03MMC as well. Thanks for your efforts!

Magalex2x14 commented 4 years ago

No, there are enough dumps so far. MiFlora support has already been implemented. The difficulty with LYWSD03MMC is that its BLE advertisements payload seem to be encrypted (we need to figure out how to read it).

The article you pointed out uses a direct connection to the sensor - this is not our method, our component receives BLE broadcasts (this method has many advantages), therefore, unfortunately, this article is useless in this case...

langerhans commented 4 years ago

Update with my findings: The testpoints on the PCB seem useless. There is one where I saw communication once but I didn't figure out the protocol as I couldn't manage to show up again. So nothing useful on this front. Here is the current firmware for the sensor: d4135e135443ba86e403ecb2af2bf0af_upd_miaomiaoce.sensor_ht.t2.zip The binary is not encrypted. Sadly the soc in this thing uses a proprietary architecture that isn't overlay well documented. There is a Ghidra plugin (https://github.com/rgov/Ghidra_TELink_TC32, make sure you use the version from rgov/Ghidra_TELink_TC32#1). But reversing this is far out of my field of expertise. Maybe someone around here can find something useful in there. At this point think that this sensor might just not put the data into its advertisement packets at all...

JsBergbau commented 4 years ago

Here https://github.com/JsBergbau/MiTemperature2/ is a script showing how to get the data out of the LYWSD03MMC sensor. Hope it is helpful to you.

wizel10 commented 4 years ago

I do concur. this script https://github.com/JsBergbau/MiTemperature2 works very well. There is also indication on what the reading bits means.

Magalex2x14 commented 4 years ago

JsBergbau code uses a connection. Our component does not use connections, but receives advertising messages.

erganmedia commented 4 years ago

this method has many advantages

can you pls tell me which advantages it has?

Magalex2x14 commented 4 years ago

There is information about this in the README.md. OK, I will write in more detail. All the advantages are due to the fact that our component passively receives advertisement messages sent by the sensor automatically. This means reduced battery consumption of the sensor at the same time as some increase in operating range (since communication is only one-way, connection is not used, many users has problems with connection instability). Another advantage (key for me personally) is the larger number of measurements per unit of time (than the usual method) without additional cost - it gives faster response time, or combined with averaging, for example, it gives an increase in resolution. The usual method (official mitemp_bt) gives you one measurement in five minutes (by default). If you need averaging (and sometimes there is no other option, some sensors give false peaks), then with the median of three you will receive the first measurement only after 15 minutes. Reducing the measurement period will have a severe negative impact on the sensor battery. Our method solves these problems, as most sensors themselves send about 20-25 measurements per minute "free of charge." At worst, such as MiFlora, we get one measurement a minute. Sorry for bad English.

Staars commented 4 years ago

I received my LYWSD03MMC today and can not receive advertisements with changing values at all. The whole time the value is fixed at:

Identifier: E14E199A-6A40-467E-BF5F-42DEDAE4A1B0, RSSI: -43 dBm, Local name: LYWSD03MMC, Data: Svc FE95: [30585b05015a81ed38c1a4280100]

The sensor behaves completely different to my other xiaomi sensors (okay, that is already written down here) and my main question is: Do the owners of the LYWSD03MMC here have other FW/HW-versions? (because I get no encrypted advertisements).

Here is a report taken with Adafruit Bluefruit LE connect:

I need the data in the advertisement and for me it does not help too, that the data is easily readable via connecting and subscribing.

Staars commented 4 years ago

BTW, writing 1 to "Temperature Uint" (sic!) changes the display to FAHRENHEIT, but this is not really useful (for me).

vevsvevs commented 4 years ago

@Staars ADV containing meaningful data send every ~10 minutes (5, if data is changed), but as mentioned above - it's encrypted.

JsBergbau commented 4 years ago

Suppose the ADV data is really encrypted. How do you know then that it contains meaningful data? The LYWSD03MMC has a very bouncing temperature output. It is even quite unlikely that there is no change within one minute. Often data read differs in the second decimal place every reading. At 99% after 3 readings (~18 seconds) readings changed.

custom-components / ble_monitor

LYWSD03MMC support (implemented since 0.6.0) #7