Update problem v2.2.3 to v2.3.0 ESP32

[open1999]

Hello,

for your information.

If I update from version 2.2.3 to 2.3 the key is broken. I had to reinstall the software with https://web.esphome.io/

Same if updating from 2.2.3 to 2.2.4.

The only difference I saw is that under 2.2.3 in "Firmware->Hardware: ESP32 -"

In 2.2.2 no indication for Hardware.

With v2.3 Firmware->Hardware: ESP32"

Update 2.2.2 to 2.3 it's ok. Update 2.2.3 to 2.3 it's not ok.

thank you for this wonderful work.

[rstrouse]

I am not sure I understand what you mean by the key is broken. Are you referring to the API Key or the pin?

[open1999]

I apologize.

When I do an update (System->Firmware->Github Update), I can no longer communicate with the ESP32 (the key ;-)) and I have to flash the ESP32 using https://web. esphome.io/ to install your software.

This problem exists with version 2.2.3 to 2.3.0

[rstrouse]

I have tried with several devices to get this to fail. Which ESP32 device do you have?

[open1999]

ESP-32 30 pin

[rstrouse]

Onboard your device with v2.3.0. Make sure you have a backup first and apply that backup. In v2.2.3 it was possible that the download from Github could timeout while it was downloading and the firmware update did not properly rollback. This could be caused by a slow connection or wifi dropping or anything that could interrupt the stream from Github.

In 2.3.0 additional checks have been applied to roll back the update if it runs into this condition.

[open1999]

I tested several times, on different days. No network issues (1Gb).

Update 2.2.2 to 2.2.3 is OK Update 2.2.3 to 2.2.4 is not OK Update 2.2.3 to 2.3.0 is not OK Update 2.2.2 to 2.3.0 is OK

My message was for you to have the information.

I have a question if we want to flash a new ESP32 with version 2.3 how do we do it?

[rstrouse]

I have several devices and flashing from 2.2.3 to 2.30 does not exhibit the issue you described but I do understand the conditions where this can occur. Most will never see it as it has to do with the updated libraries in 2.2.3 and the need for additional delay times when the file stream is suspended or delayed from the source (Github). If it attempts to read data and the download is not ready to deliver more data, then it needs to allow the buffer to fill up before reading again.

This only happens when the network is pumping data consistently slower than the ESP32 can process it. v2.2.2 did not have this issue as the libraries for HTTPS ran slower than the ESP libraries for 2.0.14 used in v2.2.3. In v2.2.0 there is now a check to delay when the socket is not ready to deliver any bytes.

I will continue testing to see if I can generate any other failure modes since the ability to pull the release like I am doing is a bit of a novel concept. There is another library out there that does it but it proved to use too many resources.

[rstrouse]

I have taken a look at some of the failure modes. As it turns out the corruption is unlikely to occur when writing the firmware partition. However, when writing the data partition the ESP32 has no native rollback functions if there is a failure. I have been investigating the things that can cause interruptions while the file system is updating. Among them is movement of a motor while the data partition is being written. This action can lead to persisting the shade configuration data to the data partition.

I am working on methods to make sure this cannot happen.

[rstrouse]

Thanks for this I have focused on the v2.2.3 firmware and I think I have mitigated the issue in future firmware. In v2.2.3 the wait times for the return of the data from Githb were too fast and it would stop returning data from the site if there was any (even minor) interruption. The firmware that is doing the downloading is the firmware that is currently installed.

In the next version there will be a recovery url if there is a major interruption but the minor ones should no longer apply. I am going to close this for now until I get v2.3.1 out.