ATC_MiThermometer
ATC_MiThermometer copied to clipboard
pvvx
Clock information not reliable
Hello,
first of all I wish to thank you for what you are doing on this project.
I noticed that the clock information is not reliable, time calculated by the device runs faster than conventional time.
One week ago I set the clock
11:32:42: Device Date: 2021-02-17 11:32:38.000
and today I checked the clock
10:09:23: Device Date: 2021-02-24 10:17:17.000
The device clock is about 8 minutes in advance, more da 1 minute/day.
Is the issue related to a not reliable internal clock frequency of the device?
can we foresee a parameter to fine tune the alghorithm you are using to calculate the time?
Thank you Gabriele
I noticed that the clock information is not reliable, time calculated by the device runs faster than conventional time.
The SDK uses binary libraries associated with restoring the time counter after sleep mode. Source codes are missing.
Clock_time() is used. This is a 32-bit hardware counter reading at 16 MHz (1/16 μs). It is powered by a crystal oscillator that turns off in sleep mode, and the time is counted from a 32 kHz RC oscillator. In sleep mode, the counter is reset by a timer on the RC oscillator. There is no clock crystal at 32768 Hz on the board.
Just a further question, this means that the reliability of the Time depends on the sleep mode duration? to you think it is possible to handle a SW correction over the hw counter readings? Is this an issue observed by somebody else or it depends on my settings?
Sorry is the question sounds stupid, I'm just a mechanical engineer with a very poor HW background.
RC oscillator is unstable. Its course is highly temperature dependent. Calibrating the built-in RC oscillator takes time and increases power consumption. Moreover, calibration must be done often, and this is unprofitable.
The device is cheap and has no quartz for watches. The clock can be adjusted every day.
The original firmware counts the time by 1 hour so that leaving is invisible.
Thank you for the explanation, I fully agree. I have to understand how to automatically adjust time once a day and it will work fine. Do you have any suggestions on how to do this task?
In version 2.4:
11:58:28: Send delta time ok 11:58:29: Device StepTimeSec: 1000000.813 us
I have tuned the parameter and now it works perfectly! Thank you! How does it work the modification you have done? I would like to understand just the principle.
GE
I have set: Device StepTimeSec: 1000845.125 us Since I have uploaded new sw 2.6 it started to be a little bit in advance, I have to recalibrate.
G
I'd love to see an automatic clock calibration function added to the website where the last calibration time (stored in the device?) is compared to the current time and the clock delta is calculated based on the drift.
It would be nice also for Esphome to synchronize the Xiaomi clock every 6 hours or so.
Or to have a python script automatically connect to all ATC sensors and re-sync their time, could run this as cron.
I was wondering whether I can pointed towards any command line option to adjust the clock. The delta time adjustment helps a bit, yet after a few days it shows that this isn't enough. Perfect would be if I could just setup a cronjob setting the clock once a day. Tasmota actually has a command for setting the time, but I'm getting an error and I guess this is just for the stock firmware.
It would be nice also for Esphome to synchronize the Xiaomi clock every 6 hours or so.
Esphome is not supported until the large number of receive gaps in BLE is fixed. Has unstable operation and does not support progressive options in Wi-Fi 6. Or solved in a different way - with an alternative BLE chip.
I have 3 esp32 modules as BLE receivers for my 8 xiaomi’s. Now i’m testing esp32 with tasmota FW and first results are better than with esphome - in tasmota all seen xiaomi’s are shown seconds after power-on, while in esphome it can take up to a minute. I have some minor issues with wifi disconnecting, but thatks another story and can be solved. And here i can immediately see which modules are in a range of esp module. So, i can confirm that tasmota is better than esphome in this case, eventhough i’m a bigger fan of esphome, because i can program module exactly the way i want, while tasmota is preprogrammed.
I'd love to see an automatic clock calibration function added to the website where the last calibration time (stored in the device?) is compared to the current time and the clock delta is calculated based on the drift.
I use 7 devices with your software and I love it. Thank you! All the clocks on my devices running different. So I'd also like an automatic calculation button for the delta in TelelinkMiFlasher.
Maybe it is possible to store the last update datetime of the clock on the device. Then the calculation with the tree times (update, global and device) and the actual delta is easy. If this is not possible you can maybe store the update datetime as cookie on the browser with the mac of the device. That'd only work if you always use the same browser, but it's way better than manual calculation.
Receiving and transmitting data in javascript has a jitter of 2.5 seconds (BLE connection interval).
Requires a large counter of seconds since the clock was last set.
The minimum period for the next delta calculation is more than 3 hours.
Included in version 3.6b.
It would be nice also for Esphome to synchronize the Xiaomi clock every 6 hours or so.
Or to have a python script automatically connect to all ATC sensors and re-sync their time, could run this as cron.
I'm using the delta time option but if someone has a python script for time syncing via cron, please share it. Thanks
You can also synchronize the time via ESPHome: https://esphome.io/components/display/pvvx_mithermometer.html?highlight=lywsd03mmc#only-synchronize-the-time-once-a-day
You can also synchronize the time via ESPHome: https://esphome.io/components/display/pvvx_mithermometer.html?highlight=lywsd03mmc#only-synchronize-the-time-once-a-day
This actually doesn't work for me, I had it set up like that but the time still drifted away really bad.