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.98k stars 207 forks source link

Spikes in temperature reporting #317

Closed erapade closed 1 year ago

erapade commented 1 year ago

I can see some spikes in the temperature measure. They are not frequent and I have no issues with them, I just want to report it in case it's a FW issue. I don't see the same issue in the other metrics and so far this is just on two out of 10 devices:

By the way, Thanks for a great work

image

pvvx commented 1 year ago

Specify platform used, integration installed, BT adapter used, thermometer type, and BLE advertising format type.

Such problems are seen on RPi and other platforms using UART communication with a BT adapter.

And also when using ESPHome on ESP32 due to the overload of the program for the available resources of the ESP32, the truncated implementation of the TCP stack, the inevitable defragmentation of dynamic memory in small SoCs that do not have MMU.

These hardware problems are solved by installing a USB-BT adapter.

The software limit of readings from the sensor is -45.00С to +129.99С even if its data is error. Limited by the register value from 0 to 0xFFFF. A failure (0xFFFF) is checked and discarded. The checksum of the data transmission from the sensor is also checked. Other errors are possible with memory and CPU failures in the SoC. This is unlikely.

erapade commented 1 year ago

"Specify platform used: , integration installed, BT adapter used, thermometer type, and BLE advertising format type." Are there anything missing below

Hardware Version: LYWSD03MMC B1.6, Software Version: 4.1, Sensor: SHTC3 (SHTV3) Custom config HEX string: 55032000002804a9043184b400 Advertising type: BTHome v1 I'm using a Raspberry PI 3B with Home Assistant, no extra BT adapter (to my knowledge)

One thing though. If Beta FW 4.2 is advertised as 4.1, I might have been running on that (at least on one of the sensors. The reason I think so is that one of the units also drained a lot of battery and when re-flashed (about 19:00 yesterday) with 4.1 the battery was not that heavy drained anymore, see pictures below: image image

Why the cyan one started to drop in voltage in the middle of the night I have no clue, that one is definitely not running on Beta

erapade commented 1 year ago

As I'm using the RPI 3B internal BT connection I guess that is the root cause for the spikes and in that case I guess this can be closed. Question though.

  1. Is this something that can be fixed on the HA side?
  2. Will encrypting fix the issue
pvvx commented 1 year ago

In the release of version 4.2, the calculation of battery per transmission is now averaged over 16 measurements. Otherwise, there was a lot of noise in the charts. The final version 4.2 has a lower consumption compared to version 4.1. Tested on LYWSD03MMC B1.4, B1.9 (i don't have any other versions of LYWSD03MMC to test). And in version 4.2, the 'connection latency' parameter is limited to 1 second to increase the stability of the connection. Otherwise, failures of BLE timings occur in devices where the manufacturer did not solder capacitors to the power supply (there is none in LYWSD03MMC). Large fluctuations in voltage and percentage of CR2032 batteries occur due to varying temperatures. Also quite often the battery contact goes off and this is accompanied by a lot of noise and fluctuations on the graph.

  1. Is this something that can be fixed on the HA side?

I do not think that's possible. I don't have RPi3/4 to find out possible errors.

  1. Will encrypting fix the issue

Perhaps, but there are nuances. If the error does not create an analogue of a close format for another type of device.

erapade commented 1 year ago

Thanks for answering so quick. I will monitor it for some days, maybe switch to beta for half of the fleet

Concerning the voltage measure I switched batteries between the two devices with the lowest voltage and this was the result

image

Surprisingly (at least for me) both got a higher (and normal) measured voltage. Maybe as you said it could have been a bad connection to the batteries. I guess the alternative would be if it was the power-on reboot that fixed the voltage issue