[Q] Data format documentation?

[curlyel]

Hi Victor,
if I understand correctly, you've introduced a "custom" format for advertising the data in addition to the initial ATC1441 format while sharing the same UUID for it.

I'm using this script for receiving the data and forward it to MQTT: https://github.com/JsBergbau/MiTemperature2

This script messed up with the 19 byte data when sent along with the initial 16 byte format from @atc1441 . Meanwhile the author of the script included a fix which filters out the (additional) 19 byte data. This means, if you set format to All or ATC1441, in your firmware the script decodes correctly the 16 byte variant of the broadcast. Good so far...

BUT: If someone want to leverage the addtional information you broadcast (eg. the battery level in addtion to the voltage ;-) ), a more precise documentation of your data format will be appreciated ;-)

Mind sharing your custom format similar to how atc1441 did, like:

> The format of the advertising data is as follow:
> Byte 5-10 MAC in correct order
> Byte 11-12 Temperature in int16
> Byte 13 Humidity in percent
> Byte 14 Battery in percent
> Byte 15-16 Battery in mV uint16_t
> Byte 17 frame packet counter

... adopted to your format?

Many thanks!

[pvvx]

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;

https://github.com/pvvx/ATC_MiThermometer/blob/master/src/ble.h#L37-L48

Does it make sense to describe the format for those who cannot read the simplest "с"?

[curlyel]

Does it make sense to describe the format for those who cannot read the simplest "с"?

Wow! Impressed by your kindness...