Add support for Lilygo T5-4.7 inch e-paper module
lbonherbe opened this issue · comments
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
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?
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 :-)
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 (martinberlin/cale-idf#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)
Any update on this? I could have a go if you've got some work anywhere?
Just adding a +1 here for the port, would be great to have this natively supported in ESPHome
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.....
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
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"
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
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..
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.
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!
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...
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.
@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
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 - #1555
It's obviously configured for my specific use case and entities but the yaml should be simple enough to adjust.
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);
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 :)
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...
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"
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...
@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;};
@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?
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
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..
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:
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.
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
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 ?
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
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.
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 ?
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?
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
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?
@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
@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.
@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
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?
Good news everyone! Looks like the touchscreen for this display is getting native ESPHome support from Jesse himself:
Time to go shopping...
@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
Touchscreen support: esphome/esphome#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
@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. 😭
@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++
@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.
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.
@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
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?
- platform: lilygo_t5_47_display power_off_delay_enabled: true clear: false id: t5_display rotation: 90 update_interval: 1minDoes 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.
Do you have an idea what might be wrong here? I looked at namespaces and it just doesn't make sense to me. 😭
@ashald - it seems that something has changed on esphome or epdiy side. Didn't managed to find what has changed yet.
@vbaksa thanks, I will give that a go. Is there a way to configure your component to do a full refresh every time?
Good day everyone. I have a wierd issue that I can not solve by myself: The ePaper display works flawlessly on USB-power but when connecting a 18650 battery (with or without having USB connected) the display clears upon boot but stays blank. I have verified that the ESP is powered on: log is displayed in ESPhome and also the three buttons register in Home Assistant. Any ideas?
@vbaksa thanks, I will give that a go. Is there a way to configure your component to do a full refresh every time?
@Cadair - it's possible by calling id(screenid).clear(); function.
Something like below:
display:
- platform: lilygo_t5_47_display
id: mypaperscreen
lambda: |-
id(mypaperscreen).clear();
it.circle(450, 450, 50);
Good day everyone. I have a wierd issue that I can not solve by myself: The ePaper display works flawlessly on USB-power but when connecting a 18650 battery (with or without having USB connected) the display clears upon boot but stays blank. I have verified that the ESP is powered on: log is displayed in ESPhome and also the three buttons register in Home Assistant. Any ideas?
Would you mind sharing yaml?
Would you mind sharing yaml?
I can do that, but I suspect it is a hardware issue as I just flashed an Arduino demo program (written and compiled in Visual Studio Code) and I have the same issue: draws the screen just fine on USB-power but on battery power the screen gets cleared but never re-drawn.
EDIT: Update: it seems that the battery did not make correct contact with the terminals passing only enough current to drive the ESP but not the display. After bending the terminals and ensuring the connection the display works flawlessly on battery power.
A little update on the fading after update - with changes @kaweksl mentions here vroland/epdiy#136, I do not see any fading even without a sleep. Which is a good news for those of us who looks to make a battery powered setup based on LilyGo.
The only caveat - interestingly enough - is that there is severe fading after I just unplug it from laptop after flashing (I would imagine it's not an issue if using OTA, but I have Wi-Fi disabled for power saving, and use BLE for data transmission). So I unplug the battery for few minutes, and then once I reconnect it later, it looks perfect and clear and no fading whatsoever.
I wish @vroland would incorporate @kaweksl's changes into the epdiy lib.
with changes @kaweksl mentions here vroland/epdiy#136
Can I ask: Is this only a fix for the screen fading or does this also decrease the power usage of the device? I can run the display for around a week with deep sleep enabled and refreshes around every 5 minutes - which is already impressive. But it would be really great to have it running even longer.
@Schnabulation according to @kaweksl, it helps with power consumption as well. I only got my PPK2 today and plan to setup it in the evening, so should be able to see if I can reproduce his findings on my setup.
@Schnabulation speaking of power consumption, IDK what's your setup, but there is a lot at play. I'm actually aiming at setting up a battery-powered eInk device, which I can use to show arbitrary data around home, and which could last at least a month on a single charge while refreshing every minute. I just finished some significant optimizations yesterday and will share my configs later this week, once I measure power consumptions, but here is the summary of my observations so far:
- When ESP doesn't sleep, it consumes [relatively] a lot of energy
- The key to long battery life is to minimize runtime between sleeps
- Any unnecessary waiting wastes energy (that's to my post above on fighting waiting for 700ms, also waiting in the battery component)
- eInk refresh takes [relatively] long, but I was able to bring it down to ~850ms by forking @vbaksa's component, and also using a custom waveform provided by @martinberlin in vroland/epdiy#146
- Wi-Fi consumes a lot of energy, and takes long time [to connect before it can transmit data] - I first switched to BLE client connection, and the to BLE advertisement
So far my journey was following:
- Wi-Fi based setup as described by @Plawasan - min 12s runtime, 20-30s on average (mostly Wi-Fi connection not working on 1st attempt, a delay before connecting to HomeAssistant API)
- BLE Server (wifwucite/esphome-ble-controller by @wifwucite) + Client (myhomeiot/esphome-components by @myhomeiot) based setup - min 4s runtime, 4-5s on average
- BLE Advertisement based setup - min 2.5s runtime, 3s on average
So where I'm going with all of this? @kaweksl's fix is so much valuable because it allows us to skip 700ms sleep before epd_deinit() and going to deep sleep. Yes, it's a huge difference if eInk consumes 100mAh or 200mAh for 700ms, but if it's just ~5ms (or whatever it takes to run deinit and drop into sleep), it's much less noticeable, and there are lots of other factors at play that make much bigger difference.
with changes @kaweksl mentions here vroland/epdiy#136
Can I ask: Is this only a fix for the screen fading or does this also decrease the power usage of the device? I can run the display for around a week with deep sleep enabled and refreshes around every 5 minutes - which is already impressive. But it would be really great to have it running even longer.
All depends how fast your esp32 goes to sleep after display initialization and drawing. Also in my opinion running on battery without fix may damage screen .
@Schnabulation, answering your question above:
Can I ask: Is this only a fix for the screen fading or does this also decrease the power usage of the device?
Now as I measured things with PPK2, I can confirm that it decreases power usage, indeed. That being said, if you immediately go into the deep sleep after screen update, then the power saving is less noticeable.
I've got Lilygo receiving data over BLE on wakeup, refreshing the screen, and going back to sleep. Here is the difference I see.
With the fix:
Without the fix:
As you can see, the diff is only about 20 mC per cycle, which yields about 6% in my case
And for the background, there is a bit more detail about the energy leak.
vroland/epdiy#136 (comment)
I got my touchscreen, I'm working on cleaning up the yaml now but it works in principle, only a couple issues
- y axis coordinates are flipped between the touchscreen and the draw/print functions
- I can't get it to work on battery - if anyone else has it, can you please test that on your end? My display won't even boot with the touchscreen connected when on (a fully charged) battery, it has to be connected to USB .. and then if you disconnect it, it stops sending coordinates.
It's not a showstopper for me as the use case I have for the touchscreen anyway requires it to be always on but it's still unfortunate..
Good news is that I got the whole "chain" working, i.e. ESPHome registers a touch in a given area, sends an event to HA, HA automation triggers and toggles a light and all that without any perceivable delay, for a zigbee light it's (almost..) as immediate as pushing a wall switch..
Proof of concept - https://youtu.be/r9HC_PaG8AA
Bad news is that the 3d printed cases that exist now for the display won't fit the touchscreen, it adds about 1mm of height and at least 2mm on each side.
@Plawasan I have a class for the L58 touch from Lilygo:
https://github.com/martinberlin/FT6X36-IDF Albeit if you need to support "software rotation" you need to do that on your end. The class just limits itself to deliver the events and coordinates. I made a PR request to LVGL to add this as a driver but it won't ever be merged because of a License incompatibility.
@kaweksl I noticed a strange behavior on my Lilygo T5-4.7. The image is crisp and doesn't fade in general, except for one case. When I plug it via USB, it' and the disconnect - if it's powered by battery - or if I plug in battery immediately - there is a sever fading just seconds after epd_poweroff()/deinit(). But if I wait for about 5 mins after it was plugged via USB, and power if from battery - it works like a charm.
Since you found an issue with energy consumption previously, and even came up with a workaround - do you have an idea what might be wrong here? Thanks!
@Cadair , I am having the same issues as you, did you figure something out? I tried id(screenid).clear(); but that ended up making the background a darker grey.
After many hours playing with the Lilygo EPD47 it also has this when disconnected from power. This does not happen with EPDiy based PCBs so sadly should be a hardware error in their side. There is nothing you can do about it if the power lines do this kind of effect. IMHO not solvable with software.
Hello.
Strange battery level, is not it?
Sensors are the same https://github.com/esphome/feature-requests/issues/1109#issuecomment-1003735817
And it keeps working now.
Привет.
Странный уровень заряда батареи, не правда ли?
Сенсоры те же https://github.com/esphome/feature-requests/issues/1109#issuecomment-1003735817
И теперь он продолжает работать.
How did you add Russian language support?
@Itzamna44 - it's completely arbitrary, there's a lower voltage limit in the % calculation set to 3.1 now, that's why you get a negative % when the voltage drops below that. I honestly have no idea what it should be set to or whether the board has any battery protection, I let it drop to 2.9 and then I figured I'd rather recharge it.. not sure how low it can go before it either stops powering up the ESP or the battery dies..
Btw I'm not sure if anything has changed but I've had the board running on battery for a week now and it hasn't even dropped below 4.05V.. curious how long it will actually last.
@NeroWard - just swap the font for one with Cyrillic characters.
How did you add Russian language support?
@NeroWard
Just add Russian characters to glyphs:
@swissjon I have been using tiaanv's component, it does a full refresh but I have no bleeding issues etc.
Thanks, I was using the vbaksa/esphome component, I/m giving tiaanv a try now.
Looks like touch screen support is in ESPHome 2022.2!!!
Underlying library, epdiy, has beed recently updated to address issue with increased power consumption. Some say it also helped with "bleeding".
@Cadair , @swissjon can you post your yaml and describe this bleeding i more detail. I'm trying to reproduce that issue and i can't . Did you tried to adjust VCOM ? #1109 (comment)
I also added PR to vbaksa/esphome that adds full refresh every n partial refresh.
hey @kaweksl
I adjusted my VCOM up to ~1.1 V as high as it would go, it was down about 0.6 V when I started.
I tested vbaksa's component with and without the explicit clear command, and compared them to tiaanv's component. You can see the results here: https://imgur.com/a/c5XDVKR
vbaksa's component with the explicit call to clear, is good, but has very slightly more aliasing than tiaanv's. Without the clear the aliasing and bleeding is very prominent.
My config for vbaksa's without the clear is here: https://gist.github.com/Cadair/7db53154a8d353eb304bcc515a9273bb
Thanks to everyone for their work on this, please let me know if I can give you any more information to help out!
@Cadair tiaanv version is making full refresh every each update, something like vbaksa with a call to id(screenid).clear(); at the start of each lambda (with different waveform) .
For You fading occurs on partial screen updates. i have tried yours yaml (not exact) and i don't have so extreme fading.
This is not a fix for fading but until vbaksa merge my PR vbaksa/esphome#9 you can try this
external_components:
- source:
type: git
url: https://github.com/kaweksl/esphome
ref: dev
components: [lilygo_t5_47_display]
this adds full_update_every: x, by default is set to 10. 0 will disable it, setting to 1 will make it so each update will be full.
example:
display:
- platform: lilygo_t5_47_display
id: mydisplay
rotation: 180
update_interval: never
clear: false
full_update_every: 1
power_off_delay_enabled: false
With yours yaml i have found that on battery, screen background is becoming grey after epd_poweron/off cycle if there are no changes on screen.
I have no idea why is that but as workaround i have added digital clock with seconds, so there is always something to change on screen, and background graying is not occurring anymore.
So lilygo_t5_47_battery may also cause background graying as it is performing poweron/off without screen update
@kaweksl in my experience it doesn't depend on the yaml - I was able to reproduce it with minimal example with EPDiy library directly. If I disconnect Lilygo from USB power while the battery is attached (or attach it within a minute or so), I'd see some ghosting appearing on previously blank areas of the screen. Once screen is updated, it will go away, but then come back in few seconds. It seems like it gets back to normal within couple of minutes. I can try capturing a video.
I was just wondering if you think there might be some current leaking or what not at play, such that higher-voltage power supply via USB would skew the voltage in the system and there will be this glitch until it the voltage reduces back to normal. Not sure if this makes sense.
It seams like this happens when there is poweron/off cycle without any pixel being updated (and on battery). At least that way i can reproduce that. I gonna look more into that.
For now make sure there is always something to refresh on screen (for example a clock), and don't use lilygo_t5_47_battery
@ashald , @Cadair , epdiy library has been updated and probably fixed that issue, try it now, make sure you have newest epdiy
vroland/epdiy#158
@Cadair , @swissjon can you post your yaml and describe this bleeding i more detail. I'm trying to reproduce that issue and i can't . Did you tried to adjust VCOM ? #1109 (comment)
I had this:
external_components:
- source:
type: git
url: https://github.com/vbaksa/esphome
ref: dev
components:
- lilygo_t5_47_battery
- lilygo_t5_47_display
- platform: lilygo_t5_47_display
id: t5_display
rotation: 180
update_interval: 60s
full_update_every: 5
60 sec refresh because I was still designing the lambda. I hadn't tried changing the VCOM yet. Today I just changed it to 1.19, it was at ~0.3 ish before I think. What would be the ideal value?
I still have some of text that seems burnt into the screen. It might be fading slowly, time will tell.
I got inspired @Plawasan and all the work I saw in this thread and decided to build an info display based on Lilygo T5-4.7 which could run on battery for prolonged periods of time. This means optimizing for update speed and energy consumption, which is not aligned with the default mode of operation of EPDiy library's high-level API that @vbaksa's component uses.
With lots of help from @vroland and @martinberlin I hacked together https://github.com/ashald/platformio-epdiy-monochrome, which is a wrapper around EPDiy's low-level APIs. As I target performance, I sacrificed support for grayscale and focused on monochrome images, which resulted into significantly improved performance.
I've been running on it for few days by now and totally happy with it so far! If monochrome mode works for you - you can give it a try with:
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 # 0 - never, 1 (default) - every, 2+ - throttled
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.
I'm working on a dedicated component for the battery sensor, but for now I integrated the measurement function into the display so that it's easier to access it.
The best way to use it as of now is like show below:
display:
platform: lilygo_t5_47
id: eink
lambda: |-
// Some constants for convenience
#define BATTERY_MAX 4.2
#define BATTERY_MIN 2.9
// We know we will turn on the display soon to refresh it because we're already within its lambda
// so we're just turning it on a bit earlier
id(eink).power_on();
// We need to let the ADC to stabilize for few ms - lets draw something in the meantime
it.line(0, 0, 50, 50);
// Now we're ready to read the battery
double_t battery_voltage = id(eink).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;
// And we can immediately print it
id(eink).printf(..., "%.2fV %3d%%", battery_voltage, battery_percentage);
// Now we can do something else if needed.
// Once lambda completes, the display component will render the image and turn off the power.
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).
I mentioned this to @kaweksl previously, and updating to the latest EPDiy didn't help either. I recorded a video demonstrating the issue. I disconnect it there around 15s, and you can see how imagine is clear before that, or how it gets back to normal couple minutes later. I reproduced it with a basic example as seen in https://github.com/ashald/platformio-epdiy-monochrome/tree/main/examples/basic, so that we can take out of the picture rest of the YAML and the battery component shared here previously - cc @kaweksl as you were asking for a reproduction.
@ashald With your component i always have grey background, looks like every secend line is grey
https://imgur.com/a/f3bueyM
It is like that on battery or USB, with full_update_every: 1 or 10
EDIT: Sadly esphome is not very well suited for battery projects.
@kaweksl hm, that's really interesting - especially given that the lines are across the shorter dimension. Can you try full_update_every: 0 to see how it behaves on partial updates, or try id(eink).fill(COLOR_ON) to see if it could flush the entire screen black?
As far as I know, @martinberlin tried the code behind the component, and I didn't see such behavior on his board https://twitter.com/martinfasani/status/1494699220879687681, so I'm curious why your board behaves like that. Would be interesting to see if @Plawasan or somebody else tell whether they see the same issue. 🤔
EDIT: Sadly esphome is not very well suited for battery projects.
Would be curious to hear more details - in my experiments, I didn't see notable difference in terms of power consumption between my project when I compile it with Arduino or PlatformIO, or if I build it on top of ESPHome. If anything, it's ESP32s seem to be quite power hungry [compared to something like nrf52840], but that's a different story.
I sacrificed support for grayscale and focused on monochrome images
@ashald Maybe I missed something, but what is the difference?
@jesserockz I guess you're not referring to difference between black & white image versus 16 shades of grey, but rather in terms of how it works? I'm not super deep about eInk technology, but what I saw in EPDiy library is that grayscale images are rendered with the help of specific waveforms, and also depend on the temperature of the environment. At the same time, I found a piece of code in EPDiy which flushes the entire screen with a single color (black or white), and adjusted it so that it renders a bitmap buffer rather than a solid color.
The code that drives grayscale image rendering uses 4 bits per pixel, and then somehow uses waveforms to translate a particular shade into a set of pulses required to achieve desired color on the given pixel. This means that it requires more memory to store the buffer (and therefore needs SPIRAM). With monochrome mode I pack 8 pixels per byte so it fits into SRAM, which seem to be faster, and plus we don't incur extra ~800ms at startup for SPIRAM memtest which couldn't be disabled (until this option was added last month in Arduino and is not widely available yet).
Unfortunately, I lack domain knowledge required to go into more detail about how grayscale rendering works based on waveforms.
@ashald Ah, so by monochrome, you actually mean black & white.
"Monochrome" can still have grey in between, so in the case of ESPHome displays, I believe that "monochrome" is the same as "greyscale"
@jesserockz ah, I see, sorry for confusion - I guess I need to learn relevant terminology. 😅 Will be sticking with black&white going forward to avoid confusion.
@ashald I have just converted from vbaksa to your component - and since then I also have these lines that @kaweksl is refering to. Looking exactly the same as in the picture he posted.
I have tried with full_update_every: 0 and 1, no change.
Have to say though: the refreshing process is fast as f*** boiii...
I tried this and at least in my Lilygo I cannot see the gray lines. Or they are so subtle that they do not make any difference for me. But I can't also see it in the imgur posted image, maybe a good photo with a magnifying glass can show something more.
Open the imgur page again and scroll down to the second and third picture - I actually uploaded a picture with a magnifying glass.
If you take a close look you will see that every other line is darker. But if you step back you won't see it, that's true.
Ah now I see, though was only one image!
I can confirm this does not happen to me with the standalone epdiy balck&white version that @ashald did. I even went further and added GFX functions to test it in this repository.
Never used ESP-Home though, so maybe there are some timings affected, or there is a problem in the way the component is receiving the pixels. You might also try my demo and see for yourself if you get also this lines, but I don't see them at all.
Ah so if I understand you correctly: Using @ashalds library standalone (not through ESPHome but programmed from scratch) you don't get the lines. Interesting... Then it has to be something in ESPHome...
make sure you have newest epdiy
@kaweksl How do I do this, is it automatically pulled in with the custom component or do I have to reconfigure something?
@Cadair simplest method is to delete ".esphome" folder from where you have esphome configuration yaml . at least on linux
@kaweksl Thanks, I have done that, and on a non-full refresh am still getting significant fading on partial refresh :(
@tdroza @kaweksl @Schnabulation could you try this PlatformIO example to see if it'll give you the same result? https://github.com/ashald/platformio-epdiy-monochrome/tree/main/examples/basic
If you need, I can provide more detailed instructions for your operating system, or the binary file you could flash with ESP esphome-flasher.
Also, could you share the section of your YAMLs where you configure the display? I don't need to see your lambdas if that of any concern, but only the settings you set on the display component.
If there is something wrong with my code, I'd love to fix it so it can be used by more people, but that's hard to do unless I can reproduce it. So I'm trying to narrow down source of the issue.
The only thing I have in mind so far is that there could be something wrong with the memory (huh), so whenever I have a moment, I will add an option to the component to prefer dynamic memory allocation, or PSRAM so we can see if that will make any difference.