search

pvvx / ATC_MiThermometer

Custom firmware for the Xiaomi Thermometers and Telink Flasher
https://github.com/pvvx/pvvx.github.io/tree/master/ATC_MiThermometer
Other
2.75k stars 196 forks source link

10sec max is too low for Advertising interval #450

Closed bam80 closed 6 months ago

bam80 commented 6 months ago

MQTT app I use has limited amount of the packets data stored for graph's (about 100), so I need bigger Advertising intervals to have meaningful history deep. And I don't need the data so frequently, anyway.

Is it possible to have wider Advertising intervals?

pvvx commented 6 months ago

The maximum interval is limited by the Bluetooth standard version 4.2 to 10 seconds.

bam80 commented 6 months ago

In the other firmware, I see it can be set longer:

Advertising interval byte0 0xFE byte1 0x06 - value times 10 seconds = interval 60 seconds default.

https://github.com/atc1441/ATC_MiThermometer#advertising-interval

pvvx commented 6 months ago

This is not a "Advertising Interval".

The Bluetooth specification v4.2 allows the advertising interval to be anywhere between 20 ms and 10.24 s.

bam80 commented 6 months ago

I bet I pasted it correctly, so your point probably needs further explanation.

Still, the other firmware allows to set the "Advertising interval" bigger? Could we do the same here, as it might be really difficult to find a workaround.

pvvx commented 6 months ago

Still, the other firmware allows to set the "Advertising interval" bigger?

https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/app_config.h#L9 In the ATC1441 firmware, the adv. interval is fixed: 3000 * 625 us = 1875000 us = 1875 ms = 1.875 sec. https://github.com/atc1441/ATC_MiThermometer/blob/master/ATC_Thermometer/ble.c#L63C22-L63C42

bam80 commented 6 months ago

This is not a "Advertising Interval".

What is it then? Can we have the same setting here, still?

pvvx commented 6 months ago

What is it then?

Read up on how Bluetooth works.

TelinkMiFlasher.html allows you to set the maximum time for transmitting new measurements to 250 seconds. This has been possible since the first firmware versions, for three years now...

bam80 commented 6 months ago

I see it's not documented, as well as what that "new measurements interval" is and how it relates to the advertisement. Probably worth to make a note in the Readme.

Anyway, can we make that other interval bigger, or it also restricted by some BLE spec?

bam80 commented 6 months ago

In the other fw I see it allows to set up to 10min of the "Advertising interval" (it's still not clear how it relates to BLE Advertising interval and to a "new measurements interval" here): image https://atc1441.github.io/TelinkFlasher.html

So we probably could make the our interval bigger than 250 sec, too?

pvvx commented 6 months ago

Use firmware from atc1441.

bam80 commented 6 months ago

TelinkMiFlasher.html allows you to set the maximum time for transmitting new measurements to 250 seconds.

As the interval for "new measurements" is not documented, could you clarify what it does exactly?

I had a strange behavior when tinkering with it. If I use default values:

then the behavior is as expected: I see new MQTT packets in the broker every 10 seconds.

But if I change the new measurements interval, things get wild and I start to receive the MQTT packets every advertisement interval or so.

pvvx commented 6 months ago

This is the action of your MQTT broker. Contact its creator.

The advertising formats used have documentation, but what the broker does is unknown.

bam80 commented 6 months ago

OK, that might be. Still,

As the interval for "new measurements" is not documented, could you clarify what it does exactly?

pvvx commented 6 months ago

“new measurements” is the transfer of new measurement results. The transmission packet contains a measurement number to help filter out duplicates.

Since Linux cannot work with Bluetooth standards released after 2014, it is necessary to use outdated versions of BLE advertising, which require constant transmission in increments of no more than 10 seconds. And these transmissions, in the old standard, do not have feedback - the thermometer does not know whether its message was accepted or not. Also, many devices operate in the radio network and overlaps occur - collisions. For these reasons, transmission duplication is used. Duplicate BT advertising broadcasts require increased battery consumption on the device. To further pollute the planet with battery waste, Linux does not include support for new standards. All European and American Linux distributions cannot work with the new Bluetooth standards. For what reasons this happens, I don’t know.

Since 2014, additions have been introduced to Bluetooth standards that allow communication over much longer distances without increasing the transmission power of devices. At the same time, BLE communication in the “LE long Range” format is possible over distances of up to 1.6 kilometers in a straight line, without obstacles. Adapters and other Bluetooth equipment manufactured after 2014 support these options. But the software in Linux limits users to an outdated standard.

And instead of supporting new standards, since 2014, errors have been introduced into Linux so that the old standard v4.2, which also slightly expanded the communication range in Bluetooth, does not work.

bam80 commented 6 months ago

The transmission packet contains a measurement number to help filter out duplicates.

It seems like Theengs gateway I use just doesn't support it. I'll file an issue there to suggest that feature. Thanks.

bam80 commented 6 months ago

I'll file an issue there to suggest that feature.

https://github.com/theengs/gateway/issues/202

pvvx commented 6 months ago

Your request is not clear. What is the problem of transmitting each received BLE advertising packet by the gateway further to MQTT? The function of the gateway is to transmit. The processing must be done on the end side, for example in the Home Assistant integrations themselves.

A constant reception together with duplicates indicates that the sensor is working and allows you to estimate the number of reception failures. That is, this is additional information and is needed in many cases.

It would be more correct if they send you away with such requests.

pvvx commented 6 months ago

MQTT app I use has limited ...

Write there.

For example, some Home Assistant integrations use averaging of received measurements over a user-defined interval. This increases accuracy while reducing the load on the small controller in the battery device. Do you want to deprive other users of this functionality? All this for the sake of some crooked program of yours?

bam80 commented 6 months ago

The feature I requesting is optional.

It would be more correct if they send you away with such requests.

Thank you for the wish. All the best you too.

pvvx commented 6 months ago

In the IoT field, sensors that give readings once an hour are not needed. In a few minutes the whole house burns down.

The feature I requesting is optional.

Optional features lead to a lot of confusion for other users. And it takes time to parse, instead of doing what is needed, it takes time away from developers.

So you are engaged in sabotage? It's time to block you.