ESPHome ePaper stopped working after ESPHome update

[Busta999x (Michael Horton)]

Ok total ESPHome noob.

1st device a Seeed 7.5" paper display been working great.

There have been two update of ESHome in the last week.

The first update killed the ePaper device it just went blank and no longer updated in fact is was completely blank.

Tried updating the ePaper device and I am now getting the following when attempting the install

RAM:   [=         ]  12.4% (used 40604 bytes from 327680 bytes)
Flash: [========  ]  75.1% (used 1378030 bytes from 1835008 bytes)
========================= [SUCCESS] Took 5.48 seconds =========================
INFO Successfully compiled program.
INFO Connecting to 192.168.1.171 port 3232...
INFO Connected to 192.168.1.171
INFO Uploading /data/build/epaper-display/.pioenvs/epaper-display/firmware.bin (1390512 bytes)
Uploading: [============================================================] 100% Done...

INFO Upload took 12.75 seconds, waiting for result...
ERROR Error Update end: Error: Finishing update failed. See the MQTT/USB logs for more information.

I am attempting update over wifi so unsure what or where to find the USB logs and where in MQTT is it storing logs?

Any ideas anyone? Thanks.

[Busta999x (Michael Horton)]

Ok found a setting to push logs to Home Assistant set it and then re-ran the install

Logs report

Logger: homeassistant.components.esphome.manager
Source: components/esphome/manager.py:388
integration: ESPHome (documentation, issues)
First occurred: 17:39:31 (6 occurrences)
Last logged: 17:39:36

Lounge eInk Display: [W][esphome.ota:321]: Error ending update! error_code: 132
Lounge eInk Display: [E][component:286]: esphome.ota set Error flag: unspecified
Lounge eInk Display: [W][component:407]: esphome.ota took a long time for an operation (12948 ms)
Lounge eInk Display: [W][component:408]: Components should block for at most 30 ms
Lounge eInk Display: [E][component:313]: esphome.ota cleared Error flag

Not actually any wiser on the remedy?

Anyone experienced this or have any ideas on fixing it?

[Busta999x (Michael Horton)]

OK tried a device reset.

Then connected via usb

Then Prepped device install

Saved the Install (yaml) to local file and transferred to epaper over usb

All went successfully.

Device logs

[17:48:43][C][safe_mode:018]: Safe Mode:
[17:48:43][C][safe_mode:019]:   Boot considered successful after 60 seconds
[17:48:43][C][safe_mode:019]:  Invoke after 10 boot attempts
[17:48:43][C][safe_mode:019]:  Remain for 300 seconds
[17:48:43][C][web_server.ota:224]: Web Server OTA
[17:48:43][C][api:207]: API Server:
[17:48:43][C][api:207]:  Address: 192.168.1.171:6053
[17:48:43][C][api:212]:   Using noise encryption: YES
[17:48:43][C][http_request:013]: HTTP Request:
[17:48:43][C][http_request:013]:  Timeout: 10000ms
[17:48:43][C][http_request:013]:  User-Agent: ESPHome/2025.7.1 (https://esphome.io)
[17:48:43][C][http_request:013]:  Follow redirects: YES
[17:48:43][C][http_request:013]:  Redirect limit: 3
[17:48:43][C][http_request:021]:   Watchdog Timeout: 15000ms
[17:48:43][C][mdns:122]: mDNS:
[17:48:43][C][mdns:122]:  Hostname: epaper-display
[17:48:46][D][api:146]: Accept 192.168.1.168
[17:48:46][W][component:307]: api cleared Warning flag
[17:48:46][D][api.connection:1466]: Home Assistant 2025.7.2 (192.168.1.168) connected
[17:48:49][I][waveshare_epaper:4235]: Power on the display and hat
[17:48:59][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:09][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:19][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:29][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:36][I][safe_mode:042]: Boot seems successful; resetting boot loop counter
[17:49:36][D][esp32.preferences:142]: Writing 1 items: 0 cached, 1 written, 0 failed
[17:49:39][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:49][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:59][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:09][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:19][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:29][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:39][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:49][I][waveshare_epaper:4235]: Power on the display and hat

Then just repeating the last entry

Then I get this

[17:49:36][D][esp32.preferences:142]: Writing 1 items: 0 cached, 1 written, 0 failed
[17:49:39][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:49][I][waveshare_epaper:4235]: Power on the display and hat
[17:49:59][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:09][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:19][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:29][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:39][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:49][I][waveshare_epaper:4235]: Power on the display and hat
[17:50:59][I][waveshare_epaper:4235]: Power on the display and hat
[17:51:09][I][waveshare_epaper:4235]: Power on the display and hat
[17:51:19][I][waveshare_epaper:4235]: Power on the display and hat
[17:51:29][I][waveshare_epaper:4235]: Power on the display and hat
[17:51:38][I][online_image:109]: Updating image http://192.168.1.168:10000/epaper-display/epaper-display?viewport=800x480&eink=2
[17:51:43][D][http_request.arduino:134]: Received response header, name: etag, value: 
[17:51:43][D][http_request.arduino:134]: Received response header, name: last-modified, value: 
[17:51:43][D][http_request.arduino:140]: Content-Length: 4858
[17:51:43][D][online_image:175]: Starting download
[17:51:43][D][online_image:194]: Allocating PNG decoder
[17:51:43][I][online_image:212]: Downloading image (Size: 4858)
[17:51:43][W][component:407]: online_image took a long time for an operation (4730 ms)
[17:51:43][W][component:408]: Components should block for at most 30 ms
[17:51:43][D][online_image:089]: Allocating new buffer of 48000 bytes
[17:51:43][E][online_image:092]: allocation of 48000 bytes failed. Biggest block in heap: 24564 Bytes
[17:51:43][E][online_image.png:086]: Error decoding image: Incorrect PNG signature
[17:51:43][E][online_image:250]: Error when decoding image.
[17:51:43][I][waveshare_epaper:4235]: Power on the display and hat

[Busta999x (Michael Horton)]

So it now looks like the issue is the png output file it requests from Puppet is no longer compatible.

As far as I can tell the png file has not changed.

SO cannot fathom why the esphome device will no longer accept it.

Any ideas ? I have reached the end of my diagnostic skills (such s they may be).

[WallyR (Wally)]

The heap (a type of memory) do not have space available for the image to be store in.
No idea how to fix it though.

Maybe a NVRAM reset can do it.

Factory Reset Button

And btw. ESPHome should not be updated whenever a new version comes out.
Check if there are fixes or new features for your use case and if not then skip the update.

[zoogara (Daryl)]

Have you tried changing the format to BMP in the Puppet url?

[Stubborn (Stub)]

BMP will take much more space. I think that is going in the wrong direction…
I think incorrect sig error is a lie. It is just an empty file because it failed to write to memory.

[17:51:43][D][online_image:089]: Allocating new buffer of 48000 bytes
[17:51:43][E][online_image:092]: allocation of 48000 bytes failed. Biggest block in heap: 24564 Bytes

See the problem I posted today in parallel:

Online_image not respecting buffer_size parameter

Use case SEED Studio XIAO 7.5” ePaper Display Display dashboard via puppet I have tried multiple different buffer sizes both with arduino and esp-idf and per the logs it always allocates 48000. The image is never more than 7000 bytes the huge buffer is not needed and causes it to fail 80% of the time. Is this a bug or am I misunderstanding? esp32: board: esp32-c3-devkitm-1 framework: #type: arduino type: esp-idf ======================================== online_image: - id:…

[Stubborn (Stub)]

@WallyR

And btw. ESPHome should not be updated whenever a new version comes out.
Check if there are fixes or new features for your use case and if not then skip the update.

Not the most practical solutions, if you have dozens of devices. If you roll ahead for new devices you can never redeploy config changes to older ones.

Seeing as bricking changes are common, I think we need the ability to have multiple dockers of different versions of ESPHome and link devices to different instances.

[Stubborn (Stub)]

@WallyR

Maybe a NVRAM reset can do it.

Factory Reset Button — ESPHome

I don’t think that will do any different than reloading it via a serial. And you still will need to do that step after a reset.

Can a dev confirm that theory?

[Busta999x (Michael Horton)]

The image is 5k and the limit 48k I don’t think it’s reporting the issue correctly.

This all started last week with the first of the two updates.

[WallyR (Wally)]

The data partition of the flash is not erased on updates and at some point it can get full with unused data.
The factory reset will erase the data section and restart, so it will be as if you wrote the firmware for the first time.

I have a factory reset and a reset button on all my ESPHome configs, because I have already experienced a case with it.

[Busta999x (Michael Horton)]

So if I understand this, I need to install a reset to factory button and then periodically reset to factory and re-install again.

Anyone know if there is an intent to resolve this?

Does this apply to all ESPHome devices?

Do they all require wiping and rebuilding periodically?

Just want to set my expectations of a second ESPHome device.

Mine ran for about a month before this error.

[WallyR (Wally)]

Not reinstall again.
The device will reboot with the flashed firmware, but the data partition will be cleared.
I think the build up in the data section occurs when you flash new firmwares.
I only have it occur when I have flashed a lot.
Once I have the right firmware and I have factory reset it, then it runs fine.

[Busta999x (Michael Horton)]

The issue was resolved with a workaround.

Instead of using the small,5kb, png files use the large bmp format , 48kb and all is back up and running.

Thanks to everyone who helped here, very much appreciated.

[travs]

FWIW, same thing happened to me and I switched to the bitmap option and it’s much more readable than the PNG via Puppeteer. The Youtube tutorials use the PNG - so hopefully someone stumbles across this and makes the switch.

[Busta999x (Michael Horton)]

I added a comment to the bearded tinkers YouTube video on YouTube.

[goobags]

This issue also occurs using the Kindle Lovelace Screensaver add on, so it is not just an issue with Puppet. Thanks for the pointers towards BMP.

[gferon (Gabriel Féron)]

The solution was actually quite simple. By default, the PSRAM of ESP32 boards is disabled on ESPHome builds.

Speaking for the Seeed Studio TRMNL 7.5" (OG) DIY Kit specifically, which comes with a ESP32-S3-Plus, you can benefit from the 8 MB of onboard PSRAM.

The board declaration now looks like this:

esp32:
  board: esp32-s3-devkitc-1
  flash_size: 16MB
  framework: 
    type: esp-idf

psram:
    mode: octal
    speed: 80MHz

With this, you can use any image format you want (and dozens of pages to rotate from!)

Cheers!

EDIT: I have submitted a PR to mention this in the Seeedstudio guide for this specific board Document PSRAM support for ESP32 configuration by gferon · Pull Request #3674 · Seeed-Studio/wiki-documents · GitHub