LYWSD03MMC freezes after random time

[rk125]

I have some 12 LYWSD03MMC sensors around the house. 2 of them do freeze at random intervals, it might be week working or just some hours. Display is set to show humidity and battery, and while frozen values do not alternate any more. I take out battery, put it back and sensor works again. Battery is drained (level depends how fast I notice outage) and slowly recovers (can see on the graph). If I flash sensor with atc1441 image, it works for years without problem (setup and sensors working since 2020, wanted to move to more advanced image). I have v1.4 and v1.5 hw, both show the same behaviour. It seems location related, I would expect drops in readings, but cannot understand why sensor should freeze. Gateway is openmqttgateway if that matters, both active and passive modes are same. May be some ideas what could be the issue?

[pvvx]

It looks like a connection is being made and something is being entered into the thermometer configuration.
Try setting "pin-code"...

I have some 12 LYWSD03MMC sensors around the house.

I had more during tests.
But constantly work from 30 thermometers. No failures noticed since 2020.
At the same time, I do not use any gateways. And external communications are excluded - a large territory and no neighbors in the surrounding area.

---

For example, ESP32 with BLE connection and active data reading can drain the battery of any BLE device in a short time. The reason is that ESP32 does not have time to process BLE communication and the device has to repeat transmissions many times before confirmation. Consumption increases 50 times, compared to a regular BT adapter.

[rk125]

Oki, I will try pin code idea, will report back. Though I would expect that small bluetooth sign on frozen screen, if something would make connection before freeze, so frozen screen would have that sign. But I do not have it, screen shows just temperature and humidity or battery reading. And I would expect atc1441 freeze the same then.
By gateway I mean device between BT and ethernet (device sending mqtt messages) to get data into HASS or something, just like esphome BT proxy. For me HASS is on separate server in basement where there would be bad signal for BT network. In beginning I had OMG on ESP32 board (even old wroom with wireless IP connection), batteries on sensors worked fine for year and more with my network size (despite your warning that ESP32 is not good). Moved sensors to your firmware v4.3 june 2023, all except of those 2 sensors work flawlessly, batteries still holding. Then thought for bigger range and got rtl8761 dongle january 2024, OMG running on container on orangepi. Sensors work fine since then, batteries good, freezes are with those 2 sensors the same.
Area similar as yours, but wireless is everywhere (2.4GHz).
Thank you!

[rk125]

Hello!
Unfortunately keeps freezing same way.
One other sensor died, this time was understandable - old battery, was working for long time:

Display was the same - showing values, but it was not sending any. I took battery out, put it back, but this time did not help. Strange was the voltage reported when it died:

I took battery out, on multimeter with high impedance battery was 2.7V something, but with battery tester (which applies some load) it did not even start showing anything, so totally dead. It is understandable, 1.5 years good enough. But sensor was reporting normal voltage when it died.
Could this voltage detection somehow can affect my other 2 sensors? May be too aggressive low battery detection? For these other sensors I can take battery out and put it back, it continues to work, though from graph can see that sensor was draining battery while frozen.
One idea just came in my mind, need to test though. I was greedy and wanted to squeeze out of batteries all what is in them and so followed #11 and were adding those tiny yellow 100uF SMD tantalum capacitors to sensors. All of mine have them, was adding them on previous battery cycle. Will remove 100uF cap on one freezing sensor and will test.

[pvvx]

When the voltage drops below the operating level, the thermometer enters sleep mode for 2..3 minutes.
#569 (comment)

[rk125]

Well, voltage was "normal" on this long working sensor, see in graph. Of course with next transmit battery + capacitor charge was not enough any more.

If I take sensor which freezes with still good battery, I see that voltage "restores" over the time - so seems it was not in "into sleep mode for minimum consumption (the best examples - less than 1 μA)", but rather actively using battery as if it were active connection to the sensor, but there is no connection.

[pvvx]

The capacitor capacity is not enough to maintain power when starting a BLE connection.
The voltage quickly drops below the operating voltage, the processor does not have time to measure the voltage. Nothing is turned off, but on the contrary, it begins to consume more. In this case, the LCD control chip can save the image. Depends on the chip type and its minimum operating voltage. Some display driver chips have a sleep mode with lower consumption. But if the supply voltage drops sharply, the processor will not have time to switch it to this mode.

But if the supply voltage drops sharply, the processor will not have time to switch all its components to sleep mode, but will turn off according to the internal sensor...

Then the battery is no longer able to charge the capacitor and the spontaneously turned off chip...

The normal process looks like this:
When the temperature drops, the voltage of CR2032 drops.
The voltage is checked after periods set in the settings as the measurement period.

The same applies when powered by a solar battery...

The firmware from atc1441 has a smaller information table of services, which is read by the external adapter when connected. And here there is a direct dependence on the external adapter - on its settings of connection timings at the initial stage of connection. If they are short, then this is a large load on the thermometer battery. Since it requires the thermometer to transfer all the indices of available services in a short period of time.

And this is a requirement from the external adapter. The thermometer itself transmits other connection timing settings to it, and they are also described in a special UUID service. But switching to long intervals in the external adapter occurs significantly later and everything depends on external adapter...

I will not fully retell the Bluetooth standards here...