Mi-like advertising data structure. about atc_mithermometer HOT 99 CLOSED

It looks like after 3 minutes it stops working.

Seems to be because of the long long change of the delay times

Will make the battery indication as an option but on by default as i personally like to know that. Hope thats understandable

from atc_mithermometer.

It works with my custom smarthome now without modification! Perfect!

from atc_mithermometer.

@atc1441 well, it's still the Xiaomi device, right? ;) I'm not a lawyer either, but I believe that until you don't use this UID for custom commercial hardware - there is no possible legal issue.

from atc_mithermometer.

The custom Mi-like version should be compatible now

from atc_mithermometer.

Ah could be that temp and humi is still endianes switched ^^ please someone test it

from atc_mithermometer.

Maybe type (device id) shouldn't be the same as the original firmware, and better to alter parsing in your integration?

With the "Mi like" advertising I think it should behave exactly like a Xiaomi device and work out of the box with the current integration. The custom advertisement is supported by the new component "ATC MiThermometer" with all references to Xiaomi removed. It doesn't even need xiaomi_ble anymore.

Here is what I get with the firmware uploaded 15 min ago. It still doesn't get the magic bytes because they are at the wrong position:

 [16:25:28][VV][esp32_ble_tracker:326]: Parse Result:
[16:25:28][VV][esp32_ble_tracker:343]:   Address: A4:C1:38:4E:16:78 (PUBLIC)
[16:25:28][VV][esp32_ble_tracker:345]:   RSSI: -58
[16:25:28][VV][esp32_ble_tracker:346]:   Name: 'ATC_4E1678'
[16:25:28][VV][esp32_ble_tracker:363]:   Service data:
[16:25:28][VV][esp32_ble_tracker:364]:     UUID: FE:95
[16:25:28][VV][esp32_ble_tracker:365]:     Data: 50.00.AB.BE.03.78.16.4E.38.C1.A4.04.10.02.00.F0.06.10.02.02.44.0A.10.01.52 (25)
[16:25:28][VV][esp32_ble_tracker:368]: Adv data: 1C.16.95.FE.50.00.AB.BE.03.78.16.4E.38.C1.A4.04.10.02.00.F0.06.10.02.02.44.0A.10.01.52.0B.09.41.54.43.5F.34.45.31.36.37.38 (41)
[16:25:28][VV][xiaomi_lywsd03mmc:024]: parse_device(): MAC address A4:C1:38:4E:16:78 found.
[16:25:28][VV][xiaomi_ble:172]: parse_xiaomi_header(): unknown device, no magic bytes.

from atc_mithermometer.

Its now at the stock id updated in the repo

from atc_mithermometer.

From the way the Xiaomi advertisments are structured, it would not be a problem to add the battery to the same packet. esp_home should be fine with it. May xiaomi devices all use the same "pattern" for ther advertisment packets and there exists basically every combination of sensor values.

from atc_mithermometer.

Right now the message contains the combined Temp and Humi data and the Battery level

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L30

so if possible it would be nice to leave it like that but if that mean on ESPhome or other software needs to be done some changes then it would make the Mi Like advertising a bit useless.

from atc_mithermometer.

For me it looks like esphome can only parse one data set per msg

https://github.com/esphome/esphome/blob/3fba3a5e2e812485a49dd7cf38aed7e1ff403c94/esphome/components/xiaomi_lywsd03mmc/xiaomi_lywsd03mmc.cpp#L40

It does a foor loop but only on complete new messsges and not the data payloads itself. It just uses the first one it finds

from atc_mithermometer.

Will most likely edit the Mi Like advertising so it does the alternating. That way the work is not just gone and some other software can support it as well if it already supports the Xiaomi data

from atc_mithermometer.

Having a finer grained battery status makes the custom firmware even more valuable compared to the stock one

from atc_mithermometer.

Updated the Repo to that behavior now,

So its alternating every Advertising interval between Battery and Sensor data.

It will half the advertising time on its own if mi like advertising is activated

from atc_mithermometer.

I now implemented the custom advertising structure here. It was very easy to implement compared to the original Mi stuff. I am not sure the "Mi like" advertising structure will work out of the box with the xiaomi_lywsd03mmc component. I have to think it through how the service data needs to look like.

from atc_mithermometer.

Changed the integers now to long long and that should fix it, can you please try it out

from atc_mithermometer.

if the parser can handle the same id without encryption i will set it to the stock id

from atc_mithermometer.

Yes should work with any Xiaomi like implementation on other Systems.

He asked about the original app, not other integrations to the alternative smarthome systems :)

from atc_mithermometer.

Yes it does not change back to Hummidy level

from atc_mithermometer.

Ok. Yeah something is off there.

And i believe that this battery status monitoring shouldn't be enabled by default, as such LCD-featured device more often used for one-glance climate overview rather than battery status check :) Please consider to make it selectable via Bluetooth and off by default.

from atc_mithermometer.

The humidity offset was already discussed in another issue. It is known that its about 5% of but thats the value directly from the sensor.

It is not possible to backup the stock firmware OTA, only via a telink flasher with hardware connection that works.

The update zip file is captured from an update request and can be downloaded that way over the Mi Servers. The file is not from me. But i got it the same way and by reading the flash from a device.
It is byte wise compared and the same to the flash content.

from atc_mithermometer.

That would be possible but to much work right now.
Maybe in the future but personally it wouldnt be my goal.

from atc_mithermometer.

too bad, not even https://github.com/custom-components/sensor.mitemp_bt support it.

Mi-like structure provided by this custom firmware works well with a minor change in sensor.py.

index 4f4c828..eaa4a16 100644
--- a/custom_components/mitemp_bt/sensor.py
+++ b/custom_components/mitemp_bt/sensor.py
@@ -233,7 +233,7 @@ def parse_raw_message(data, aeskeyslist,  whitelist, report_unknown=False):
     if xiaomi_index == -1:
         return None
     # check for no BR/EDR + LE General discoverable mode flags
-    adv_index = data.find(b"\x02\x01\x06", 14, 17)
+    adv_index = data.find(b"\x15\x16\x95", 14, 17)
     if adv_index == -1:
         return None
     # check for BTLE msg size```

from atc_mithermometer.

I just copy the entire folder to the esphome docker container using terminal commands:
1- mkdir /opt/esphome/esphome/components/atc_mithermometer --from inside the container
2- copy the 4 files from outside the container: --container id may changs
--sudo docker cp file_location/file_name (container_id):/opt/esphome/esphome/components/atc_mithermometer
only for test now because any restart for the docker container it will be lost but it fine by me I only want to test the platform for short time

from atc_mithermometer.

It can be edit to it without problems, but the 0x95FE is a xiaomi branded uuid so i tried to avoid it.

Using that one on the other hand would make ESPhome directly vompatible so i understand your point

from atc_mithermometer.

I would also love this. Since Xiaomi used basically the same format for all their sensor it would be very convenient to just stick with one decoding routine that works for all, including the "freed" ones with custom firmware.

from atc_mithermometer.

If there is no copyright problem im willing to implement it

from atc_mithermometer.

Well I am no lawyer, but I don't see how the structure of the advertisment would be copyrighted. I don't think it has the necessary "Schöpfunghöhe" 😃

from atc_mithermometer.

Ok sounds good. The problem i have is with the 0x95FE as that is "bought" by xiaomi.

from atc_mithermometer.

Added the beginning of advertising like an Mi Thermometer, https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L167

but i didn't found a good example of how the Mi protocol looks like, does someone has an example?

That way it works already, i think i will make it a setting later so you can change on runtime what Service uuid should do the advertising.

from atc_mithermometer.

@atc1441, gathering information in ESPHome repo gave me this:

ADV-packet structure:
	Byte 0:		data/capability/encryption flag
	Byte 1:		?
	Byte 2..3:	device-id
	Byte 4:		frame count
	Byte 5-10:	reversed MAC
	Byte 11...	data points

Data point structure:
	Byte 0:		type
	Byte 1:		fixed 0x10
	Byte 2:		length
	Byte 3..3+len-1: data point value

Data type IDs and lengths:
	0x04:		temperature 0.1°C (int16_t)
	0x06:		humidity 0.1% (int16_t)
	0x0A:		battery 1% (uint8_t)

I only mentioned the needed data type IDs. The battery voltage wasn't seen in the wild yet, but last known data type ID is 0x17, so something like 0x1a should be fine, I think :) Data/capability/encryption flag should be 0x50 in our case.

from atc_mithermometer.

@ahpohl thank you very much! I've tried to implement my own integration pretty much the same way, but I'm stuck with compilation error due to lack of C-syntax understanding :)

@atc1441 if you didn't bother yet too much with my request, maybe it should be canceled now, this implementation is more than enough to use. Sorry for disturbing you.

from atc_mithermometer.

@vevsvevs Advantage to support the "Mi Like" advertising would be no further PRs to ESPHome would be necessary. I think your request has already been implemented by @atc1441 . We can easily change the custom firmware to make it fit (thanks to open source!)

from atc_mithermometer.

Great to see its implemented now,

Was just done implementing the Mi Like advertising....

You can set it from the Flasher simply with a button click.

I am not shure if the format is correct of the mi advertising escpecially the length.

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L24

Would love if someone with ESPhome can test it.

It does not Advertise Battery mV as its to long then.

Also as adition the LCD will show Humidity and battery percent in change now indicating via the Battery symbol.

from atc_mithermometer.

@atc1441 I can test the "Mi Like" function and I tell you in a minute how the advertising needs to look like in order to make it work out of the box with ESPHome

from atc_mithermometer.

Thank you, a real life example data packet would be nice to have including the real values to know how it exactly should look like

from atc_mithermometer.

Another topic: I pressed the 10 minute interval button a couple of times and currently it is receiving data approx every 2 min. Have you tested the 10 min. interval?

from atc_mithermometer.

didnt tested that no, is the counter increasing on every advertising ?

it could be that the advertisind_delay simply has an overflow so it can not count so long, will change it if so

from atc_mithermometer.

Ok thank you will change the delay values from us to seconds so they dont overflow. Thought about that a while ago but never encountered a problem till now ^^

from atc_mithermometer.

The ATC MiTemperature component has a duplicate packet filter and rejects duplicate packets. I see quite a lot of them with the same frame counter, but then after approx. 2 min the frame counter increases and the next packet is processed. So yes, maybe its a variable overflow issue in the firmware which needs fixing.

from atc_mithermometer.

Maybe changing the delay variable from uint32 to long does help as well?! Should be a long enough delay then just not shure if TC32 compiler does support it will test.

from atc_mithermometer.

I switched to the "Mi Like" advertising. This is what I get:

[15:43:37][VV][esp32_ble_tracker:343]:   Address: A4:C1:38:4E:16:78 (PUBLIC)
[15:43:37][VV][esp32_ble_tracker:345]:   RSSI: -55
[15:43:37][VV][esp32_ble_tracker:346]:   Name: 'ATC_4E1678'
[15:43:37][VV][esp32_ble_tracker:363]:   Service data:
[15:43:37][VV][esp32_ble_tracker:364]:     UUID: 95:FE
[15:43:37][VV][esp32_ble_tracker:365]:     Data: 50.00.AB.BE.04.78.16.4E.38.C1.A4.04.10.02.00.EE.06.10.02.02.44.0A.10.01.52 (25)
[15:43:37][VV][esp32_ble_tracker:368]: Adv data: 1C.16.FE.95.50.00.AB.BE.04.78.16.4E.38.C1.A4.04.10.02.00.EE.06.10.02.02.44.0A.10.01.52.0B.09.41.54.43.5F.34.45.31.36.37.38 (41)
[15:43:37][VV][xiaomi_lywsd03mmc:024]: parse_device(): MAC address A4:C1:38:4E:16:78 found.
[15:43:37][VV][xiaomi_ble:108]: parse_xiaomi_header(): no service data UUID magic bytes.

For comparison an original packet:

[12:03:39][VV][esp32_ble_tracker:321]:     UUID: FE:FE95
[12:03:39][VV][esp32_ble_tracker:322]:     Data: 58.58.5B.05.17.B7.34.8C.38.C1.A4.EE.37.C3.AC.10.46.00.00.FC.27.F0.A5 (23)
[12:03:39][VV][esp32_ble_tracker:325]: Adv data: 02.01.06.1A.16.95.FE.58.58.5B.05.17.B7.34.8C.38.C1.A4.EE.37.C3.AC.10.46.00.00.FC.27.F0.A5.0B.09.4C.59.57.53.44.30.33.4D.4D.43 (42)
[12:03:40][VV][xiaomi_ble:118]: parse_xiaomi_service_data(): encrypted packet received.

It seems that the magic bytes have the wrong endianess. The same was actually true for the custom firmware advertising. I had to swap UUID 0x181A into UUID 0x1A18 in order to be recognized.

from atc_mithermometer.

Looks like your stock data/ original packet is from an LYWSD03MMC but we need a original packet from another Xiaomi thermometer without encryption.

from atc_mithermometer.

The advertising packets have been explained here: https://github.com/Magalex2x14/LYWSD03MMC-info.

Looks like you stock data/ original packet is from an LYWSD03MMC but we need a original packet from another Xiaomi thermometer without encytion.

Yes, I'll did through some old logs.

from atc_mithermometer.

@atc1441 here is a data from CGG1:

5030470386FD4910342D58061002B701

from atc_mithermometer.

@vevsvevs thank thats perfect.

Changed the endianes of the service, that was indeed of

from atc_mithermometer.

The CGG1 sends the following unencrypted advertisement:

50.20. 47.03. 16. 67.3A.10.34.2D.58. 0D.10.04.E1.00.87.02. 0A.10.01.15 (22) 
50.30. 47.03. D0. 7A.4C.10.34.2D.58. 04.10.02.E9.00.       0A.10.01.10 (20)
ctrl   type   cnt        mac rev     data 1                data 2

For the LYWSD03MMC the type would be 5B 05. The frame control bytes indicate the packet is not encrypted, which I need because I need to skip decryption.

The flag 0x50 at byte 1 get checked like this:

  result.has_data = (raw[0] & 0x40) ? true : false;
  result.has_capability = (raw[0] & 0x20) ? true : false;
  result.has_encryption = (raw[0] & 0x08) ? true : false;

from atc_mithermometer.

The temperature, humidity and battery data format is like this (data 1 and data 2 in last comment):

  // temperature, 2 bytes, 16-bit signed integer (LE), 0.1 °C
  else if ((raw[0] == 0x04) && (data_length == 2)) {
    const int16_t temperature = uint16_t(data[0]) | (uint16_t(data[1]) << 8);
    result.temperature = temperature / 10.0f;
  }
  // humidity, 2 bytes, 16-bit signed integer (LE), 0.1 %
  else if ((raw[0] == 0x06) && (data_length == 2)) {
    const int16_t humidity = uint16_t(data[0]) | (uint16_t(data[1]) << 8);
    result.humidity = humidity / 10.0f;
  }
  // battery, 1 byte, 8-bit unsigned integer, 1 %
  else if ((raw[0] == 0x0A) && (data_length == 1)) {
    result.battery_level = data[0];
  }
  // temperature + humidity, 4 bytes, 16-bit signed integer (LE) each, 0.1 °C, 0.1 %
  else if ((raw[0] == 0x0D) && (data_length == 4)) {
    const int16_t temperature = uint16_t(data[0]) | (uint16_t(data[1]) << 8);
    const int16_t humidity = uint16_t(data[2]) | (uint16_t(data[3]) << 8);
    result.temperature = temperature / 10.0f;
    result.humidity = humidity / 10.0f;
  }

from atc_mithermometer.

but will also change it so it use the combined 0x0D type then the data is shorter.

Changed the endianes now and updated it, so with luck its now like it should be :)

from atc_mithermometer.

For the LYWSD03MMC the type would be 5B 05

Maybe type (device id) shouldn't be the same as the original firmware, and better to alter parsing in your integration?

from atc_mithermometer.

Yeah type id is now AB BE just to differ it from others

from atc_mithermometer.

Maybe type (device id) shouldn't be the same as the original firmware, and better to alter parsing in your integration?

I think it should stay the same. It's still the same just the encryption bit is not set and not encrypted.

from atc_mithermometer.

because they are at the wrong position:

I believe, not because of position, but it's AB:BE instead of 5B:05 ;)

@atc1441 maybe as you implemented selectable advertising_type, indeed there is no reason alter the device id for mi-like mode?

from atc_mithermometer.

yes, I think it does. The parser depends on the three flags data, capability and encryption being evaluated correctly. A value of 0x50 in the first frame control byte (the second is not checked) gives us true, false, false which will work. I am trying to remember what beginning of the service data means up to the point where the data packet starts

from atc_mithermometer.

The original adv packet from above:

02.01.06          1A         16        95.FE          58.58        5B.05         17          B7.34.8C.38.C1.A4        EE.37.C3.AC.10.46.00.00.FC.27.F0.A5.0B.09.4C.59.57.53.44.30.33.4D.4D.43 (42)
BR/EDR+LE flags   len        AD-type   Xiaomi UUID    Frame ctrl   device type   Frame cnt   mac reversed             start of encrypted payload

So great it already seems to work!

from atc_mithermometer.

Does that mean that it will work again with the Xiaomi Home application ? Absolut great work Aaron, many thanks to all of you

from atc_mithermometer.

It should work with any Xiaomi like implementation on other Systems but not the Mi Home App itself

Now only the 10 minute Advertising intervall needs to be tested.

Right now the settings will be back to default on battery removing, i am thinking about adding a storage in flash but without it its kinda failsave

from atc_mithermometer.

@DoeWayne it won't, of course.

from atc_mithermometer.

@vevsvevs I just recognized it, what a shame, so need to find another application on the mobile which should receive all the data. I'm just on the way to order another 20 devices.

from atc_mithermometer.

@atc1441 btw, there is some kind of problem with the battery icon state, tracing now..

from atc_mithermometer.

Does the frame counter increase properly? I get lots of duplicate packets but not the data. My frame counter is at 0x0B (11, byte 5) for quite some time now (10 s interval setting)

[17:14:25][VV][esp32_ble_tracker:326]: Parse Result:
[17:14:25][VV][esp32_ble_tracker:343]:   Address: A4:C1:38:4E:16:78 (PUBLIC)
[17:14:25][VV][esp32_ble_tracker:345]:   RSSI: -53
[17:14:25][VV][esp32_ble_tracker:346]:   Name: 'ATC_4E1678'
[17:14:25][VV][esp32_ble_tracker:363]:   Service data:
[17:14:25][VV][esp32_ble_tracker:364]:     UUID: FE:95
[17:14:25][VV][esp32_ble_tracker:365]:     Data: 50.30.5B.05.0B.78.16.4E.38.C1.A4.0D.10.04.F0.00.3A.02.0A.10.01.52 (22)
[17:14:25][VV][esp32_ble_tracker:368]: Adv data: 19.16.95.FE.50.30.5B.05.0B.78.16.4E.38.C1.A4.0D.10.04.F0.00.3A.02.0A.10.01.52.0B.09.41.54.43.5F.34.45.31.36.37.38 (38)
[17:14:25][VV][xiaomi_lywsd03mmc:024]: parse_device(): MAC address A4:C1:38:4E:16:78 found.
[17:14:25][VV][xiaomi_ble:124]: parse_xiaomi_header(): duplicate data packet received (11).

from atc_mithermometer.

@vevsvevs the battery i con will be on when the battery status is shown in the humidity value section.

Thats so you know how full the battery is

from atc_mithermometer.

Ok. Yeah something is off there.

Will check

from atc_mithermometer.

Still no data yet, only duplicate frames. Maybe the long long change of the counter also affected the frame counter. Everybody else is seeing data apart from me?

from atc_mithermometer.

Yes also the frame counter was broken, kind of anything timing related was broken.

Did reversed it to uint32 for now, and added the battery show setting

Need to find a good working Arduino like millis() counter, will look into timers, but that will take a while as i cant think of a good way to look out for overflows in software, it would kind of work but would still be off

from atc_mithermometer.

@atc1441 With the last firmware update the temperature and humidity data are broadcasted again approx. every minute (60 s interval setting). No battery level data yet. I guess you have implemented only the first data packet with temp/humidity. The CGG1 actually broadcasts the battery level in a second separate packet shortly after the first packet. This is what I have given you in #3 (comment). I don't think it is possible with xiaomi_lywsd03mmc to broadcast all three values in one packet. Of course, with the custom advertisement you can do whatever you want and it was no problem to implement the three values in atc_mithermometer.

from atc_mithermometer.

if the 10 minute broadcast interval causes a problem with the very fast µs or even ns timers, you can alternatively slow down the sensor in ESPHome:

  - platform: xiaomi_lywsd03mmc 
    filters:
    - throttle: 10min

For me having a 1 min interval in the firmware is sufficient.

from atc_mithermometer.

@ahpohl ok to bad, i thought its possible to simply send more than one packet with an advertising message.

need to think of a solution for that.

Would as well be nice to have the timer running fine for future projects so will still try to find a fix for the interval problem

from atc_mithermometer.

For me that's perfect

from atc_mithermometer.

@ahpohl ok to bad, i thought its possible to simply send more than one packet with an advertising message.

Maybe we misunderstood each other. I was not aware that it is possible to send two packets with one broadcast. As long as the data is formatted like shown above and each payload (1. temp/humidity, 2. battery level) is encapsulated in a separate advertising packet it should work fine. I do not understand how the messages are broadcasted by the device (both original and your custom firmware), I can only see what has been received. There is also this issue with duplicate frames for this device in either firmware, which must be hardware related.

See https://github.com/esphome/esphome/blob/dev/esphome/components/xiaomi_ble/xiaomi_ble.cpp in function parse_xiaomi_message.

from atc_mithermometer.

@ahpohl ok so it should work just fine as the battery level is in the right format?!

The dublicate advertising is most likely because it is being send out every ble interval (1900ms)
And only changes on set interval(60s default)

from atc_mithermometer.

Yes I believe so. I can test if you changed the firmware. The version I have flashed doesn't have the battery level broadcast yet.

from atc_mithermometer.

It does a foor loop but only on complete new messsges and not the data payloads itself. It just uses the first one it finds

This for loop is strange and I never encountered more than one service data in one packet. But its the way all these Xiaomi components are setup. At one point I thought of removing the for loop, but then decided to leave it as it doesn't do any harm.

For me it looks like esphome can only parse one data set per msg

Yes, apparently the two payloads (temp/humidity and battery level) need to be in two separate service data packets sent alternating shortly after one another (with increasing frame counter)

from atc_mithermometer.

If it turns out to be not possible to sent two packets with different payloads, I suggest to remove the "Mi like" advertising feature and stick with the custom advertisement. I can prepare a pull request for the new component atc_mitemperature against esphome/dev, which fully supports temperature, humidity and battery level in one packet.

Modifying the existing Xiaomi packet parser and introducing a new data type is not a good idea, as the data types are all real Xiaomi ones. If Xiaomi develops a new sensor which uses our new fake data type, the support for either would break.

from atc_mithermometer.

@ahpohl
While I agree with your points, the funny thing is: As far as I remember the original firmware always reported the battery at 100%, so it doesn't work anyway. 😃

To me the mi like advertising is still valuable, but being the only one using my solution it probaly doesn't justify the feature.

from atc_mithermometer.

As far as I remember the original firmware always reported the battery at 100%, so it doesn't work anyway.

Actually this is not true. Today I discovered that one my devices with original firmware displayed the battery symbol and the battery level was reported at 10 %. I then went back in my historical data and the status jumped straight from 100 % to 10 %. If its a feature or a bug only Xiaomi can tell.

from atc_mithermometer.

@atc1441 I was sure that the MI ADV payload may contain more than one data point, but it can't. Sorry for this misinformation.
@ahpohl check this out, please.

from atc_mithermometer.

So my idea is now the following with the alternating Mi data, the Advertising data will contains one time Battery and the next time the Sensor data and so on.

So if set to Mi Like it would be needed to make the Advertising interval half the time of the Custom one.

also thought about sending it only every ten advertising but as i can not really send both ( Sensor and Batt ) on one go there would be always one Temp/Humi data packet missing every tens message which maybe does not look good on the graph as well

is that something to work from ?

i will not add the Battery in mV as from the % that can be kind of calculated and needs changes to Mi plugin of ESPhome

from atc_mithermometer.

Battery data is now received in addition to temperature/humidity

I have two other things:

• I noticed that after flashing the custom firmware the humidity immediately dropped by 5 %. I also confirmed this by placing another LYWSD03MMC with stock firmware directly next to one with the custom firmware. I checked the temperature of the sensors when I bought them with a calibrated Fluke reference thermometer and was surprised how well calibrated they are. The humidity I am not able to verify, but all eight sensors were showing values +- 1%. Is the humi offset something I have to set?
• Would it be possible to implement a backup function in the the Telink flasher? So before flashing the custom firmware you could take a backup of the stock firmware first. Were does the stock firmware in this zip archive comes from?

from atc_mithermometer.

I am a bit confused bi the mi-like format now 😄

Current format is like this:
50 30 5b 05 5c 72 e6 46 38 c1 a4 0a 10 01 3d 00 00 00
with bytes
0-1: ctrl
2-3: type
4: cnt
5-10: mac
11: data type (in this case 0A for battery)

what I see in my stock devices after decryption (in my e-ink one which doesn't encrypt anyway is this:
70 20 5b 04 92 1f a1 42 01 2e e7 09 06 10 02 30 02 (never encryapted
which has the data type at byte 12 (06 for humidity in this case). Not sure what byte 11 is for, but it's there 😄

Am I the only one stubling over this?

from atc_mithermometer.

This is not a contradiction. 0x70 (byte 1) means the payload has data (0x70 & 0x40 = 64), capability (0x70 & 0x20 = 32) and is not encrypted (0x70 & 0x08 = 0). When the device has capability, the payload starts at byte 12 instead of byte 11. xiaomi_ble takes care of all this.

result.raw_offset = result.has_capability ? 12 : 11;

What this extra byte means I also don't know.

from atc_mithermometer.

Thx, that makes sense (somehow 😄 ). Now it seems to work for me.

from atc_mithermometer.

Just so more people will see it, the issue with the LCD turning of on to low temperature is now fixed. #11 (comment)

Also i added the feature to get an instant advertising as soon as the Sensor data changes to fast between an Main loop delay (5 Seconds)
https://github.com/atc1441/ATC_MiThermometer#temp-or-humi-instant-advertising

from atc_mithermometer.

is MI like suppose to be recognize and paired with official Mi Home app? because i can't make it so.

for Mi Home on iOS, it's not even discovered. for Mi Home on android it's found but timed out pairing.

from atc_mithermometer.

No its just the Advertising that is mi like. So that the Advertising data can be decoded with some custom Mi decode like in ESPhome.

Not for the official App

from atc_mithermometer.

too bad, not even https://github.com/custom-components/sensor.mitemp_bt support it. it is possible to add mi home support? i really like the 1 minute interval and features regarding to battery (excluding the blinking face)

from atc_mithermometer.

Can I use the sensors with current custom firmware version by simply using Homeassistant default mitemp_bt Integration: https://www.home-assistant.io/integrations/mitemp_bt/

from atc_mithermometer.

Hi guys, thanks for work done first of all. I have flashed custom firmare using OTA method - awesome!
I want to integrate these sensors into openhab2, I'm using RPI 3B+ embedded bluetooth and in Openhab using blueZ bridge discovering devices, but only RSSI channel is autodetected. Any thoughts why humidity, battery level and temperature is not detected?

from atc_mithermometer.

too bad, not even https://github.com/custom-components/sensor.mitemp_bt support it.

Mi-like structure provided by this custom firmware works well with a minor change in sensor.py.

index 4f4c828..eaa4a16 100644
--- a/custom_components/mitemp_bt/sensor.py
+++ b/custom_components/mitemp_bt/sensor.py
@@ -233,7 +233,7 @@ def parse_raw_message(data, aeskeyslist,  whitelist, report_unknown=False):
     if xiaomi_index == -1:
         return None
     # check for no BR/EDR + LE General discoverable mode flags
-    adv_index = data.find(b"\x02\x01\x06", 14, 17)
+    adv_index = data.find(b"\x15\x16\x95", 14, 17)
     if adv_index == -1:
         return None
     # check for BTLE msg size```

I can confirm that this works well just
`sensor:

• platform: mitemp_bt
  whitelist:
  • 'A4:C1:38:A2:XX:XX'
    `

from atc_mithermometer.

too bad, not even https://github.com/custom-components/sensor.mitemp_bt support it.

Mi-like structure provided by this custom firmware works well with a minor change in sensor.py.

index 4f4c828..eaa4a16 100644
--- a/custom_components/mitemp_bt/sensor.py
+++ b/custom_components/mitemp_bt/sensor.py
@@ -233,7 +233,7 @@ def parse_raw_message(data, aeskeyslist,  whitelist, report_unknown=False):
     if xiaomi_index == -1:
         return None
     # check for no BR/EDR + LE General discoverable mode flags
-    adv_index = data.find(b"\x02\x01\x06", 14, 17)
+    adv_index = data.find(b"\x15\x16\x95", 14, 17)
     if adv_index == -1:
         return None
     # check for BTLE msg size```

Tested this modification here on HA 0.115.2, ATC_Thermometer.bin of 9/9/2020 and HACS ble plugin 0.6.12 but unfortunately I get no data (with original firmware and default sensor.py, I do get the data).

EDIT: my bad, after clicking"Mi Like" button on telink flasher webpage, the data started to appear in HA (I assumed this was the default behavior of the firmware but it's not the case).

from atc_mithermometer.

There is a PR esphome/esphome#1293 by @Alex9779 on its way which adds back the functionality of multi value parsing in the base component xiaomi_ble (see also issue esphome/issues#1500) . Once this has been merged, the "Mi Like" advertising could be modified to send multi values at once like initially wanted. The values are just patched together in Xiaomi format:

04 10 02 00 00  06 10 02 00 00  0A 10 01 00 
temperature     humidity        battery level

Apparently there is a particular version of CGG1 which does exactly this (esphome/issues#799). The updated code in esphome will parse the payload until it is fully consumed and then report everything it found at once.

from atc_mithermometer.

Oh nice to hear.

Is that already implemented? Or should i wait till i code it back to multi values?

from atc_mithermometer.

It is implemented, tested by me and confirmed working with my CGG1 devices which send temp/humidity with appended battery data.
@ahpohl reviewed and also tested with his devices which do not do this, so basic and encrypted functions are also fine, so now waiting for someone to merge if it is considered fine. No idea when this will happen and then it is just in dev, not in master...

from atc_mithermometer.

EDITED: I think is affected by: #19

Everything is working perfect. But the firm is sending the announcements every minute or so. The battery is draining fast. It is 80% after one week.

It does not matter the value that you put from the flash page (https://atc1441.github.io/TelinkFlasher.html).
I have 8 sensors (LYWSD03MMC) with the custom firm, all with Advertise type: "My like" and Advertising interval: "10minutes". Checked in the logs that the command has reached the sensor.

15:18:15: Detected custom Firmware
15:18:19: Settings AB was send successful
15:18:41: Settings FE3C was send successful

But the esp32_ble_tracker sees the ads every few seconds:

[15:23:02][D][sensor:092]: 'e32c1 xc1 Temperature': Sending state 24.30000 °C with 1 decimals of accuracy
[15:23:02][D][sensor:092]: 'e32c1 xc1 Humidity': Sending state 49.00000 % with 0 decimals of accuracy
[15:23:26][D][sensor:092]: 'e32c1 xc1 Temperature': Sending state 24.30000 °C with 1 decimals of accuracy
[15:23:26][D][sensor:092]: 'e32c1 xc1 Humidity': Sending state 49.00000 % with 0 decimals of accuracy
[15:24:10][D][sensor:092]: 'e32c1 xc1 Temperature': Sending state 24.30000 °C with 1 decimals of accuracy
[15:24:10][D][sensor:092]: 'e32c1 xc1 Humidity': Sending state 49.00000 % with 0 decimals of accuracy
[15:24:32][D][sensor:092]: 'e32c1 xc1 Temperature': Sending state 24.30000 °C with 1 decimals of accuracy
[15:24:32][D][sensor:092]: 'e32c1 xc1 Humidity': Sending state 49.00000 % with 0 decimals of accuracy
[15:24:53][D][sensor:092]: 'e32c1 xc1 Temperature': Sending state 24.30000 °C with 1 decimals of accuracy
[15:24:53][D][sensor:092]: 'e32c1 xc1 Humidity': Sending state 49.00000 % with 0 decimals of accuracy
[15:26:13][D][sensor:092]: 'e32c1 xc1 Battery Level': Sending state 79.00000 % with 0 decimals of accuracy

[14:39:36][D][sensor:092]: 'm5stick_abajo x2 Humidity': Sending state 56.00000 % with 0 decimals of accuracy
[14:41:05][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy
[14:41:58][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy
[14:42:23][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy
[14:42:46][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy
[14:44:11][D][sensor:092]: 'm5stick_abajo x2 Temperature': Sending state 21.10000 °C with 1 decimals of accuracy
[14:44:11][D][sensor:092]: 'm5stick_abajo x2 Humidity': Sending state 56.00000 % with 0 decimals of accuracy
[14:45:19][D][sensor:092]: 'm5stick_abajo x2 Temperature': Sending state 21.10000 °C with 1 decimals of accuracy
[14:45:19][D][sensor:092]: 'm5stick_abajo x2 Humidity': Sending state 56.00000 % with 0 decimals of accuracy
[14:45:38][D][sensor:092]: 'm5stick_abajo x2 Temperature': Sending state 21.10000 °C with 1 decimals of accuracy
[14:45:38][D][sensor:092]: 'm5stick_abajo x2 Humidity': Sending state 56.00000 % with 0 decimals of accuracy
[14:46:21][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy
[14:46:33][D][sensor:092]: 'm5stick_abajo x2 Battery Level': Sending state 81.00000 % with 0 decimals of accuracy

[14:41:49][D][sensor:092]: 'm5stick_abajo x3 Battery Level': Sending state 86.00000 % with 0 decimals of accuracy
[14:42:10][D][sensor:092]: 'm5stick_abajo x3 Battery Level': Sending state 86.00000 % with 0 decimals of accuracy
[14:42:29][D][sensor:092]: 'm5stick_abajo x3 Battery Level': Sending state 86.00000 % with 0 decimals of accuracy
[14:43:43][D][sensor:092]: 'm5stick_abajo x3 Battery Level': Sending state 86.00000 % with 0 decimals of accuracy
[14:44:05][D][sensor:092]: 'm5stick_abajo x3 Temperature': Sending state 21.50000 °C with 1 decimals of accuracy
[14:44:05][D][sensor:092]: 'm5stick_abajo x3 Humidity': Sending state 54.00000 % with 0 decimals of accuracy
[14:44:26][D][sensor:092]: 'm5stick_abajo x3 Temperature': Sending state 21.50000 °C with 1 decimals of accuracy
[14:44:26][D][sensor:092]: 'm5stick_abajo x3 Humidity': Sending state 54.00000 % with 0 decimals of accuracy
[14:45:34][D][sensor:092]: 'm5stick_abajo x3 Temperature': Sending state 21.50000 °C with 1 decimals of accuracy
[14:45:34][D][sensor:092]: 'm5stick_abajo x3 Humidity': Sending state 54.00000 % with 0 decimals of accuracy
[14:46:24][D][sensor:092]: 'm5stick_abajo x3 Temperature': Sending state 21.50000 °C with 1 decimals of accuracy
[14:46:24][D][sensor:092]: 'm5stick_abajo x3 Humidity': Sending state 54.00000 % with 0 decimals of accuracy

Any suggestion?

Thanks for the impressive work to all of you who have made it possible.

from atc_mithermometer.

Hi can anyone please share how to add a sensor for the custom firmware to ESPHOME configuration
which sensor should I choose sense "xiaomi_lywsd03mmc" will not work anymore after replacing the firmware

from atc_mithermometer.

There is a pending pull request for esphome: esphome/esphome#1291
Until it's merged you can fetch files from esphome/components/atc_mithermometer and put it in corresponding directory on your installation. Sample config would look like this:

sensor:
  - platform: atc_mithermometer
    mac_address: "A4:C1:38:57:C4:EE"
    id: sens1
    temperature:
      name: "sens1_temp"
    humidity:
      name: "sens1_hum"
    battery_level:
      name: "sens1_bat"

from atc_mithermometer.

thank you for the fast response my esphome installation is on Hassio inside docker container but i couldn't find the atc_mithermometer component can you provide a link
thanks a lot

from atc_mithermometer.

never mind I found it thanks a lot
https://github.com/ahpohl/esphome/tree/dev/esphome/components/atc_mithermometer

from atc_mithermometer.

@onecd2000 how do you plan on getting the corresponding files into your home assistant build?

from atc_mithermometer.

@onecd2000 Perfect. I didn't realize Portainer was hiding the addon containers at first, but once that was sorted I got it all set up. Only thing is that when I upload the *.yaml to my MiThermometer, it tries to connect to wifi and fails [which makes sense]. Honestly I'm just playing around but i think my configs might be off / bluetooth might not be working on my Home Assistant instance. Either way, thanks for the info!

from atc_mithermometer.