No periodic display refresh for MHO-C401

[znanev]

Victor, first I'd like to commend you for the wonderful job that you did evolving ATC's code to support the EPD display of MHO-C401 too!

I've updated the firmware on one of my devices yestarday with the latest code for MHO-C401 and I have to say that I'm quite impressed with the result!

I noticed a small issue on first sight, but I think that it is subtle for the longevity of the e-ink display. Your code doesn't seem to perform periodic full refresh of the display (showing all black segements, followed by showing all white segments, background ones included), and this causes some minor "ghosting" of the white segments:

The device on the left is running with Xiaomi's original firmware, the one on the right is running your code. I'm not sure if it can be noticed on this photo, but from afar the white background of the display on the right appears a bit more gray-ish compared to the original one (left).

During my reverse-engineering sessions of the e-ink display of MHO-C401, I noticed that the original firmware performs a full refresh after 32 partial updates. Generally e-ink displays need to have full refresh performed from time to time in order to de-energise the pigmented particles, otherwise they seem to become "sticky" and harder to operate, which shortens the life of the EPD.

[atc1441]

Observed the same behaivior, after a real reset(battery pulling) the full update is made so the code exists allready and simply needs to be called every ThirtyTwo updates ?!

[znanev]

@atc1441 Indeed the code is already there. I had a prototype for this refresh in my crude implementation:

https://github.com/znanev/ATC_MiThermometer/blob/9bf0ab1e08f00753031fb5eed1f09ea2e18455e0/ATC_Thermometer/app.c#L112

But I suppose Victor will know better how to accomodate this change - probably introducing a counter in the epd driver itself.

[pvvx]

I don't know how long it takes to refresh.

[znanev]

I don't know how long it takes to refresh.

What do you mean - the delay following the DISPLAY_REFRESH (0x12) command? You should be waiting for BUSY_N to be de-asserted.

If you invoke the start-up init sequence for the EPD, that should do the trick?

[pvvx]

What do you mean -

(English translator is wrong)
Time period before new update.

refresh after 32 partial updates.

The effect does not appear in 24 hours.
I cannot calculate what period is needed.

[znanev]

I think that time period has no play here. What I meant was the number of invocations of the function, that is "drawing" to the EPD display.

As far as I can see, it's probably this function in your code:

ATC_MiThermometer/src/epd.c

Line 332 in f57e38c

_attribute_ram_code_ int task_lcd(void) {

So if you keep track of how many times it has been invoked, you should re-initialise the display after every 32 invocations (the end goal is to show all black segments, then all white ones; with both black and white big background segments included). At least this is what the original firmware does, and also any other EPD-related firmware - the display needs this full refresh in order to keep it operational for longer, otherwise it's life gets shortened.

I see where you might get confused about time period. I own several other EPD-based Xiaomi devices, like Mijia LYWSD02MMC (hygrometer / thermometer with clock). Indeed this device does full display refresh based on time periods - every half an hour. But this is done due to the fact that the primary functionality of this device is to keep track of the time, so you have guaranteed at least 30 partial updates within half an hour (every minute change). But the case with MHO-C401 is different and from observation it performs full display refresh after 32 changes of the temperature / humidity values.

[pvvx]

Today I will build "Refresh LCD". Will be in version 2.1

PS: In the original and in the code, the work with E-Inc is incorrectly built. I will not redo this. I will build 'refresh' and that's it.

[znanev]

It's a bit of off-topic, but is it possible to also take a look at the following pull request when building the new version: #42. It's not a critical functionality, more like a cosmetic one :)

[pvvx]

E-ink refresh cycle
https://pvvx.github.io/MHO_C401/power_altfw.html

[pvvx]

Integration in Mi-home?



Is it possible to find a Xiaomi sensor without ad encryption? Then it is possible to emulate such a device...
Encryption kills the battery...

[znanev]

Integration in Mi-home?

No, I didn't mean Mi-home at all. I use Home Assistant and this is how the original one appears:

And this is the one with your firmware:

You see, it is really just nit-picking, it is "cosmetic" only - the "Sensor type" field is wrong if the correct bytes are not used...

Both sensors are integrated with this custom component:

https://github.com/custom-components/ble_monitor

It dosn't connect to devices and uses passive scanning only, so doesn't effect the battery at all.

As for encryption-less sensors, the clock that I mentioned doesn't encrypt its broadcasts: LYWSD02MMC. Also MHO-C303 (alarm clock / thermometer / hygrometer) uses unencrypted broadcasts.

Edit to add: Thanks, the sensor now appears correctly in Home Assistant:

[znanev]

Just chiming in to report that I've tested the latest version of the firmware for MHO-C401 - v2.1a. Everything looks fine (as far as I was concerned). The broadcast contains the correct bytes for sensor type (as reported above), and the full refresh now clears the "ghost" segments and the background stays as white as the original one.

Thank you, Victor!

[pvvx]

The sensor itself records data.


For the v2.1 test, i connected to the source-programmer with 3.3V and the CR2032 battery was charged again. :)