Add support for Lilygo T5-4.7 inch e-paper module

[lbonherbe]

Describe the problem you have/What new integration you would like The Lyligo T5-4.7inch is a great e-paper module based on an ESP32. It has a resolution of 960*540, 16 gray level and support partial refresh. I would be great to have it integrated in ESPHome the same / similar way Waveshare e-paper screens and modules are.

Please describe your use case for this integration and alternatives you've tried: To date there is no support for this module in ESPHome. The only support given by the maker is through Arduino IDE

Additional context This is the maker's GitHub for this product: https://github.com/Xinyuan-LilyGO/LilyGo-EPD47

[ashald]

@kaweksl will have to dig deeper into configs to see if I can spot anything important, but for the record - how did you change display settings when you was trying my component? Did you change auto_clear_enabled or any other options?

[kaweksl]

something like

display:
  - platform: lilygo_t5_47
    id: mydisplay
    rotation: 270
    update_interval: 60
    full_update_every: 1

i have also tried without rotation, with single it.printf

[ashald]

@kaweksl thanks! When you tried without rotation, did the direction of grey lines change, or it was the same along the short side of the screen?

[kaweksl]

Direction of lines stayed the same

[kaweksl]

I have tried yaml below and same issue, I can also see ghosting from like 3 uploads back, so screen is not cleaning old pixels no matter how many refreshes it gets. https://imgur.com/a/Rledbs9

substitutions:
  devicename: eh-lilygot5-1
  upper_devicename: Livingroom

esphome:
  name: ${devicename}
  platform: ESP32
#  board: esp-wrover-kit
  board: m5stack-core2

logger:

wifi:
  use_address: 172.16.108.51
  domain: ".home"
  ssid: kaw
  password: !secret eh-lilygot5-1-wifi
  fast_connect: true
  manual_ip:
    static_ip: 172.16.108.51
    gateway: 172.16.108.1
    subnet: 255.255.252.0
    dns1: 172.16.108.1

external_components:
  - source: github://ashald/esphome@lilygo-t5-47
    components:
      - lilygo_t5_47

font:
  - file: 'fonts/IBMPlexMono-Bold.ttf'
    id: fontid2
    size: 40

display:
  - platform: lilygo_t5_47
    id: mydisplay
    update_interval: 60s
    full_update_every: 1
    lambda: |-
       it.printf(115, 400, id(fontid2), TextAlign::TOP_LEFT, "asdasdasdasd");

[ashald]

Oh, great - I can reproduce the issue with the last config. Thanks! Now let me look into it...

[ashald]

@kaweksl I think I found the issue. The YAML you shared above looks good now. Could you try again please? Just make sure to wipe out caches in esphome ("Clean build files"/esphome clean depending on whether you use UI or CLI).

[llamaonaskateboard]

Firstly, great work everyone on building support for the T5-4.7. I'm currently using @vbaksa's component and even with a it.clear() at the start of my lambda I sometimes get background artifacts that trend along the line rows. They don't appear on every refresh and sometimes follow along different lines - see attached photo where it appears above the horizontal line at the bottom. Does anyone else experience this?

IMG_7978

[ashald]

@llamaonaskateboard I also had similar issue randomly with that component, I think I had to tweak VCOM screw to get rid of it.

I don't see any grayscale on your photo - could you try my component https://github.com/esphome/feature-requests/issues/1109#issuecomment-1046174098 to see if it will have the same issue? The issue others reported above should be fixed now.

[llamaonaskateboard]

@ashald Trying yours now and looking good so far. I do get a faint speckled grey background (no lines) after changing from USB to battery, but it seems to slowly disappear after being on battery for a while (or after multiple refreshes, my code deep sleeps for 10 mins).

IMG_7986

[tdroza]

@ashald Great work! - the alternating grey lines issue has gone for me with the latest version. I do still see some artefacts from previous content when doing a partial update though which I didn't have with vbaksa's version (see here). Setting full_update_every: 1 fixes it but causes the whole screen to flash to black fairly often which isn't ideal.

[martinberlin]

In EPDiy library using MODE_DU that is the fastest it also leaves ghosts. The trick is every N updates to do a full refresh. If I'm not mistaken, e-readers do the same, and from time to time they make a full refresh to clean screen completely.

[tdroza]

@martinberlin Yeah I had it doing a full refresh every 10 updates but the ghosts were very apparent after a single update. Doing a full refresh every time isn't a big deal for me in normal use because I'll have my device sleep for 5 mins, wake up, do an update and then sleep again. It's just really obvious when developing and I don't have the device entering sleep.

[ashald]

@tdroza I just pushed a fix for https://github.com/ashald/platformio-epdiy-monochrome which is used by my component to increase delay between row updates as per recommendation from @vroland - it might be a placebo effect, but I have an impression that it significantly increased image quality for partial updates with just extra 15ms of update time. Could you give it a try to see if there is any difference? You'd need to clean build files for your node in ESPHome so that it pull latest code. @Cadair could you also try my component to see if it will work for you in partial-refresh mode? https://github.com/esphome/feature-requests/issues/1109#issuecomment-1046174098

I also fixed the full_update_every in my component - looks like it wasn't decrementing the counter properly, and I also made it persist through deep sleep.

@llamaonaskateboard yup, I'm getting the same, but I also had it with all other versions of components I tried in this thread. I recorded a video demonstrating the issue.

@Schnabulation would love to hear your feedback as well as you tried the earlier buggy version.

@Plawasan I love your demo with the touchscreen, but one thing that caught my eye was the delay in screen refresh after you touch it. Would you mind trying my component in the partial refresh mode - I'm super curious to see how this demo would look like?

P.S.: Time-permitting, I plan to test 1 more enhancement for partial-refresh - the way it works right now is by rendering the image 10 times so that it becomes crisp enough. Based on me observations, sometimes there is still a little bit of ghosting from pervious iterations if switching from black background to white and vice versa. My plan is to try adding an option to control number of iterations so that one can set it to 20 or 30 and hopefully get a super crisp image that will look and feel like partial refresh without ay flashing - the update time will go from ~180ms to 2x-3x that, but hopefully it won't be an issue as the image won't be flashing but will be just getting crispier and crispier.

[Plawasan]

@ashald - tested, see the video here, this is the config I was using:

https://www.youtube.com/watch?v=0UdyiUQ990o

display:
  - platform: lilygo_t5_47
    id: t5_display
    rotation: 0
    update_interval: 10s
    full_update_every: 6

It definitely is MUCH quicker however there a lot of ghosting that only goes away after a couple partial refreshes.. full refresh actually seems to make it worse for some reason, it brings back the "shadows" that actually were not even visible after the partial updates.

Once thing that it did fix is the flipped y coordinates of the touchscreen, I had to update my touch areas but now they are where they should be.. i guess that's more for @vbaksa to look into.

Still doesn't work on battery though, won't even boot with the touchscreen connected, I have to physically disconnect it.

[martinberlin]

@ashald maybe in the full refresh you try to do a full black screen to remove all ghosts? E-readers do that from time to time but more subtly like inverting the image grays, I guess for the same reason. Yes, epapers are weird to control displays

[ashald]

@martinberlin yes, I fill it with white and then black. Would you suggest rendering inverse image? Should I fill it with black or white after that?

[martinberlin]

Not sure but is worth a try. I would try the easier and move on to next if doesn’t work, color inversion sounds easy if it’s only black and white though

[Cadair]

@ashald I have tried out your component and it's great, I have partial refresh and no significant ghosting. Thanks!!

The only thing I would say is that, while very minor, compared to vbaksa's component I think the contrast is a little lower after a full refresh, i.e. the background is slightly darker.

[Schnabulation]

@Schnabulation would love to hear your feedback as well as you tried the earlier buggy version.

@ashald I can confirm: with the latest version the stripes are gone and the display refreshes very fast. Exactly what I need. I'll stay on that version.

To have an accurate battery percentage that gets written back to Home Assistant I am still using vbaksa's integration, but only component "lilygo_t5_47_battery". The display component is commented out.

Thanks again for your work!

[Dianoga]

You can still have battery percentage written back to HA with @ashald's component. It's a little hacky feeling but works.

Define sensors

  - id: batt_volt
    platform: template
    name: ${esp_name} Battery Voltage
    device_class: voltage
    # lambda: return {};
    on_value:
      then:
        - binary_sensor.template.publish:
            id: plugged_in
            state: !lambda "return id(batt_volt)->state >= 4.2;"
        - binary_sensor.template.publish:
            id: charging
            state: !lambda |-
              float cvolt = id(batt_volt)->state;
              return cvolt >= 4.2 && cvolt < 4.8;
        - component.update: batt

  - id: batt
    platform: template
    name: "${esp_name} Battery"
    unit_of_measurement: "%"
    accuracy_decimals: 0
    device_class: battery
    lambda: |-
      int y = (1-(4.2-id(batt_volt)->state)/(4.2-2.9))*100;
      return y > 100 ? 100 : y < 0 ? 0 : y;
    update_interval: never

Within the display lambda

          // Now we're ready to read the battery
          double_t battery_voltage = id(t5_display).get_battery_voltage();
          double_t percentage = (1-(4.2-battery_voltage)/(4.2-2.9))*100;
          uint8_t battery_percentage = percentage < 0 ? 0 : percentage > 100 ? 100 : percentage;

          // Send battery info to the sensors
          id(batt_volt).publish_state(battery_voltage);

[tdroza]

@ashald I've tried your latest version and gone back to doing a full update only every 10 refreshes. There is still some ghosting but it's much better than the earlier version and fades after one or two updates which is much better than before. I'm also using your example code to display the battery percentage.

For info, my config is here: https://github.com/tdroza/HomeAssistantConfig/blob/main/esphome/epaper-t5.yaml

Brief summary: I have defined 4 pages (but really page 3 and 4 are just test pages with features that I'm playing around with) which can either be accessed directly by using the buttons on the device, or from Home Assistant by selecting the page from a dropdown. If you change the page on the device, it updates the selection in HA. The reason for allowing the page to be set in HA is that I have the device sleep for 13mins (can't remember why I picked that number!) so when it's sleeping the device buttons obviously don't respond, but it will find which page it should display from the dropdown when it next wakes up.

My 4 pages are:

1. House info (next appointment in family calendar (or current track title/artist if music is playing). Temperature in various rooms. Weather forecast icon, wind speed and temperature. Sunrise/sunset time.
2. Crypto balances of various coins, and amount changed since midnight using a utility_meter sensor
3. Graph of crypto portfolio balance - I just wanted to play with the ESPHome graph feature. This only works when the device is permanently powered, otherwise it loses the data history.
4. Current time displayed using a literary quote. I was attempting to recreate one of these (https://authorclock.com/) but don't have it fully working yet. I uploaded all of the quotes to a jsonbin.io account and created a sensor to fetch the quote for the current time by querying jsonbin with a jsonpath header, but haven't figured out how to get the result to wrap when I display it.

[Yazzcat]

Dear All,

Thank you so much for this integration! I am using Ashald's version to implement my dashboard. It is extremely fast, but it seems I have 'burn-in' / ghosting that I cannot get rid of anymore... Full / partial redraw does not fully clear the screen anymore. Even tried an arduino program using the original (no ESPHome) drivers to clear the screen multiple (> 10.000) times. No good.

Is is true these display can realy have burn-in, or am I doing something wrong? I have adjusted the VCOM from -0.6 to -1.04V (as far as I could go).

Thanks, Yazz.

[ashald]

@Yazzcat I've been using my component since [before] I posted it here almost 2 weeks ago, and I haven't noticed any difference in burn-in compared to how it was before. In other words, I noticed equal amount of burn-in regardless of what component is used.

Could you post a photo of the ghosting you observe?

One thing I noticed is that my use-case is such that there are no big changes on the display - just numbers changing values in the same positions - and it doesn't result into any ghosting. At the same time, when I try to do some tests that dramatically change what's on the screen, I did see some ghosting. I'm testing a workaround for that and will push an update shortly. The idea is that rendering the image on the screen is done by repeatedly telling it to show the same image. The currently released version does it either 10 or 16 times - I don't recall. That may result into some ghosting. Depending on the use-case, you may get entirely the artifact free image in 20-40 cycles. This would make refresh taking longer [objectively], but doesn't involve any flickering and it's just your image becomes crisper as milliseconds pass by.

Burn in is an issue for e-Ink and that's the primary goal of full-refresh - flip pixels into inverted state for some time so that they "exercise" and reduce burn in.

My home country is under military invasion right now so I have very limited time for this project, but I'll try to publish the above update as soon as I can so you can try it to deal with ghosting.

[ashald]

I happened to have some free time today and just pushed an update for my version of the component that allows controlling number of cycles for rendering on the display.

One disclaimer: I realized I confused myself and other a little bit. To be precise, my component always does "full update" - meaning it renders every single line on every iteration. What I refer to as "partial update," is when my component first inverses the image on the display to prevent burn-in, and then renders the image as usual. It's possible to render only those lines that changed - and I believe that's what @vbasksa's component does - which presumably should be more performant, but it resulted into more ghosting for me so I moved away from it. TL;DR: My component actually does full update every time, but what I call full update is "flashing screen" in inverted collors to prevent burn-in.

@Yazzcat, @tdroza et al - the version you've been using did "10 cycles" for rendering, which resulted in some ghosting. I just pushed a new version that bumps that to 20 by default. Also, I added new options so you can tweak number of cycles to your liking. Please don't forget to clean build files so that you'd get the latest version of the code.

I just got 2nd Lilygo and it works flawlessly without VCOM tweaking.

Without further due, latest usage instructions: Add to external_components:

external_components:
  - source: github://ashald/esphome@lilygo-t5-47
    components:
      - lilygo_t5_47

and configure it as:

display:
    platform: lilygo_t5_47
    full_update_every: 1 # optional (default:  1): 0 - never, 1 (default) - every, 2+ - throttled
    cycles_render: 20    # optional (default: 20): higher number -> less ghosting, crisper image, more time
    cycles_invert: 20    # optional (default: 20): higher number -> more timef or full update, but mor burn-in protection

And you can use other options from the base display component such as auto_clear_enabled (this wipes out the buffer but not the screen), update_interval etc.

Also, component now includes battery voltage sensor:

sensor:
  - id: battery
    platform: lilygo_t5_47

and then just read it as id(battery).state.

The only issue that I observe - and I observed it with all versions that were shared here so far - when you disconnect a Lilygo from USB and connect to a battery within a minute or two (or if it's powered by a battery while disconnecting), there would be some fading on white areas after either power_off() or deinit() (need to double-check which one actually does it).

P.S.: Advanced usage. You can call this functions to control parameters in runtime:

id(eink).set_full_update_every(2) # reconfigure how often display should do "full" update
id(eink).set_full_update_countdown(0) # or force "full" refresh on next update, can be any positive value
id(eink).set_cycles_render(30) # set render cycles count
id(eink).set_cycles_invert(30) # set invert cycles count

[Yazzcat]

Dear Ashald, I just read you last line in response to my post. My prayers are for you and your family. I am following the news closely and cannot believe this is happening. I hope you are safe.

Thank you for providing this enormous fast response still. I have tested it and it seems to work find. Need to test more to see how the ghosting is now. It is crisp for sure.

Do you have any suggestions how to get rid of the burn-in that was already done in previous use of the display? I've attached an image.

Yass .

[ashald]

Actually, happened to have a bit of extra free time today - added sensor for battery voltage to my version of component, see updated instructions in https://github.com/esphome/feature-requests/issues/1109#issuecomment-1059808670.

@Yazzcat I see 2 kinds of burn-in on your photo - bits of text here and there, and black bands at the top and bottom. I think former should go away, but I'm not sure about the latter. If I were you, I'd either configure the display component with 50 cycles render and invert, and set update every to 1, and then let it run overnight every few seconds (rendering some changing text to avoid extra burn in), or I'd just flash this demo and let it run overnight https://github.com/ashald/platformio-epdiy-monochrome/tree/main/examples/basic as it does something similar. I'm not an expert on eInk though. 😕

[tdroza]

@ashald I just updated to your latest component and it's working really well, including the battery component. No noticeable ghosting for me.

Really appreciate your work on this and I hope you and your family are safe and well.

[lbonherbe]

@ashald thank you very much for your hard work on this... Today when compiling the code with your component, I get this:

src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp: In member function 'void esphome::lilygo_t5_47::LilygoT547Display::flush_screen_changes()': src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp:57:58: error: 'eink_render_advanced' was not declared in this scope eink_render_advanced(fb, this->cyclesinvert, true); ^ src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp:63:55: error: 'eink_render_advanced' was not declared in this scope eink_render_advanced(fb, this->cyclesrender, false); ^ *** [/data/ed1/.pioenvs/ed1/src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp.o] Error 1

Any idea where the issue might be coming from? Previous versions seemed to work. I have HA 2022.3.2 and ESPHome 2022.2.0, compiling for wireless update.

[ashald]

@lbonherbe that means you got an outdated version of the underlying library. Did you clean build files for your Lilygo?

[lbonherbe]

Naturally this was the answer, a big think you @ashald

[Yazzcat]

@Ashald, I've tried your advise and with the suggested settings I let it run for 2 days. Unfortunately this does not take away the burn-in (not even reduces it). Im afraid this display is unrecoverable. I am actualy a bit hesitant to purchase a new one... But Im thinking about it. If I am the only one that has it, maybe something with this particular display!

[lux4rd0]

@ashald - Just getting some time to try this new version out. I've been lurking and playing around with this and my Waveshare devices... I am curious about the update to provide for a built-in battery voltage measurement for a sensor:

I'm using this configuration as represented in your previous post:

external_components:
  - source: github://ashald/esphome@lilygo-t5-47
    components:
      - lilygo_t5_47
display:
    platform: lilygo_t5_47
    full_update_every: 5 # optional (default:  1): 0 - never, 1 (default) - every, 2+ - throttled
    cycles_render: 20    # optional (default: 20): higher number -> less ghosting, crisper image, more time
    cycles_invert: 20    # optional (default: 20): higher number -> more timef or full update, but mor burn-in protection
    id: ${devicename}_display
    update_interval: 60s
sensor:
  - id: ${devicename}_battery
    name: ${devicename} Battery
    platform: lilygo_t5_47

But it's not registering a class or unit of mesurement.

[12:56:33][C][lilygo_t5_47.sensor:038]: Battery Voltage Sensor 'esp14 Battery'
[12:56:33][C][lilygo_t5_47.sensor:038]:   State Class: ''
[12:56:33][C][lilygo_t5_47.sensor:038]:   Unit of Measurement: ''
[12:56:33][C][lilygo_t5_47.sensor:038]:   Accuracy Decimals: 2
[12:56:33][C][lilygo_t5_47.sensor:039]:   Update Interval: 60.0s
[12:56:36][D][sensor:125]: 'esp14 Battery': Sending state 4.76293  with 2 decimals of accuracy

Is that something that I can overwrite in the esphome configuration? Or does that make sense to add into the module?

Thanks again for all of your assistance!

[lux4rd0]

Should have done a little more homework - I can add configurations to the sensor to push this information to Home Assistant:

sensor:
  - platform: wifi_signal
    name: '${devicename} WiFi Signal'
    id: '${devicename}_WiFi_Signal'
    update_interval: 60s
  - platform: uptime
    name: '${devicename} Uptime'
    update_interval: 60s
  - id: '${devicename}_battery_voltage'
    name: '${devicename} Battery Voltage'
    platform: lilygo_t5_47
    unit_of_measurement: V
    state_class: measurement
    device_class: voltage
    update_interval: 15s

Thanks!

[ashald]

@lux4rd0 glad you figured it out! I'll see if I can make those defaults.

@Yazzcat ugh, it's really sad that happened to your display. AFAIK, eInk displays are generally susceptible to burn-in. And the cheaper the display - the higher the risk, and AFAIk Lilygo doesn't have a particularly high-quality ones. I have an Inkplate 6 on my desk waiting for a test drive - looking forward to seeing if it'd be any better than Lilygo. That being said, I just bought a 2nd Lilygo module as I was able to make it work really well for my use-case. It receives data over BLE, and shows CO2 values on eInk. When values are abnormal as on example below, I invert the row. This both helps to highlight the value, but also helps to prevent burn-in as the values would go from normal to abnormal and back many times a day. With such a setup, I haven't seen any serious artifacts as in your case.

[jasonmhite]

For what it's worth I have also seen some burn in but mine behaves quite strangely. As long as it's plugged in there is no problem, but if you unplug it anything on the display fades and you also see some old artifacts bleed in. I suspect the display might have some kind of damage from some different code that I was running on them before that wasn't very well tuned for this display, but I don't really understand enough about them to know what's up.

[lux4rd0]

My experience is the same when unplugged and running on battery. There's a voltage difference between 4.8 when plugged in and 4.2 when on battery. But I also only see this kind of "fade in" of artifacts when the full refresh is set to anything larger than 1. So even if I have a 5 minute refresh and it's set to full refresh every 2 times - it starts developing artifacts before even the first partial refresh. If I have it set to always do a full refresh - it doesn't develop any artifacts between that 5 minute refresh interval. The full refresh regardless always gives me a clear screen.

It's weird to see stuff developing on the screen when nothing is scheduled to draw to the screen.

[Cadair]

@Plawasan Don't suppose you have any more info on the issue with the touchscreen and the battery?

@ashald Your component ended up with me having some dark spots on the display after running it for a long time (weeks), swapping to a different component cleared them, and I was going to swap back to your component but it wont compile. I get this error:

Compiling /data/esp-display/.pioenvs/esp-display/src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp.o
Compiling /data/esp-display/.pioenvs/esp-display/src/esphome/components/mdns/mdns_component.cpp.o
src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp: In member function 'void esphome::lilygo_t5_47::LilygoT547Display::flush_screen_changes()':
src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp:57:58: error: 'eink_render_advanced' was not declared in this scope
       eink_render_advanced(fb, this->cycles_invert_, true);
                                                          ^
src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp:63:55: error: 'eink_render_advanced' was not declared in this scope
   eink_render_advanced(fb, this->cycles_render_, false);
                                                       ^
*** [/data/esp-display/.pioenvs/esp-display/src/esphome/components/lilygo_t5_47/display/lilygo_t5_47_display.cpp.o] Error 1
========================== [FAILED] Took 1.48 seconds ==========================

[jasonmhite]

@Cadair clear your build files before building again and it should work.

[Cadair]

I removed the .esphome/builld directory (I use the hass addon) and I still get the error. Is there something else I should delete?

[ashald]

@Cadair are you using cli or dashboard? If using cli, try esphome clean config.yaml If dashboard - click on three dots in the corner of the card representing your device, and select "clean build files"

BTW, do you have a photo of the dark spots you mentioned?

[ashald]

P.S.: @Cadair you probably need to delete .esphome/external_components

[Cadair]

BTW, do you have a photo of the dark spots you mentioned?

Unfortunately not, I forgot to take one before I swapped component to see if they would clear. It was maybe 5mm across and a nebulous collection of pixels (some dark some not).

Removing external_components did the trick, thanks :)

[jasonmhite]

@ashald @Cadair I just noticed I had a similar dark spot appear and I thought to take a photo.

It's interesting that the blob is still visible while the screen is inverting during a refresh, those pixels appear to not change.

It's the blob above the right plot line in this pic:

[Cadair]

Mine also came back significantly worse after re-flashing:

[ashald]

@jasonmhite interestingly enough, I've got similar - albeit much smaller - blobs in two places on the screen. They showed up first few days after I just received my Lilygo - with an interval of a day or two. Just to confirm, were you running my version of the component? My blobs appeared even before I started thinking about my own component and was just running some demos to see how it works, so I don't think it's related, but still curious.

I tried contacting Lilygo support but the response was going in rounds between trying yet another demo that flashes screen white, and asking me to accept a defective product, duh. I heard multiple statements about questionable quality of Lilygo boards, so I wonder if that's what it was about. FWIW, I've got 2nd Lilygo running same code as the one on the photo and it didn't have any issues with the screen over few weeks so far.

I noticed that Lilygo is available from Amazon in US with fulfillment by Amazon - I'd suggest anyone who can order from there prefer this route, as in my experience Amazon is very reasonable with returns and exchanges for defective products that they fulfill.

@Cadair you're referring to that large black blemish at the bottom of the screen? Ugh, that really looks bad, and I'm afraid it's likely permanent.

Lastly, while I suspect we're experiencing hardware defects - I'm not an expert on eInk, so I cannot firmly state that software is not involved, unfortunately.

[Cadair]

@ashald It's not permanent, flipping back to tiaanv's component (for the many full refreshes) makes it go away:

[jasonmhite]

@ashald Yep, it was running your version of the component. Tonight I'll try and see if switching back to the other version makes the blob go away. I agree I suspect it might be a quality issue. It could also be that I was running a poorly tested (non-esphome) library on it before when I was playing with it that also caused some weird issues and perhaps damaged it. I know the driving of these displays is fairly complicated, so I could see how a bad implementation might do something to the display.

The weird fading effect I was getting after unplugging seems to have at least diminished, however.

[ashald]

@Cadair that's great news - I'm glad that wasn't permanent damage. Assuming you used the latest version of my component when that happened, it seems that it might cause some strange side-effects. :/ Unfortunately I have no clue whatsoever about what could be going on there.

@jasonmhite One thing I'd note is that you should treat my component as another poorly tested library given what we observed above. 😅 I'm sticking with it as it doesn't cause any issues on my devices, but will post a heads up if anything comes up.

BTW: did any of you tweak VCOM? I wonder if it could be at play. Trying to figure out why it doesn't manifest on all Lilygo's.

P.S.: I still experience some weird fading for about 5-10 mins after I unplug from USB and switch to battery. :/

[tdroza]

I'm not noticing any of these blobs on my device - I did tweak the VCOM when I first got it and was playing around with various different components.

Battery life is great too - I think it's 3 weeks since I charged mine (I'm using an 18650), it's sleeping for 13mins then wakes for a minute or so to receive data and refresh the screen. It's currently showing 58% battery remaining, and that includes a bunch of config changes and reflashing about 10 days ago.