Supporting uptime/battery time in the custom format (0x181a)

[csiki2]

First, thank you for your library, I am using it for more than a year (since v2.5) and it's perfect!

When I refreshed my new devices, I noticed that for the LYWSD03MMC, I even can set the proper date.
If the device is able to measure the time for this range; is it possible to add extra 2 bytes to the custom format (0x181a) and send the "uptime"/"battery time" in hours (one byte in days might be too small)?
If somebody changes the battery (hard reset, battery voltage significantly greater than the last measurements) the firmware would save the starting date of the battery change somewhere and then just send the date difference in hours in the advertisements.
With this feature we would be able to follow easily the battery life for each device.
Thank you very much!

[pvvx]

Unsolvable factors:

1. Changing the advertise format will require third party software changes.
2. It is not possible to programmatically determine the replacement of the battery and its condition.
   The CR2032 voltage is highly dependent on temperature. When replacing with a new element with a lower temperature, the voltage in the new element may be less.

Batteries are sold with different conditions, shelf life and different manufacturers. They have different capacities in Ah.
The thermometer consumption strongly depends on the settings and operating modes. With frequent connections, the time will be less.
For warranty work, only a recommendation is possible to replace with high-quality batteries every 10..12 months when working in the factory settings in the passive advertising polling mode.

[csiki2]

1. Changing the advertise format will require third party software changes.

I thought that your code generates the 19 bytes advertisements output and you only need to add the extra 2 bytes. Isn't that the case?
On the reading side everything will work till they didn't expect exactly 19 bytes, but minimum 19 bytes for 0x181a.

2. It is not possible to programmatically determine the replacement of the battery and its condition.
   Battery consumption #165 (comment). When replacing with a new element with a lower temperature, the voltage in the new element may be less.

Yes, but I don't consider this a big issue or even to be a valid use case.
First. Right, my new battery went to nearly 70% (around 2.8V) at 5-6C, but that is still way higher than a near depleted battery at 36% and 2.5V, room temperature (15+ °C difference!!!).
Second. I expect somebody to replace the battery at same temperature or the new battery in a better temperature (changing outdoor battery). Could somebody mislead the detection? Of course. It's their tool, if they happy with it then do it. The normal users just wont do it, why would they do it?

[pvvx]

I thought that your code generates the 19 bytes advertisements output and you only need to add the extra 2 bytes. Isn't that the case?
On the reading side everything will work till they didn't expect exactly 19 bytes, but minimum 19 bytes for 0x181a.

All Integrations will not work.
Samples:
https://github.com/custom-components/ble_monitor/blob/master/custom_components/ble_monitor/ble_parser/atc.py#L13

Adding any byte to the advertising packet increases battery consumption.

[csiki2]

I see, all of them is 0x181a and it can rely only on the message length?
Totally new format with a version byte as well? :D

[pvvx]

• During a cold start, the thermometer does not know the past battery voltage. The voltage of the battery under the influence of the load is different and does not mean anything. At the cold start of the load more.
• It is almost impossible to determine the amount of charge in a CR2032 battery.

Describe the algorithm for determining battery replacement.

I have installed batteries that have been stored for over 10 years. The initial voltage on them was 2.0V. After a day of work, it rose to 2.8V.

[csiki2]

Yes, it would need to save the voltage time to time. Or we would lose that date too?
Does the statistics lost on battery change or at a firmware update?

I would simply say if the battery is above 3V at start and the last save of the battery is below 2.6V then there was a replacement.

[csiki2]

I have installed batteries that have been stored for over 10 years. The initial voltage on them was 2.0V. After a day of work, it rose to 2.8V.

Do you consider that a regular usage? :D
Reset the battery start date through the flash tool in such exotic case.

[pvvx]

And in this exotic case:
If a capacitor is installed in the power supply (these are models from Qingping) and people themselves restore in LYWSD03MMC, then the voltage is always 3.0V. Even with an old battery. This is their property/feature.

---

The battery change event can only be registered by setting it in the configuration when connected.
Constantly transmitting the battery installation time is a waste of battery life.

Home Assistant allows you to write a script that calculates the time and battery life without resorting to changing the program in the thermometer.

At the time of its appearance, only 14 months have passed since 11.2021 and I have not replaced a single battery on the thermometer with custom firmware. The battery life is still unknown.

[csiki2]

In the capacitor case you don't get any meaningful battery percentage either.

Constantly transmitting the battery installation time is a waste of battery life.

Elapsed time, but you are right, 3 bytes already used on battery (I didn't check, but my guess is that the percentage is a formula from battery_mv).
uint16_t battery_mv; // mV
uint8_t battery_level; // 0..100 %

Home Assistant allows you to write a script that calculates the time and battery life without resorting to changing the program in the thermometer.

Is it possible to attach persistent values based on - let's say - MAC address and then propagate new properties to the device?

How would adding one extra byte change the battery life?
One advertisement is 14..20 uA at 3.3V for the total 27 bytes?

[pvvx]

Whole ad package: 10 + adv_data_len + 1
if 19 bytes advertisements data -> 30 bytes, consumption increases with RF TX by (30+x)/30 times
if 12 bytes advertisements data -> 23 bytes , consumption increases with RF TX by (23+x)/23 times

[pvvx]

In the capacitor case you don't get any meaningful battery percentage either.

In no case will you get a meaningful percentage of battery charge by measuring only the voltage of CR2032.
A fully discharged CR2032 battery will typically output 3.0V (+25С) on a high impedance tester.
But the battery is not delivering current.
Example of comparison with measurement of different load in CGG1 (there is a capacitor and an uncontrolled consumer E-Ink)
If a capacitor is installed in the thermometer on the printed circuit board, then it is charged in the time interval between advertisements. In this case, the consumption is about 6..9 μA (depending on the type of thermometer). During the transmission of advertising, the capacitor is discharged and at this time the voltage is measured. This ensures that the batteries are fully utilized.
In Xiaomi LYWSD03MMC, the capacitor is not installed in place on the PCB.
Ultimately, the battery voltage depends on the transmission current, previous actions, capacitor capacity, thermometer type, active scan requests, measurement position in the processor activity cycle, temperature, battery manufacturer, shelf life before sale...
As a result, most official firmware simply does not show battery percentages.
I'm waiting for an example of a solution to this problem that will satisfy the majority :)

The battery voltage measurement process takes about 83 µs. The current consumption during the measurement is about 3mA if no other loads are active.
RF transmission - more than 8 mA at +0 dB.
Shown here is an example consumption graph for the longest activity cycle in ad mode when measured with a CHTV3 sensor.

On the new CHT4x, cycle smaller.
The battery voltage graph on Xiaomi LYWSD03MMC will be similar, but inverted and with amplitude depending on the quality of the battery.

[csiki2]

Thank you for the explanation.
So the conclusion is that the battery percentage we get from LYWSD03MMC is not really good for anything and there is no point trying to measure the battery life in the device itself.

[pvvx]

Not certainly in that way. The analysis can be performed by a person who is familiar with everything described and has battery voltage graphs, but not a stupid processor in the thermometer itself.