[ATC] Support 19 byte ATC advertising format on UUID 0x181A

[curlyel]

The initial ATC custom firmware from https://github.com/atc1441/ATC_MiThermometer advertises 16 byte data which are decoded by the MiTemperature script correctly.

Meanwhile the original author promotes a fork of his initial work because of some advantages:

Victor @pvvx did some very nice refinigs of this custom firmare so i really suggest on cheking it out and even use his version as it offers many more functions including non-volatile storage and a better low power management https://github.com/pvvx/ATC_MiThermometer

This fork advertises in four formats:

Advertising in 4 formats:

UUID 0x181A - size 16: atc1441 format
UUID 0x181A - size 19: custom - temperature x0.01C, humidity x0.01%, battery charge level 0..100%, battery voltage in mV, GPIO-pin flags (mark “reset”) and triggers.
UUID 0xFE95 - 0x0A: Xiaomi - battery charge level 0..100%, battery voltage in mV
UUID 0xFE95 - 0x0D: Xiaomi - temperature x0.1C, humidity x0.1%

Although the firmware has the option to omit some of these, the default would be to advertise all four formats. Since two of them share a single UUID

UUID 0x181A - size 16: atc1441 format
UUID 0x181A - size 19: custom - temperature x0.01C, humidity x0.01%, battery charge level

... the MiTemperature2 script messes up the new 19 byte advertisement which leads to false readings e.g.:

BLE packet: A4:C1:38:14:10:D8 00 1312161a18d8101438c1a46d08e70c040c61e804 -76
Temperature:  2791.2
Humidity:  231
Battery voltage: 1.036 V
RSSI: -76 dBm

BLE packet: A4:C1:38:14:10:D8 00 1110161a18a4c1381410d800d820610c02e1 -75
Temperature:  21.6
Humidity:  32
Battery voltage: 3.074 V
RSSI: -75 dBm

Therefore I suggest to either ignore (filter) the 19 byte advertisement or parse it correctly and introduce an option to choose between the "16 byte low res" and "19 byte hight-res" advertisements.

[JsBergbau]

Hi curlyel thanks for this important information. I'll take a look.
So if I understand you correct, you can only distinguish between both firmware formats by packet length?
I mean reusing the same UUID but changing format breaks compatibility with almost every software. Changing UUID or using put this additional data after the first 16 Byte would have avoided this situation.

[curlyel]

Yes, both share the same UUID, only different data length.

The new firmware sends both formats: The initial ATC1441 (16byte) together with the 19 byte per default.
As I said, you can limit the advertised formats to a single format through custom options to be sent to the ATC device.

The 19 byte format is not well described, just:

UUID 0x181A - size 19: custom - temperature x0.01C, humidity x0.01%, battery charge level 0..100%, battery voltage in mV, GPIO-pin flags (mark “reset”) and triggers.

So the easiest way would be to simply ignore any 19 byte advertisment or ask @pvvx for a detailed explanation of his custom format.

[JsBergbau]

Hi curlyel,
I've just implemented the fix. Please try out.
Thanks for your help improving MiTemperature2.

@ALL: If new format is needed, please provide detailed description of it and then I'll implement. Please notice that temperature output with 2 decimal places bounces a lot, so that would not give much benefits from my point of view.

[curlyel]

Works as expected! Many thanks for looking into it and providing a fix that quickly 👍

Though, I've asked Victor to provide more information about his custom format: pvvx/ATC_MiThermometer#26 (comment)

@ALL: If new format is needed, please provide detailed description of it and then I'll implement. Please notice that temperature output with 2 decimal places bounces a lot, so that would not give much benefits from my point of view.

I'd aggree: The higher "precision" is not a real advantage or even the opposite - as you said ;-)
Only benefit I currently see is the pre-calculated charge level (0...100%) which presumably is based on the real voltage range the LYWSD03MMC can work on.

[JsBergbau]

Only benefit I currently see is the pre-calculated charge level (0...100%) which presumably is based on the real voltage range the LYWSD03MMC can work on.

Don't rely too much on this values. I've sensor with original firmware which even don't show a weak battery symbol. However when you connect to them, they reboot because battery can't supply enough current/voltage for the more power needed during connection.

Are you sure that this battery level is really calculated like the one with original firmware? Author could also make assumptions about voltage range and calculate the battery level a bit different than with original firmware.

Also original ATC firmware has precalculated battery level in byte 14. You can see it with --battery switch. And I doubt that Victor changed the way battery level is calculated.

[curlyel]

Are you sure that this battery level is really calculated like the one with original firmware?

Mmh... no. ;-)

ATC firmware has precalculated battery level in byte 14. You can see it with --battery switch

Just tried: Works with Victor's firmware the same way with the '--battery' option.
Wasn't aware of that. Thanks for pointing out!
Considering this, I don't see any advantages for my use case with the 19 byte format anymore.

Many thanks again, happy now ;-)

[rjblake]

Did you try this with Victor's latest firmware? I get no data when running this on v2.0 of his firmware. If I set broadcast atc1441 it works, if set to custom, nothing. What version did you use?

[curlyel]

That's the intended behavior. JsBergbau has filtered out any 19byte (a.k.a. custom) broadcasts and just let the 16byte atc1441 through the decode procedure.

This means, if you set the format to atc1441 or default/all you get the readings.

The 19byte custom format is not yet implemented in the script. At least for my use case it does'nt bring much benefit or even the opposit: more bouncing values.

Therefore I sticked with atc1441 16byte ;-)

[rjblake]

@curlyel - thanks for info. I misunderstood the post thinking the 19byte custom was implemented. Only reason I was looking at this was to set calibration for a number of devices (i.e. get them as close to each other), but probably not a big benefit if the values bounce a lot.

[rjblake]

Hi curlyel,
I've just implemented the fix. Please try out.
Thanks for your help improving MiTemperature2.

@ALL: If new format is needed, please provide detailed description of it and then I'll implement. Please notice that temperature output with 2 decimal places bounces a lot, so that would not give much benefits from my point of view.

The format Victor uses for the 19bytes is as follows:

// GATT Service 0x181A Environmental Sensing
// All data little-endian
typedef struct __attribute__((packed)) _adv_custom_t {
	uint8_t		size;	// = 19
	uint8_t		uid;	// = 0x16, 16-bit UUID
	uint16_t	UUID;	// = 0x181A, GATT Service 0x181A Environmental Sensing
	uint8_t		MAC[6]; // [0] - lo, .. [6] - hi digits
	int16_t		temperature; // x 0.01 degree
	uint16_t	humidity; // x 0.01 %
	uint16_t	battery_mv; // mV
	uint8_t		battery_level; // 0..100 %
	uint8_t		counter; // measurement count
	uint8_t		flags; 
} adv_custom_t, * padv_custom_t;

[curlyel]

Reopening because of ongoing discussion....

[pvvx]

Hello,
In the new firmware versions there is an advertisement in the "Encrypted Mi beacon" format with a bindkey.
The description of mijia advertisement is on the official website.
Partial translation of several pages of the official website from Chinese
https://github.com/pvvx/ATC_MiThermometer/tree/master/InfoMijiaBLE

[xjustbmw]

can we try the new custom adveritising type with 0.01 resolution ?
i have a pid that might react better (or worse:) with the extra digit as feed back

[JsBergbau]

Hi xjustbmw. It it is really important I'll try to find some time and add support for the new format. This is not so trivial because of other features like the skip identical parameter must be taken into account.
Before you try with 0.01 resolution please also try adding a capacitor, because the lack of it affects measurement accuracy, see pvvx/ATC_MiThermometer#11 (comment)

So if your PID still doesn't react well enough then you can try 0.01 resolution and for accurate values this capacitor is mandatory I would say. Please keep in mind that original firmware in connection mode uses 0.01 resolution. However these values bounce so much that these values weren't really useful for me, see #2 Perhaps with a capacitor the bouncing is gone.
So if you need a really fast solution to try, flashback original firmware with connection mode and 0.01 resolution, add a capacitor and give it a try.

Hope to hear from you soon.

[xjustbmw]

Its perfectly usable at the moment even like this. temperature in room varies + - 0.2 degrees at most
Before I had ~2 degrees between rooms using only one temperature sensor on the return air (of all romos) temperature control

I am using an old raspberry pi using your script to inject data into influxdb/mqtt, nodered + tasmota esp8266 + a few pwm servos to control the supply air ventilation flow in each room

Adding more stability of the sensors and resolution would be even better, perhaps a little bit of pid tuning as well :)

[JsBergbau]

Custom format is now supported in latest version v4.0.