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

[jeremypoulter]

Would someone be able to give me some hints in to what this actually involves? I assume mainly just adding support for the actual e-paper display?

[DomoYop]

It seems that it dont use the same driver as the Waveshare e-paper series does... it use this one: EPDiy E-Paper Driver which support the ED047TC1 E-Ink Display.

from my (limited) comprehension, it's much closer to the Inkplate which is already supported in esphome.

here is what i found analyzing the schematics: LilyGo-EPD47.pdf

8 pin for data: IO33 -> EP_D0 IO32 -> EP_D1 IO4 -> EP_D2 IO19 -> EP_D3 IO2 -> EP_D4 IO27 -> EP_D5 IO21 -> EP_D6 IO22 -> EP_D7   and some direct control pin: IO26 -> EP_STH IO25 -> EP_CKV IO5 -> EP_CKH

connection to shift register (74HC4094) IO0 -> strobe IO23 -> data IO18 -> clock with the corresponding output : q0 -> EP_LE q7 -> EP_OE q6 -> EP_MODE q4 -> EP_STV

it's all i have :-)

[Mitchy6]

I attempted to port the Inkplate driver; Haven't been fully successful yet, Likely I goofed a timer or something, No scope at the moment so I'm flying blind in making sure the driver signalling/timing is how it should be.

Things to note: Inkplate uses the MCP23017 i2c IO extender. EPD47 uses a 74HCT4094 shift register, I modified/forked the SN74HC595 component to get it working with the reversed shift logic for the 4094 this will let you substitute the IO Call in your yaml file. the 4094 is trivial to control, May submit my fork to at least have the 4094 able to be controlled in the future.

The inkplate code has i2c enabled/forced, this is mapped to GPIO 21/22, so you'll get boot loops if you try to use it with the EPD (As GPIO 21 & 22 are used in the parallel connection for the display). You'll need to modify the component and disable the i2c call.

Inkplate has several control IO signals that aren't used on the EPD47, I've deleted these, or used them in similar functions (power enable)

That said, the sample code by vroland (https://github.com/vroland/epdiy) is a work of art, and far exceeds that of the inkplate base code by using the built in timer and I2S Parallel driver function of the ESP32. I've pivoted and I've been trying to port the base driver much like martinberlin (https://github.com/martinberlin/cale-idf/issues/27) has done for his Cale software, but Its only a past time, and I suck at C/C++ I'm assuming the Display buffer output is compatible. It's definitely doable and not far out, Someone can whip up the code pretty quick I'll continue to mess about when I can.

What should happen is the EPD driver should be ported, and made universal to consume the inkplate and all other EPDiy type boards. This should let anyone use any of the EPDiy based board/display combos (Link above in vroland's github)

[Chrismelba-Instaclustr]

Any update on this? I could have a go if you've got some work anywhere?

[Plawasan]

Just adding a +1 here for the port, would be great to have this natively supported in ESPHome

[tiaanv]

I put something together using the edp_display drivers from Lilygo. I tried using a more generic approach for all displays supported by epdiy, but got frustrated and resorted to basic support.

The display component only supports full draw, and not partials... Partial updates in general are bad news, but I might look into support at some later stage. This was NOT thoroughly tested and it might stop working at any time... your mileage may vary.

https://github.com/tiaanv/esphome-components

Enjoy.

PS. I also tried doing this in the more correct "external_components" model, but for some reason it no longer worked when I did that.... So custom_component it is.....

[Plawasan]

Great! I tried to test this, not sure where I'm going wrong. I've cloned the repo to the base of my esphome config and renamed the folder to custom_components otherwise I was getting errors even recognizing the platform

~/esphome$ git clone https://github.com/tiaanv/esphome-components.git
~/esphome$ mv esphome-components/ custom_components

I've added a very basic definition of the display into my yaml:

display:
  - platform: t547
    id: t5_display
    update_interval: 30s
    lambda: |-
      it.line(0, 0, 50, 50);

but I'm hitting this error when trying to compile it:

Compiling .pioenvs/esp-display/lib9aa/ESPAsyncWebServer-esphome/WebAuthentication.cpp.o
src/main.cpp:36:1: error: 't547' does not name a type
 t547::T547 *t5_display;
 ^
src/main.cpp: In function 'void setup()':
src/main.cpp:1608:3: error: 't5_display' was not declared in this scope
   t5_display = new t547::T547();
   ^
src/main.cpp:1608:20: error: 't547' does not name a type
   t5_display = new t547::T547();
                    ^
*** [.pioenvs/esp-display/src/main.cpp.o] Error 1
========================== [FAILED] Took 4.77 seconds ==========================

Any pointers? Thanks again for the effort, I've been using this display for a while with the code borrowed from here - https://github.com/rbaron/eink-ha but I would still prefer native ESPHome integration.

Any chance you can also post the sample yaml? Thanks!

Edit: I've added the header to my config:

esphome:
  includes:
    - custom_components/t547/t547.h

now I'm missing the driver.. I cloned the repo but being the noob I am I'm not sure where to place it for esphome to find it..

Compiling .pioenvs/esp-display/src/main.cpp.o
In file included from src/main.cpp:43:0:
src/t547.h:7:24: fatal error: epd_driver.h: No such file or directory

[tiaanv]

remove the includes statement... I got the same issue... What you are trying here is the "external_components" model... That does not work... What you need is to locate the esphome folder in your config dir in HomeAssistant... Then create the "custom_components" folder in there if you don't already have one.. then make sure to copy the T547 folder into that folder. On my system I'm accessing it via a samba share from my windows machine..

effective folder structure:

\config\esphome\custom_components\t547 with all the files in there... This method works for me... Other that that, I'm afraid I haven't spent enough time with development of custom components to know why I can't get it to work as an "external component"

[Plawasan]

I probably should have mentioned that I have ESPHome running on a completely different machine (a laptop) than Home Assistant, that's running in a docker container on my RPi, not on Hass

but.. I also have a VM with hass.io running on the laptop, I used the terminal add-on to clone the git repo to config/esphome/, renamed esphome-components to custom_components, then I got no errors in the yaml editor..

but it still won't compile:

Compiling /data/esp-display/.pioenvs/esp-display/src/esphome/core/util.cpp.o
Compiling /data/esp-display/.pioenvs/esp-display/src/main.cpp.o
src/main.cpp:34:1: error: 't547' does not name a type
 t547::T547 *t5_display;
 ^
src/main.cpp: In function 'void setup()':
src/main.cpp:354:3: error: 't5_display' was not declared in this scope
   t5_display = new t547::T547();
   ^
src/main.cpp:354:20: error: 't547' does not name a type
   t5_display = new t547::T547();
                    ^
*** [/data/esp-display/.pioenvs/esp-display/src/main.cpp.o] Error 1

[tiaanv]

I don't have enough experience in this regard. I'm sorry I can't help more... Perhaps one of the smarter people can figure it out... that sees this post.... I'm not near my dev PC, but perhaps tomorrow I will give the external components route a go again... then it should work... until then, I hope you figure something out..

[osresearch]

I was getting the same t547 does not name a type errors and determined that what was needed is an empty __init__.py in the custom_components/t547 directory. Not sure why; this was based on looking at the difference to the waveshare_epaper component.

Here is a working example:

esphome:
  name: t547demo
  platform: esp32
  board: esp32dev
  platformio_options:
    upload_speed: 1500000

wifi:
  ssid: "YOUR-SSID"
  password: "*********"

time:
  - platform: sntp
    id: ntp

font:
  - file: 'IBMPlexMono-Bold.ttf'
    id: din_big
    glyphs: "+-0123456789.:"
    size: 300
  - file: 'IBMPlexMono-Bold.ttf'
    id: din_med
    size: 100

display:
  - platform: t547
    rotation: 180
    update_interval: 60s
    lambda: |-
      it.strftime(15, 310, id(din_big), TextAlign::BASELINE_LEFT, "%H:%M", id(ntp).now());
      it.strftime(50, 500, id(din_med), TextAlign::BASELINE_LEFT, "%Y-%m-%d %a", id(ntp).now());

The redraw is full screen, which is fairly slow. Using the sample code from Lilygo I was able to do partial updates, so it should be possible to enable.

[Plawasan]

martin@EliteBook:~/esphome/custom_components/t547$ touch __init__.py

That's all it took.. now I have work to do over the weekend to create a decent dashboard but it should be pretty straightforward from here.. thanks!

[tiaanv]

The Init.py issue was because the file in my local source failed to upload to github. It skips empty files... I added a single blank space to correct that issue. I guess in theory I can now try the proper external components approach again... Will make it easier for most to implement, and it will be pulled from git automatically...

[NeroWard]

The redraw is full screen, which is fairly slow. Using the sample code from Lilygo I was able to do partial updates, so it should be possible to enable.

Share the code with which you were able to do a partial update? Sorry for my English.

[osresearch]

@NeroWard the sample code is here https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/blob/master/examples/demo/demo.ino although it is built and installed with Arduino, and the partial update functions aren't compatible (yet) with the esphome display class. It allows individual regions to be forced to white by flashing them several times, and then drawing the black pixels.

It might be possible to remove the call to epd_clear() in T457::display() https://github.com/tiaanv/esphome-components/blob/main/t547/t547.cpp#L82 and to track damage to the display buffer rather than drawing the full one, although it looks like the other epd with partial update still send the full image, but with a different LUT. The code from lilly go has a function to update the LUT with some comments that might be helpful https://github.com/tiaanv/esphome-components/blob/main/t547/epd_driver.c#L267

[Plawasan]

I took me a bit of time to fine-tune it to my liking but I'm pretty happy with the outcome:

yaml is here - https://gist.github.com/Plawasan/4ae826b05aaa7812f3a191714ca47a50 - keep in mind I'm no programmer so it may not be as clean as it could be but it works reliably.

I have yet to see how long will the battery last, right now I have it configured to refresh every 20 minutes during the day and then sleep for 6h after midnight. There is a period of time after the ESP wakes up from deep sleep (and resets the display) until new data comes from HA when the display is blank - I didn't find a way to easily disable it so I at least raised a feature request for it - https://github.com/esphome/feature-requests/issues/1555

It's obviously configured for my specific use case and entities but the yaml should be simple enough to adjust.

[vbaksa]

I'm sharing one more implementation that I developed a while ago. I'm using it for a least one month and so far haven't experienced any issues.

I'm utilizing vroland/epdiy library which supports partial screen update and display orientation.

Pretty much all ESPHome display features are supported.

Minimal usage example

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_display]

display:
  - platform: lilygo_t5_47_display
    lambda: |-
      it.line(0, 0, 100, 50);
      it.rectangle(50, 60, 30, 42);
      it.filled_rectangle(50, 60, 30, 42);
      it.filled_circle(250, 250, 100);
      it.circle(450, 450, 50);

A bit more complex usage example

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_display]

display:
  - platform: lilygo_t5_47_display
    id: mypaperscreen 
    landscape: true
    temperature: 23
    clear: false
    update_interval: 4s
    pages:
      - id: page1
        lambda: |-
          id(mypaperscreen).clear();
          it.line(0, 0, 100, 50);

[Plawasan]

lilygo_t5_47_display

Tested, works!

• 'clear: false' is exactly what I needed to keep the display from going blank when the ESP wakes up from deep sleep, that's awesome however
• the redraw "routine" seems to only fill the screen once with blank/fill and then draws the text, on my display that for some reason leaves the parts of the screen that are supposed be blank about 20% dark (after a couple secs) - this happens regardless of whether i use 'clear: false' or not. With the component provided by tiaanv this doesn't happen - it refreshes the screen about 4 times and the display then stays completely clear (I mean the parts that are supposed to be clear) even after the esp goes to deep sleep
• for some reason that I don't really understand I get nonsensical values for battery voltage when using your display component:

This is how I get the values:

  - platform: adc
    pin: GPIO36
    name: "${esp_name} Battery Voltage"
    id: batt_volt
    attenuation: 11db
    update_interval: never
    filters:
      - multiply: 2

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

and this is what I get with lilygo_t5_47_display:

[08:57:32][D][sensor:113]: 'ESP Display Battery Voltage': Sending state 0.28400 V with 2 decimals of accuracy
[08:57:32][D][sensor:113]: 'ESP Display Battery': Sending state -376.00000 % with 0 decimals of accuracy

Simply changing platform back to tiaanv's t547 gives me the correct readings again:

[08:59:59][D][sensor:113]: 'ESP Display Battery Voltage': Sending state 3.94200 V with 2 decimals of accuracy
[08:59:59][D][sensor:113]: 'ESP Display Battery': Sending state 80.00000 % with 0 decimals of accuracy

So very selfishly the ideal solution for me would be implementing the 'clear: false' option in tiaanv's version of t547 :)

[tiaanv]

I find that even with my component when I power off the display, the ink begins to "bleed" I think this has to do with the the way the display works... I have tested @vbaksa s version, and I think it works much better. The only funny thing I notice is that the update cycle takes 4 seconds, even though it/s partial, which should be very quick... Haven't looked at the code...

As far as the clear setting is concerned, I don't think it would really work well with my version, as I do a full display redraw in any event... potentially, what you can do as a workaround to "clear" the screen is to draw a full-screen rectangle on/off/on/off. basically simulating a clear...

I think it would be good to invest further development effort into his version. I will play around a bit with deep sleep and see what can be done. As far as the Voltage is concerned. I'm pretty sure somewhere in the code, the EPDY library messes with the VREF because for some displays it uses temp sensor. Perhaps that's the cause for the voltage ref. Irrespective.. should be simple to work around that also... simply use the scaling factor, until we can figure it out... Provided it's actually reading the correct pin etc...

[vbaksa]

One more update.

I added separate battery voltage measurement component "lilygo_t5_47_battery". It is based on EPDY library code. As @tiaanv mentioned before - it is messing up VREF, so keeping it as separate component.

Usage sample below:

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_battery]

sensor:
  - platform: lilygo_t5_47_battery
    update_interval: 5s
    voltage:
      name: "Battery Voltage"

[Plawasan]

Updated my config to:

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_display, lilygo_t5_47_battery]

I was getting errors about missing init.py in my local repo, had to temporarily add a refresh: 5s line to the component definition to force it to get the repo again..

I've updated my battery voltage sensor to use the platform, got this error:

/home/martin/esphome/esp-display.yaml:248:34: error: 'class esphome::lilygo_t5_47_battery::Lilygot547Battery' has no member named 'state'
       int y = (1-(4.1-id(batt_volt).state)/(4.1-3.3))*100;

When I got rid of the lines that work with the sensor I can see it returns the correct value but it seems to be missing the members that allow it to be used same as other sensors.. i think?

[15:49:34][D][sensor:113]: 'ESP Display Battery Voltage': Sending state 4.06435 V with 2 decimals of accuracy

Bleeding issue is still there...

[vbaksa]

@Plawasan - try something like below for templating battery voltage measurements

sensor:
  - platform: lilygo_t5_47_battery
    id: battery
    voltage:
      name: "Battery Voltage"
  - platform: template
    name: "${esp_name} Battery"
    id: batt
    unit_of_measurement: "%"
    accuracy_decimals: 0
    device_class: battery
    lambda: |-
      int y = (1-(4.1-id(battery).voltage->state)/(4.1-3.3))*100;
      if (y < 100) {return y;} else {return 100;};

[Plawasan]

@vbaksa - OK, that worked (after I remembered to refresh the repo again...).. thanks!

So really the only issue I see now is the display bleeding, I created 2 additional pages, one blank, one all black and I have the display cycle through them before displaying the main page - the bleeding still occurs. I don't think this is the issue, even without this the display always starts perfectly clear after the update and then it fades. I can't figure out whether it happens when the ESP goes to deep sleep but it seems to me it has something to do with power, it's never an issue when I have the display connected via USB, it only happens when it's running on battery power (even 100% charged)

btw I wanted to return my display back to the previous config (- platform: t547) but keep using your component for the battery, now I'm getting a ton of errors of duplicate definitions - is that solvable?

[vbaksa]

Few more updates:

• Updated init order, so display is initialized much earlier. Should fix delay on startup.
• Fixed shutdown hook and added epd_deinit() function call. This should ensure display shutdown before deep sleep.

@Plawasan - regarding display "bleeding" issue you are getting. Is it the same as vroland/epdiy#92

[Plawasan]

Few more updates:

• Updated init order, so display is initialized much earlier. Should fix delay on startup.
• Fixed shutdown hook and added epd_deinit() function call. This should ensure display shutdown before deep sleep.

@Plawasan - regarding display "bleeding" issue you are getting. Is it the same as vroland/epdiy#92

Yep, sounds like exactly the same issue... I never had that problem using @tiaanv 's driver..

[geekuillaume]

I also have the same issue of display "bleeding", not a lot when running with USB-C but more pronounced when using a battery. Everything else seems to run fine.

I tried using the new ESP-IDF mode in my configuration but got a problem related to a header from epdiy not being found. I couldn't understand why.

Here's a preview of my setup:

[NeilS1966]

I have the touch panel for this display. What would be required to implement touch into this build? It would be pretty awesome to be able to place a few ON/OFF buttons.

[kaweksl]

Screen bleeding is caused by switching screen off to early. This board is designed in a way that if there is USB power then screen has power all the time ( indicated by blue led) but on battery, power to screen is controlled by driver.

Simply delay must be added before epd_poweroff, or maybe there is way to ask if refresh is completed

[vbaksa]

Screen bleeding is caused by switching screen off to early. This board is designed in a way that if there is USB power then screen has power all the time ( indicated by blue led) but on battery, power to screen is controlled by driver.

Simply delay must be added before epd_poweroff, or maybe there is way to ask if refresh is completed

@kaweksl - thanks for the info. A delay can be added quite easily. However, the question is - how long it should be delayed before calling epd_poweroff ?

[kaweksl]

somewhere i saw that it takes 613ms to do full refresh. so maybe try 700ms

EDIT: now i know where is saw that and its ~630ms, https://youtu.be/19g5nORIjxA?t=14

[vbaksa]

Thanks @kaweksl . I updated the code with a new option 'power_off_delay_enabled'. When enabled it delays epd_poweroff by 700ms.

Tester wanted :) !

To test it, set option 'power_off_delay_enabled: true'. Something like following:

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_display,lilygo_t5_47_battery]
    refresh: 1s
display:
  - platform: lilygo_t5_47_display
    power_off_delay_enabled: true
    lambda: |-
      it.line(0, 0, 100, 50);
      it.rectangle(50, 60, 30, 42);
      it.filled_rectangle(50, 60, 30, 42);
      it.filled_circle(250, 250, 100);
      it.circle(450, 450, 50);

On top of that there few other minor improvements:

• Screen clearing runs together with update(). This should fix delay problem reported before.
• Component is initialized lately, so you should get initial update together with data in most cases.

btw, if you want to trigger "epd_clear()" manually, then please use id(displayid).clear() instead of it.clear(). The reason behind it - it seems that so far it's not possible to override ESPHome "it.clear()" function, or at least I didn't found a way to do this.

[kaweksl]

Gonna test

However I have noticed when board is on battery and power to screen is enabled (blue led is on) it draws ~110mA@3.6V , but when power to screen is off board draws ~260mA , so something is not right. In both cases screen is not refreshing , for test I modified code so power to screen is always enabled . Tested with power profiler kit II I have looked at schematic but didn't found anything obvious. Anyone know what can draw that ~150mA ?

[Plawasan]

Ran a couple tests with my display:

• Issue is unfortunately still there (but see edit below)
• I even added a 15s delay between the component update and entering deep sleep, the fading still occurs at the point of entering deep sleep (although I'd say there's a barely noticeable drop in contrast starting immediately after the redraw but don't quote me on that, it may be just my eyes looking for problems)
• It happens to a random extent, I let the cycle run 10+ times with 20s of deep sleep, sometimes it's barely there, sometimes the fading is very pronounced:

EDIT: I've had this config running for a couple hours now on a 20 minute interval and I haven't really noticed a "bad" redraw.. It's still not as 100% clear as the previous setup but it's better, to the point where I prefer this setup due to the quicker redraw and no update on initialization that left me with a blank screen for up to a minute..

One thing I noticed as well but I assume this has to do with wireless logging more than battery power (unfortunately I cannot do one without the other)

Deep Sleep on battery (with wireless logging) - I don't get the "Shutting down screen" message but again, I think it's because the wifi has shut down by then rather than the action not happening on the device..

[08:23:38][I][deep_sleep:072]: Beginning Deep Sleep
[08:23:38][D][esp32.preferences:114]: Saving preferences to flash...
INFO Disconnected from ESPHome API for 192.168.1.107
WARNING Disconnected from API

Deep Sleep on USB power (and USB console)

[08:24:50][I][deep_sleep:072]: Beginning Deep Sleep
[08:24:50][D][esp32.preferences:114]: Saving preferences to flash...
[08:24:50][I][lilygo_t5_47_display:066]: Shutting down Lilygo T5-4.7 screen

@kaweksl - I haven't measured it directly but I've been running my display for days on a 103450 battery, I'm pretty sure that with 260mA phantom draw in deep sleep it would have killed the battery in a day.. or is that something you're seeing when the ESP is still running but not refreshing the display?

[kaweksl]

@Plawasan -

or is that something you're seeing when the ESP is still running but not refreshing the display?

Yes, In deep sleep (on battery) my board takes ~230uA , problem is when screen have been initialized and not refreshing (after epd_poweroff) but esp32 is still running (not in deep sleep ), then it takes ~235mA . This is because ESP32 is keeping some screen control pins high when screen don't have power and current flows from esp32 pin thorough screens chip clamping diodes to disabled 3V3 rail .

It is ~100mA load on esp32 pins, that may damage screen or esp32. So better not to use battery, for now. I have opened issue on epdiy driver.

Also did you calibrate VCOM ? My board required that. partial refreshes are mostly affected by wrong VCOM from epdiy wiki "The existing image fades / darkens when updating a partial screen region. Make sure the VCOM voltage is calibrated for your specific display." https://epdiy.readthedocs.io/en/latest/getting_started.html#calibrate-vcom

Lilygo also have potentiometer around opamp, "The VCOM value is usually between -1V and -3V." , During calibration, board should be powered via USB

[Plawasan]

I checked my board, VCOM was at -0.6V, I've adjusted it to -1.16V (as far CW as the trimmer would go) and initially it looks good - I'll keep an eye on it, thanks for the heads-up.

Btw same question as was already raised - I'm about to buy a second one of these for a similar usecase as @geekuillaume i.e. always on power, should I throw in the touch panel as well? I'm not sure if that's supported by ESPHome..

Also the version you can buy now is "9102 chip" as opposed to the "2104" version I have now - does that make any difference to ESPHome?

[kaweksl]

@vbaksa - I have tested new changes and seems like they messed up screen rotaion in display.py i noticed line 50 cg.add(var.set_landscape(config[CONF_POWER_OFF_DELAY_ENABLED])) probably shouldn't be "set_landscape", after commenting this and removing pycache screen rotation is back. Also that means power_off_delay setting may not work

@Plawasan I think touch screen is not supported by now, but may become handy in future . I read that CH9102F is not working on Mac and have resolvable issues on Ubuntu

EDIT: Also take a look at EPDIY project, there are inexpensive (~16$) e-ink screens on ali

[vbaksa]

@vbaksa - I have tested new changes and seems like they messed up screen rotaion in display.py i noticed line 50 cg.add(var.set_landscape(config[CONF_POWER_OFF_DELAY_ENABLED]))

Good catch! Thanks @kaweksl ! Screen rotation and power off delay configuration should be fixed now.

[Plawasan]

@kaweksl - from what I can tell they claim compatibility with CP2014, I run ESPHome on Ubuntu so I'll give it a shot, hopefully I won't end up with a paperweight.

Sorry for a quick off-topic - As for the alternative displays, I've looked into those, I do like some of the options, now I just need to do a bit of research on the actual HW needed to make it work with ESPHome (I hoped this https://www.aliexpress.com/item/32965291143.html would be able to drive this https://www.aliexpress.com/item/1005002789845584.html but from what I can tell the physical connection is different 24 vs. 34 pin..).. will keep digging.

[Plawasan]

@vbaksa - I have tested new changes and seems like they messed up screen rotaion in display.py i noticed line 50 cg.add(var.set_landscape(config[CONF_POWER_OFF_DELAY_ENABLED]))

Good catch! Thanks @kaweksl ! Screen rotation and power off delay configuration should be fixed now.

Have it running now with the fix, so far it looks great - will keep watching it.

EDIT: 24h later, all looks good, haven't really noticed any fading

[ashald]

Trying it out and works pretty good so far as well.I I just noticed that lilygo_t5_47_display defines full_update_every parameter https://github.com/vbaksa/esphome/blob/dev/esphome/components/lilygo_t5_47_display/display.py#L25 but it doesn't seem to be respected. Is that intentional?

[Plawasan]

Good news everyone! Looks like the touchscreen for this display is getting native ESPHome support from Jesse himself:

https://www.reddit.com/r/Esphome/comments/s8utze/comment/htk6v7x/?utm_source=share&utm_medium=web2x&context=3

Time to go shopping...

[Plawasan]

@Plawasan Very nice configuration, but how do you create the sensor.power_meter_battery_life_remaining ? It looks like you have a script or some code in the HomeAssistant that generates this value.

You can ignore that one, it was meant for a battery pack that powered another esp, not for the display itself..

My latest config is here, i changed a couple things around to clean it up a bit.

https://gist.github.com/Plawasan/f4fdc1480534ca4a50bcfbdf495b9448

[jesserockz]

Touchscreen support: https://github.com/esphome/esphome/pull/3084 Untested as I am waiting for it to arrive still but decided the code didnt look too hard to write. Then i decided to rewrite other code at the same time...haha

[ashald]

@vbaksa I just cleaned build files for my node and when I tried to rebuild it I got this error:

In file included from src/esphome/components/lilygo_t5_47_display/LilygoT547Display.h:9:0,
                 from src/esphome.h:16,
                 from src/main.cpp:3:
/data/lilygo-test/.piolibdeps/lilygo-test/epdiy/src/epd_driver/include/epd_highlevel.h:81:3: error: conflicting declaration 'typedef struct EpdiyHighlevelState EpdiyHighlevelState'
 } EpdiyHighlevelState;
   ^
In file included from src/esphome/components/lilygo_t5_47_battery/Lilygot547Battery.h:10:0,
                 from src/esphome.h:15,
                 from src/main.cpp:3:
/data/lilygo-test/.piolibdeps/lilygo-test/epdiy/src/epd_driver/include/epd_highlevel.h:81:3: note: previous declaration as 'typedef struct EpdiyHighlevelState EpdiyHighlevelState'
 } EpdiyHighlevelState;
   ^

Do you have an idea what might be wrong here? I looked at namespaces and it just doesn't make sense to me. 😭

[Plawasan]

@ashald - hit the same issue yesterday , I ended up just commenting out the epd_highlevel include in the battery component to get it to compile but I'm glad to see it's not just on my end..

Not sure what changed though, I checked @vbaksa 's repo and I didn't see any commits in there recently.. So more likely something on ESPHome side but I'm a complete noob when it comes to C/C++

[ashald]

@Plawasan thanks for confirmation, and glad we have a workaround - I thought about doing that but wasn't sure it it'd break the battery sensor.

[ashald]

P.S.: I just noticed that that the battery sensor makes a call to epd_poweron(), waits for 100ms, and then epd_poweroff(). While it's not a lot, we still seem to waste some battery power here. And we seem to be doing similar while updating the display anyway, so I wonder if there is a way we can make the display component "export" the value somewhere from where we can simply read it later? Maybe it can accept a sensor id for which it would push state, or a lambda that would get the battery voltage value so that you can do whatever you want with it, if you need.

[kaweksl]

@ashald that needs to be done since battery measurement is behind mosfet with is controlled by epd_power*() functions. As for errors above, maybe underlying epdiy library had some changes

[Cadair]

Using @vbaksa 's component I get serious bleeding and weirdness on USB power.

this is with:

external_components:
  - source:
      type: git
      url: https://github.com/vbaksa/esphome
      ref: dev
    components: [lilygo_t5_47_display]
    refresh: 5s

and

  - platform: lilygo_t5_47_display
    power_off_delay_enabled: true  
    clear: false
    id: t5_display
    rotation: 90
    update_interval: 1min

Does anyone have any suggestions about what's going on?

[vbaksa]

  - platform: lilygo_t5_47_display
    power_off_delay_enabled: true  
    clear: false
    id: t5_display
    rotation: 90
    update_interval: 1min

Does anyone have any suggestions about what's going on?

@Cadair - I suspect that you might have artifacts accumulation happening. From time to time full update needs to happen, because artifacts accumulate. There are few strategies to handle it:

• You can clear screen by calling lambda function id(screenid).clear();.
• In deep sleep scenario, typical approach is to set clear: true, so then screen gets cleared on startup.