Support for Waveshare Three-color E-Ink Displays #239
Comments
|
After some fiddling around, I can report that implementing color in 7.50 modules is quite hard due to memory.
I'll try to use flash memory for this. This result will also affect our ability to implement color LCD displays. |
|
@asmfreak Hmm yeah that's true. Of course the ESPHome memory usage could be optimized a bit (though most of that number probably comes from the SDK wifi system etc), but that would not solve the problem for longer. At least on ESP32s this will be a much smaller problem (I think they had like 6 times as much RAM, but don't quote me on that). So if it turns out that it can't run on ESP8266s let's just make it ESP32-only. |
|
I'd also like support for WaveShare's 3 color e-ink displays, but I'm interested in the smaller displays (1.5" 200x200). So let's not make it ESP32 only since the smaller buffer required should fit on an ESP8266. |
|
@sbussinger I've written and tested the code for 7.5in color display. I could extend it for all color displays, but I need someone to test the code. |
I have a waveshare 4.20in BWR Display and i'd like to test your code. |
you developed 3 color? If I can use 3 color I'll buy it, I wich you can share the code with esphome library. you great !!! |
OttoWinter
added
integration: waveshare_epaper
and removed
component: waveshare_epaper
labels
|
What about implementing the smaller color ones as b/w? I could test 1.54in-c |
|
Any update on this, I have hardware to test this out. |
|
Hello all! Since then Waveshare has released a flurry of epaper screens - the list is long but a lot of good ones, with partial refresh, almost instant refreshes etc. We can see the list here for example: https://www.waveshare.com/product/displays/e-paper/epaper-2/3.7inch-e-paper.htm |
|
Is there a ticket to track color support for these three-color displays? I can only find a few old references about specific displays (#892, a reference in a PR to another PR, and possibly the referenced PR itself). |
|
i will love the support of the 3 color 4.2 display! |
|
Is there a way to use the colored version without using the red color? just to make it work with b&w? |
The displays are working in b&w there is just no option yet to make use of the color. |
|
|
Same issue here. Hoping that there's a way to address this. |
|
Hello, For the colors:
|
|
#239 (comment) |
|
#239 (comment) @parats15 I got my 7.5" screen working with Is the model just wrong in my case and for mine it's not supported yet? I got this one (driven by a ESP32 driver board): |
|
Ah, I got the v1 - which is the lower version. Would you be able to provide the color support for that one as well by any chance @parats15? |
|
@TheFitzZZ Also if you have recently adding the external component, add |
|
@parats15 thanks for the swift response (and refresh hint)! The red does work, yet now I have vertical "interlacing" lines: Any chance to fix that? Also please drop me your paypal or so, that I can buy you a drink :-) |
|
Yes think I found my mistake, I updated my bio on my github page, Thank |
|
Glad it was an easy fix! :) |
|
Am I right, that other Diplays, e. g. the waveshare black/white/yellow 4.2in is not working with this solution? I tried: `
color:
But I get compilererror ` HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
|
|
Figured I'd link to my projects here if anyone is thinking about what these things can actually be used for. The WeatherBoard was mostly for wife-approval factor and the TasksBoard is right next to it. |
Hello, |
|
Anyone have a solution now for good red support on the |
It's supposed to be this way. The red requires a 20-ish second refresh by the manufacturer's spec. I think that info is upward in this thread. If it's not, you know now. If you want a faster refresh, you can use the non-tri-color ESPHome driver and it can refresh in 2s. There are some good videos on color eInk and why it is this way. My bet is that there are no red pixels but rather the pixels themselves are tricolor. The fast refresh color eInk screens have CMY pixels similar to how monitors have RGB pixels. |
|
I'm not sure these are the same things you are referring to @trip5? I understand the refresh time is longer, but the flickering is consistent between the code with AND without implementation of the red color. This seems to be more of a result of a slight mismatch of the code with the way the v3 hardware version works (the code is for v2). 7.50in-bV3: no flickering |
|
Hey @ceddimag and @Fiiti, did you make any progress with this? I have the 4.2 V2 model B as well and didn't get it to work with what was presented here so far. I was always hoping that any of the geniuses here working on e.g. the 7.5in-v2 would eventually also have some tips for us. Did you try re-implementing the changes for the 4.2 model? |
|
@tvdhorst Not sure if you're mixing up a bit here. The 7.50inv2b is in atomicmike's repo while twisterss uses 7.50in-bv2-rb - unless something has changed? Actually I can't be sure of twisterss fork since I've been using atomicmike's. His seems to have a bit of a better result than twisterss. I admit I have a V2 but I played with it a lot and the different drivers. I'm still not sure what you mean by flickering as the refresh itself does tend to flicker anyways...? It's not a bad idea to post a video link (youtube or whatever) here and get other folks to take a look and see what exactly you mean. BTW here's my 2 variations of my YAMLs for you to compare with yours. Please note the difference in model names and reset duration. About a year ago, I did fiddle with the reset duration a bit, going as low as 1ms and high as 10ms. It can't hurt the display by trying to raise the value by 1ms. But I do remember too high or too low had side-effects. In the end, you may be right. There be a code-implementation mismatch between V2 and V3. Likely timing, I'd think. Try both forks and see if one of them works for you. |
|
Here's an example video showing the "flicker" when refreshing using twisterss' fork. Once it fully refreshes it looks pretty excellent, it just takes about 22-23s to finish. Not sure if this is what's expected. |
|
That looks normal to me. Mine all do that initial reverso-black stuff too. I'm curious what other people say, too but I suspect this is normal behavior... at least in ESPHome. A search around Youtube reveals that this type of refresh: https://www.youtube.com/watch?v=_QKtgPaasXA is what Waveshare uses for their demo... Almost the same but in slow motion (about 30s, so 30-40% slower)... and with a third of the "flashes." The flashes are also responsible for that beautiful contrast (which is lacking in some of the ESPHome drivers). So, yeah it looks like the drivers that twisterss and atomicmike have added in may not be optimal but... they work, they look great and BTW atomicmike's code might be a bit closer to Waveshare and ESPHome spec than twisterss... I can't remember where I read that he kept up with some spec talk and worked a few tweaks into his code. Not sure what the difference is and can't judge it with eyes alone. Just a gut feeling. |
|
The refresh flickering is in line with the time Waveshare says a refresh should take on the three color display. It is a normal looking refresh cycle for this technology. As for the difference between atomicmike and twistterss: I have a pretty full display, so the display method takes a long time. twisterss implemented a different approach that allows for the display method taking a long time. atomicmike has an implementation really close to the original implementation. For me that experiences timeouts with the display function too long, that I do not have with twisterss. Why I think this makes a difference to me: with the original implementation, and that of atomicmike, I experience signs of the display not turning off power while idle. Regarless of the inverted pin setting. My educated guess (not proven) is that when the display method takes too long, the code to turn off power to the display isn't called. With twisterss, it is. With that I have no deterioration signs whatsoever, so I'm sure it turns off the power for me. The twisterss implementation also improved over time a display that deteriorated due to the power not turning off. So, while I think atomicmike did correctly implement power off, it does not work for me because the display method takes too long. Due to the large display, I think that it is hard to avoid that it takes a long time. That is why a stick with the twisterss one. But ymmv, and as i said, I'm not sure if my analysis is correct. |
|
Thanks for linking to those vids @wolfinabox and @trip5. That gets us on the same page about what we're actually seeing :) This is the exact behaviour that I have. With both atomicmike and twisterss forks and current release version of the 7.50inv2b implementation. I currently use the release implementation of 7.50in-bV3 with my V3 screen. See gif for how that refreshes. It's much cleaner, less flickering.
That's why I assumed that all the flickering caused on V3 screens by both 7.50inv2b and 7.50in-bv2-rb implementations, incl. forks that support red, was unexpected and caused by slight mismatch in hardware definitions. Resulting in me beleving a cleaner implementation incl red might be possible :) |
|
Well, again, I have 3 V2s and my refresh looks the same as wolfinabox's video. The faster refresh is only possible with BW because the black and white inside a pixel "flip" while the red remains floating. To get a clear red, more weirdness is required. If you want the visual version, check out Linus explaining how color can work here: https://youtu.be/aVUxxn53mBE?si=9qiIBjIE6xyNTCal&t=85 - this is almost surely how the tricolor displays work and why they take so long to work. |
|
The gif above of release implementation of 7.50in-bV3 may flicker less, but in terms of contrast it is very very pale compared to what Twisterss version gives: |
Same here! Hope 5.79in B can use with esphome. So painful using Arduino IDE for coding with HA now... |
|
The display is slowly being destroyed regardless of that inverted pin on my display. Anyone else experiencing the same issue? |
|
Yes, I had the same, look a few posts up: |
Cheers mate. I'll give this a go. Your's is with |
|
Yes, I have it set to inverted. |
|
I just found a nice-looking board: https://www.elecrow.com/crowpanel-esp32-5-79-e-paper-hmi-display-with-272-792-resolution-black-white-color-driven-by-spi-interface.html which is using SSD1683 (https://www.elecrow.com/download/product/DIS08792E/SSD1683_Datasheet.PDF) |
|
That's kind of interesting as the SSD1683 is in ESPHome for OLED Screens, is it not? You wouldn't need any external components at all if that's true. I imagine you could just draw to the screen what you need and then send the ESP into sleep mode... So, that's pretty cool. I just ordered an ESP32 Terminal CrowPanel and I've been playing with it with OpenHASP and it's fantastic. The acrylic around it makes it look wall-worthy. It already has the wife-approval factor even when I haven't finished setting it up (problem being how/where to mount it). They both seem to have an acrylic frame in common and a bit of break-out with buttons and a few GPIOs already exposed... and at a very reasonable price. It's not on their official Aliexpress store yet so it must be pretty new. |
SSD1306 is used for OLED - https://esphome.io/components/display/ssd1306.html, but didn't find anything about SSD1683, so I think those are different chips. I'm waiting for their 5.0 Display - https://www.elecrow.com/esp32-display-5-inch-hmi-display-rgb-tft-lcd-touch-screen-support-lvgl.html, but found the E-paper displays on their website and before I get one I'd like to know if ESPHome supports it. |
|
Hi Good People, Does anyone knows if this might be the right place, or is there anything related to the 3 inch tri-color e-papers maybe? Thank you in advance. |
|
To anyone with ESP8266 driver module, willing to use it with 7.5in 3-color epaper. Here is a new rendering engine, which can run on resource-constrained ESP8266. It uses dithered colors by default. Warning This rendering algorithm right now is EXTREMELY slow.
esphome:
name: epaper
friendly_name: epaper
on_boot:
then:
- wait_until:
wifi.connected:
- lambda: |-
ESP_LOGW("main", "on boot");
id(colDisp).set_ready_for_updates();
id(colDisp).update();
external_components:
- source:
path: ./components
type: local
esp8266:
board: esp12e
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: #KEY
ota:
- platform: esphome
password: #KEY
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Epaper Fallback Hotspot"
password: #PASSWORD
captive_portal:
spi:
- id: spi0
mosi_pin: GPIO13
clk_pin: GPIO14
font:
# gfonts://family[@weight]
- file: "gfonts://Roboto"
id: roboto_20
size: 30
- file: "gfonts://Material+Symbols+Outlined"
id: icons_50
size: 50
glyphs: ["\U0000e425"] # mdi-timer
image:
- file: mdi:alert-outline
id: alert
resize: 80x80
display:
- platform: epaper
id: colDisp
spi_id: spi0
dc_pin: GPIO4
cs_pin: GPIO15
reset_pin: GPIO2
busy_pin: GPIO5
lambda: |
using namespace esphome::waveshare_epaper::elements;
using namespace esphome::display;
it.fill(COLOR_OFF);
// Turn a single pixel off at [50,60]
it.elements.draw_pixel_at(50, 60, COLOR_OFF);
it.elements.append_element<LinearGradient>(Rect2D{Point2D{0,0}, Point2D{it.static_width_() ,it.static_height_()}},
Color3{0,0,0}, Color3{255,255,255}
);
it.print(
30, it.static_height_()/2+30, roboto_20, COLOR_OFF,
TextAlign::TOP_LEFT, "hello world", COLOR_ON);
it.print(30, it.static_height_()/2+70, icons_50, COLOR_ON, "\356\220\245");
it.strftime(
320, 100, roboto_20, "%Y_%m_%dT%H_%M_%S", esphome::ESPTime::from_epoch_local(1728075180));
// it.printf(
// 300, 100, roboto_20, "%lld ms", it.s);
// Draw a line from [0,0] to [100,50]
it.line(0, 0, 100, 50);
// Draw the outline of a rectangle with the top left at [5,20], a width of 30 and a height of 42
it.rectangle(5, 20, 30, 42);
// Draw the same rectangle a few pixels apart, but this time filled
it.filled_rectangle(40, 40, 30, 42);
// Circles! Let's draw one with the center at [20,40] and a radius of 10
it.circle(20, 40, 10);
// ... and the same thing filled again
it.filled_circle(20, 75, 10);
// Triangles... Let's draw the outline of a triangle from the [x,y] coordinates of its three points
// [25,5], [100,5], [80,25]
it.triangle(25, 5, 100, 5, 80, 25);
// and a filled triangle !
it.filled_triangle(115, 5, 95, 25, 125, 70);
// Regular Polygons? Let's draw a filled, pointy-topped hexagon inscribed in a circle
// centered on [170,45] with a radius of 20
it.filled_regular_polygon(170, 45, 20, EDGES_HEXAGON);
// and the outline of flat-topped octagon around it!
it.regular_polygon(170, 45, 40, EDGES_OCTAGON, VARIATION_FLAT_TOP);
// Need to rotate the polygon, or retrieve the coordinates of its vertices? Check the API!
auto black = esphome::Color{0, 0, 0, 0};
auto red = esphome::Color{255, 0, 0, 0};
auto green = esphome::Color{0, 255, 0, 0};
auto blue = esphome::Color{0, 0, 255, 0};
auto white = esphome::Color{255, 255, 255, 0};
it.filled_circle(20, 120, 15, black);
it.filled_circle(40, 120, 15, red);
it.filled_circle(60, 120, 15, green);
it.filled_circle(80, 120, 15, blue);
it.filled_circle(100, 120, 15, white);
it.image(320, 0, alert);https://github.com/asmfreak/esphome-waveshare-7.5in-epaper-dynamic-render |
Cool stuff, thank you for sharing. :) |
|
@Joshyakadamien Can you please specify (with links to waveshare site), which ESP module and epaper display do you use? |
Sure Sir, this one:
|
|
@Joshyakadamien Your module is ESP-independent (as it includes the driver IC onboard). You can use any ESP board with SPI interface (ESP8266 or ESP32). I'm not sure, but I think your device's screen buffer should fit in even in ESP8266 memory (in my case with 7.5inch screen it does not). For you, the screen buffer will consume |
Thank you for the info and explanation. Basically i tried dissect the examples given by manufacturer to create my own custom comp. |
and others
Describe the problem you have/What new integration you would like
References #77.
I've got Waveshare's 3-color e-ink display and it would be nice to have some support for them.
7.50in B-type (red-black-white)
7.50in C-type (yellow-black-white)
Please describe your use case for this integration and alternatives you've tried:
Additional context
The text was updated successfully, but these errors were encountered: