Waveshare 7.5in V2 e-paper dim and grainy when using lines or rectangles

[TheStork239]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Hass.io

ESP (ESP32/ESP8266, Board/Sonoff):

ESP32 Waveshare Driver Board

ESPHome version (latest production, beta, dev branch)

1.19.4

Affected component:

Waveshare e-paper display https://esphome.io/components/display/waveshare_epaper.html

Description of problem:

All items on a Waveshare 7.5in V2 e-paper display (black & white) go dim and grainy if the items to be displayed include horizontal lines, rectangles or filled rectangles. The wider the line or rectangle, the more marked the effect is. Other shapes or text do not cause the issue.

Below is example code that has the issue. If I comment out the "it.filled_rectangle" lines in the code, then the text on screen becomes crisp and clear, but if the rectangles are included, when the screen refreshes, for a split second on refresh it is clear but the black 'ink' dims out instantly. The issue is exactly the same if I use "it.line" or "it.rectangle" of similar dimensions.

If I only use very short horizontal lines or rectangles then the issue is less noticeable, but for long horizontal lines and rectangles the entire display goes dim.

Problem-relevant YAML-configuration entries:

esphome:
  name: cabin-epaper
  platform: ESP32
  board: esp32dev
  on_boot:
    priority: -10
    then:
      - delay: 10s
      - component.update: epaperdisplay

wifi:
  networks:
  - ssid: [removed]
    password: [removed]

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: [removed]

font:
  - file: 'fonts/Roboto-Regular.ttf'
    id: footer_font
    size: 15
    glyphs:
      ['&', '@', '!', ',', '.', '"', '%', '(', ')', '+', '-', '_', ':', '°', '0',
       '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E',
       'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S',
       'T', 'U', 'V', 'W', 'X', 'Y', 'Z', ' ', 'a', 'b', 'c', 'd', 'e', 'f',
       'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',
       'u', 'v', 'w', 'x', 'y', 'z','å', 'ä', 'ö', '/','º','µ','³']

  - file: 'fonts/Roboto-Regular.ttf'
    id: main_sensor_unit
    size: 20
    glyphs:
      ['&', '@', '!', ',', '.', '"', '%', '(', ')', '+', '-', '_', ':', '°', '0',
       '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E',
       'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S',
       'T', 'U', 'V', 'W', 'X', 'Y', 'Z', ' ', 'a', 'b', 'c', 'd', 'e', 'f',
       'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',
       'u', 'v', 'w', 'x', 'y', 'z','å', 'ä', 'ö', '/','º','µ','³']

  - file: 'fonts/Roboto-Bold.ttf'
    id: main_sensor_font
    size: 54
    glyphs:
      ['&', '@', '!', ',', '.', '"', '%', '(', ')', '+', '-', '_', ':', '°', '0',
       '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E',
       'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S',
       'T', 'U', 'V', 'W', 'X', 'Y', 'Z', ' ', 'a', 'b', 'c', 'd', 'e', 'f',
       'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',
       'u', 'v', 'w', 'x', 'y', 'z','å', 'ä', 'ö', '/','º','µ','³']

  - file: 'fonts/materialdesignicons-webfont.ttf'
    id:  mdi_wifi
    size: 20
    glyphs: [
      # Wifi
      '󰤫', # mdi-wifi-strength-alert-outline
      '󰤟', # mdi-wifi-strength-1
      '󰤢', # mdi-wifi-strength-2
      '󰤥', # mdi-wifi-strength-3
      '󰤨'  # mdi-wifi-strength-4
      ]

time:
  - platform: homeassistant
    id: homeassistant_time

sensor:
  - platform: wifi_signal
    name: "WiFi Signal Sensor"
    id: wifisignal
    update_interval: 60s

spi:
  clk_pin: 13   #SCK
  mosi_pin: 14  #DIN

display:
  - platform: waveshare_epaper
    id: epaperdisplay
    cs_pin: 15
    dc_pin: 27
    busy_pin: 25
    reset_pin: 26
    update_interval: 600s
    model: 7.50inV2
    lambda: |-

      static const char* TAG = "epaperdisplay";
      ESP_LOGD(TAG, "Writing to e-ink display");

      it.print(775, 17, id(main_sensor_unit), TextAlign::BASELINE_RIGHT, "E-Paper is awesome!");
      it.print(0, 460, id(main_sensor_unit), "E-Paper is awesome!");

      /* TOP */
      it.print(10, 10, id(main_sensor_unit), "TOP");
      it.filled_rectangle(98, 21, 400, 3);
      it.print(15, 60, id(main_sensor_font), "Test 1");

      /* MIDDLE */
      int offsetY = 200;
      it.print(10, 10 + offsetY, id(main_sensor_unit), "MIDDLE");
      it.filled_rectangle(98, 21 + offsetY, 500, 3);
      it.print(400, 80 + offsetY, id(main_sensor_font), TextAlign::BASELINE_CENTER, "Test 2");

      /* BOTTOM */
      int offsetYb = 360;
      it.print(10, 10 + offsetYb, id(main_sensor_unit), "BOTTOM");
      it.filled_rectangle(98, 21 + offsetYb, 600, 3);
      it.print(775, 80 + offsetYb, id(main_sensor_font), TextAlign::BASELINE_RIGHT, "Test 3");

      /* FOOTERT */
      it.strftime(755, 475 , id(footer_font), TextAlign::BASELINE_RIGHT , "Updated at %d/%b/%Y %H:%M", id(homeassistant_time).now());

      /* WiFi Signal Strenght */
      if(id(wifisignal).has_state()) {
        int x = 775;
        int y = 475;
        if (id(wifisignal).state >= -50) {
            //Excellent
            it.print(x, y, id(mdi_wifi), TextAlign::BASELINE_CENTER, "󰤨");
            ESP_LOGI("WiFi", "Exellent");
        } else if (id(wifisignal).state  >= -60) {
            //Good
            it.print(x, y, id(mdi_wifi), TextAlign::BASELINE_CENTER, "󰤥");
            ESP_LOGI("WiFi", "Good");
        } else if (id(wifisignal).state  >= -75) {
            //Fair
            it.print(x, y, id(mdi_wifi), TextAlign::BASELINE_CENTER, "󰤢");
            ESP_LOGI("WiFi", "Fair");
        } else if (id(wifisignal).state  >= -100) {
            //Weak
            it.print(x, y, id(mdi_wifi), TextAlign::BASELINE_CENTER, "󰤟");
            ESP_LOGI("WiFi", "Weak");
        } else {
            //Unlikely working signal
            it.print(x, y, id(mdi_wifi), TextAlign::BASELINE_CENTER, "󰤫");
            ESP_LOGI("WiFi", "Unlikely");
        }
      }

Logs (if applicable):

The logs do not display any errors.

Additional information and things you've tried: I have tried this with two separate Waveshare 7.5in V2 e-paper displays, and two separate ESP32 driver boards, and get the same results for each combination, so it does not seem to be a faulty hardware issue.

[probot-esphome[bot]]

waveshare_epaper source waveshare_epaper issues waveshare_epaper recent changes _{^{(message by IssueLinks)}}

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gonzotek]

I observe similar behavior with the same model (7.5inV2 waveshare e-paper). I'm not working with rects and lines though, only fonts.

[TheStork239]

Yes, the issue is still there. I think what we are short of is a developer who knows the waveshare code and has time to look at how the code in ESPHome needs to be modified for the various “v2” boards out now. I presume the waveshare displays do not have a named “owner” within the ESPHome community. I tried to eyeball the example code on Waveshare’s own wiki and compare with the code of ESPHome but could not spot anything glaring. But then again it’s probably way beyond my skillset, so I am afraid I was able to spot the issue but probably not able to identify the cause and suggest a fix myself.

[dimitribellini]

I would like to share also my experience. In my case with Waveshare 7.2v2 with Hat v.2.2 after a loto testing i can not see nothing on the screen. I have used a Wemos Lolin32 lite and follow this project (https://github.com/G6EJD/ESP32-e-Paper-Weather-Display) to test if the screen is working and it works!!! But not with Esphome... Maybe as reported by previous project is something related to the new HAT version 2.2? I need to change this on the Arduino project:

NOTE change needed for latest Waveshare HAT versions Ensure you have the latest GxEPD2 library See here: https://github.com/ZinggJM/GxEPD2/releases/tag/1.2.10 Modify this line in the code: display.init(115200, true, 2); // init(uint32_t serial_diag_bitrate, bool initial, uint16_t reset_duration, bool pulldown_rst_mode)

Thanks to all EspHome team for the great work made!!! and thanks for a possible solution/Fix

[napalmz]

Having same issued with 7.5inV2 and Waveshare ESP32 Driver Board. Waveshare support said could be a "capacitor problem" and suggested me to change it... it's way beyond my skills so i refused. Also because this board is specifically designed by them to support their display. I hope an update in ESPhome can fix this situation.

[TheStork239]

Having same issued with 7.5inV2 and Waveshare ESP32 Driver Board. Waveshare support said could be a "capacitor problem"

I have tried with two separate 7.5inV2 displays with two separate waveshare ESP32 driver boards with two separate cables, so I doubt it would be a faulty capacitor on one board / display (or some other hardware fault). I am still thinking it’s a software issue with ESPhome that can be fixed. I guess we are short of a coding “champion” for the ESPhome support for waveshare displays, who might have an idea on how to fix it.

[napalmz]

Yesterday I tried printing some images (B/W 800x480 png) with different pattern. Here some examples:

• A solid black image get displayed flawlessly.
• A solid black image with a white box inside get displayed but the space over/under the white box get a little bit gray.
• A photo of me and my son (attach 1) (of course converted to B/W) get displayed correctly, with solid black parts.
• The photo of a landscape with trees (attach 2) is drawn quite well, only the vertical part of the trees is black while the oblique / horizontal branches are gray
• A pattern (dovetail like) with thin lines get completely screwed (attach 3)

So basically problems arrives when you mix a lot of thin black parts with white ones, especially oblique.

Some example pictures (every image is natively 800x480px, no resize done by ESPhome):

UPDATE After get my hands on a RaspberryPi W0,i tryed it with standard Waveshare demo code. These are the results: There demo codes made me think there's a fault in these display, maybe the majority of them.

[Eriner]

Should be resolved by esphome/esphome#3121 if you're seeing these symptoms on a 7.5in-BV2, which is the version with red color.

[napalmz]

No difference so far on 7.5inv2 (B/W), still degrades over time/pattern.

[TheStork239]

Just tested again with ESPHome 2022.3.2, and the issue of grainy / dim display is very much still there, even with changing the reset_duration parameter to 2ms (instead of default 200ms) which was suggested by some.

It seems that the Waveshare e-paper example code at least for Arduino had some bugs fixed 8-9 months ago; have those made it into ESPHome's code for Waveshare 7.50inV2? https://github.com/waveshare/e-Paper/tree/master/Arduino/epd7in5_V2

[Egglestron]

To this day, it still looks terrible under certain circumstances (lines and rectangles seem indeed to make the issue worse).

The first version of the screen I had, which had a wider connector on the screen end, didn't exhibit the issue (but had a failing line of pixels so I had to return it)...

Settings tried:

model: 7.50inV2 / 7.50inV2alt
reset_duration: 200ms / 2ms

[droans]

I had the same issue when using 7.50inV2alt. Whenever there were too many pixels turned on in a given row, it would become very grainy.

However, it works perfectly with these settings:

spi:
    clk_pin: GPIO18
    mosi_pin: GPIO23

display:
    - platform: waveshare_epaper
        cs_pin: GPIO26
        dc_pin: GPIO25
        busy_pin: GPIO27
        reset_pin: GPIO33
        model: 7.50inV2
        update_interval: 30s
        reset_duration: 2ms
        rotation: 90°
        lambda: |-
        ....

[napalmz]

As of today, still same result using reset duration 2ms and model 7.50inV2.

[droans]

Hmm.

I swapped to the B/W/R model. Definitely noticing it on this one now, so it seems the issue varies for each panel.

Their documentation say that you can use either 3.3v or 5v for the input, but the FAQ states the rated voltage is 2.3-3.6v and says to use a level converter if you use 5v. However, the spec guide says it can accept up to 6v while the panel is limited to 3.6v.

The documentation is hard to understand because of translation issues. They seem to imply that there both is and isn't a level converter in the driver board.

The FAQ also suggests increasing VCOM voltage or reducing "the position of the round brush".

From what I can see, VCOM is being set to 1.9v. The docs seem to suggest that it be set to the same as the supply range, 2.3v-3.6v ±0.1. I might be reading it wrong though. I don't know much at all about microcontrollers.

I don't know what they mean by the round brush, though.

When I have time, I'm going to test this theory and bump it up slightly to see if there's an improvement.

[droans]

Okay, I increased VCOM up to 2.3v. Unfortunately it still hasn't really improved, so it's not that.

[lucasimons]

Okay, I increased VCOM up to 2.3v. Unfortunately it still hasn't really improved, so it's not that

Are there any improvement? which version of 7.5in is 100% compatible?

[droans]

Are there any improvement? which version of 7.5in is 100% compatible?

Sorry - forgot to ever come back. That did not work for me, but I think I have found the issue. I have been using a forked version of the Waveshare component that added support for Red in the BRW model. Unfortunately, I don't know for certain what will need to be changed here. I have been able to get it almost perfect for me, although there is some minor graininess.

However, if you are using the same version (ESPHome Model 7.50in-bv2), try this:

Download the esphome/esphome/components/waveshare_epaper directory and place it in a location accessible by ESPHome. Add it as an external component.

Go to the line void WaveshareEPaper7P5InBV2::initialize() {. Currently this is line 940.

Change the code to match below:

void WaveshareEPaper7P5InBV2::initialize() {
  // COMMAND POWER SETTING
  this->command(0x01);
  this->data(0x07);
  this->data(0x17);  // VGH=20V,VGL=-20V
  this->data(0x3f);  // VDH=15V
  this->data(0x3f);  // VDL=-15V

  // BOOSTER SETTING
  this->command(0x06);
  this->data(0x17);
  this->data(0x17);
  this->data(0x24);
  this->data(0x17);

  // COMMAND PLL SETTING
  this->command(0x30);
  this->data(0x06);

  // COMMAND POWER ON
  this->command(0x04);
  delay(100);  // NOLINT
  this->wait_until_idle_();

  // COMMAND PANEL SETTING
  this->command(0x00);
  this->data(0x0F);     // KW3f, KWR-2F, BWROTP 0f, BWOTP 1f

  // COMMAND VCOM DC SETTING
  this->command(0x82);
  this->data(0x30);

  this->command(0x61);  // tres
  this->data(0x03);     // 800px
  this->data(0x20);
  this->data(0x01);  // 400px
  this->data(0xE0);

  this->command(0x15);
  this->data(0x00);

  // COMMAND VCOM AND DATA INTERVAL SETTING
  this->command(0x50);
  this->data(0x11);
  this->data(0x07);

  // COMMAND TCON SETTING
  this->command(0x60);
  this->data(0x22);

  // COMMAND RESOLUTION SETTING
  this->command(0x65);
  this->data(0x00);
  this->data(0x00);  // 800*480
  this->data(0x00);
  this->data(0x00);
}

Command power is changed, booster is added, and VCOM DC Settings are added. You may find it helpful to remove the PLL settings.

If you are using a different model, I'm not sure what the correct answer is. You can download the spec sheet for your model and try making the changes to your config.

[jschlyter]

@droans any updates on integrating the fix above? Did you have a link to the forked version with support for red colour?

[droans]

Here's my forked component..

There are many ways to add it. You could clone the source and redownload every now and then, download just the files in the waveshare folder to ESPHOME_DIR/components/waveshare_epaper, or just use a GitHub source for the component. My recommendation is either cloning or downloading.

You will want to add this to your ESPHome device config:

external_components:
  - source:
      type: local
      path: ${COMPONENTS_DIR}     # Points to the esphome/components directory.
    components:
      - waveshare_epaper

color:
  - id: COLOR_RED
    red: 100%
    green: 0%
    blue: 0%
    white: 0%
  - id: COL_BLACK                  # Code changes improved performance, but inverted black/white. 
    red: 100%
    green: 0%
    blue: 0%
    white: 0% 

Keep in mind that this isn't perfect. Red seems to be nearly perfect for me while black shows slight issues in fine text or when there is still too much. However, it still displays black much more clearly than the default config.

If you want to try and mess around with the code to improve your display, here's where you'll begin. From my experience so far, the VCOM DC setting and VCOM/Data Interval settings are the most likely culprit.

For more help, here is a link to the dev guide for the BWR 7.5" Waveshare Display. There's a lot of information here. The command table begins on page 22 with the section afterwards providing more information.

[jschlyter]

@droans seems to work a lot better! Any chance of gettings this improved component merged?

[droans]

Might try at some point, but honestly the changes were mostly educated stabs in the dark.

It also seems likely even more improvements can be made to improve the display and some code I adjusted likely didn't make much difference.

The original code also came from someone else. I'm not certain how compatible it is with just the B/W version or if it would need to be a new module.

[Madelena]

Since my project uses this exact same screen and it has been kinda popular, a few of us are beginning to run into this issue since it was published 6 months ago. Do you know what it takes to get these bug fixes and changes to be merged?

[droans]

Nice surprise seeing you here - my display was based on your original project with some changes made to better suit my needs. Thank you for providing the inspiration and config!

I'm not sure what would be needed, but I think we'd need someone who could better understand the code. I know next to nothing about these displays or C++ and honestly just used the documentation and a bunch of trial and error to figure out what worked. It's likely there are even more changes that could be made to improve the displays.

I'd guess our best bets would be to reach out to the devs on Discord and ask them to take a look or to ask Waveshare to submit a PR to improve the code.

I'm not a developer, but I'm guessing "It works, but I don't know why" isn't really a good reason to submit a pull request.

[droans]

Okay, I think I just got it absolutely perfect. See my updated comment above - I changed the booster settings to increase the strength of Phase C Booster. If that isn't enough for you, adjust the second to last data from the booster from 0x24 to 0x34.

Can someone with a B/W model test adding the booster settings to their config? It appears to be perfect for my BWR model.

[napalmz]

Hello @droans I put this in my cfg but I can't see any difference, I'm using a BW V2.

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

While compiling it shows that it's using GIT or not? Compiling logs says nothing.

Thank you

[droans]

@napalmz

I had to make some changes since I need to eventually get the code merged. Use ref: waveshare-color instead.

[bluesheep]

@droans I tried to add your code to my B&W display.

I added this to my config

# external_components:
#   - source:
#       type: git
#       url: https://github.com/droans/esphome-components
#       ref: waveshare-color
#     components: [ waveshare_epaper ]

I get the following errors when compiling:

Compiling /data/hall-epaper/.pioenvs/hall-epaper/src/main.cpp.o
src/main.cpp: In function 'void setup()':
src/main.cpp:3961:63: error: invalid new-expression of abstract class type 'esphome::waveshare_epaper::WaveshareEPaper7P5InV2'
   paper_screen = new waveshare_epaper::WaveshareEPaper7P5InV2();
                                                               ^
In file included from src/esphome.h:74,
                 from src/main.cpp:3:
src/esphome/components/waveshare_epaper/waveshare_epaper.h:312:7: note:   because the following virtual functions are pure within 'esphome::waveshare_epaper::WaveshareEPaper7P5InV2':
 class WaveshareEPaper7P5InV2 : public WaveshareEPaper {
       ^~~~~~~~~~~~~~~~~~~~~~
In file included from src/esphome.h:19,
                 from src/main.cpp:3:
src/esphome/components/display/display_buffer.h:375:23: note:   'virtual esphome::display::DisplayType esphome::display::DisplayBuffer::get_display_type()'
   virtual DisplayType get_display_type() = 0;
                       ^~~~~~~~~~~~~~~~
*** [/data/hall-epaper/.pioenvs/hall-epaper/src/main.cpp.o] Error 1

My display config is below:

display:
  - platform: waveshare_epaper
    update_interval: 12h
    reset_duration: 2ms
    id: paper_screen
    cs_pin: GPIO15
    dc_pin: GPIO27
    busy_pin: GPIO25
    reset_pin: GPIO26
    model: 7.50inV2

[droans]

@bluesheep try using 7.50inv2b instead. If that doesn't work, I can try to add the B/W changes to a different branch.

I was getting a similar error when I first tried to rebase back to the standard code.

[bzzbzzz]

color:

• id: COLOR_RED red: 100% green: 0% blue: 0% white: 0%
• id: COL_BLACK # Code changes improved performance, but inverted black/white. red: 100% green: 0% blue: 0% white: 0%

Did you set both colors to 100% red, 0% g/b/w on purpose ?

[droans]

Just a typo; Black is 0% for everything.

[Egglestron]

@bluesheep try using 7.50inv2b instead. If that doesn't work, I can try to add the B/W changes to a different branch.

I was getting a similar error when I first tried to rebase back to the standard code.

That would indeed be awesome if you could include those changes for the BW version!

[EagleStClair]

@bluesheep try using 7.50inv2b instead. If that doesn't work, I can try to add the B/W changes to a different branch.

I was getting a similar error when I first tried to rebase back to the standard code.

I tried 7.50inv2b but it wouldn’t render at all.

[Draexl]

Has anyone gotten a 7.5 V2 B/W model stable? If so, with which config? Please post the YAML with all content.

[Kumskaka]

Hi, I have a similar problem with the model 7.5 480x800 and use the model: 7.50inV2alt. All other models don't work. Some pictures and some text are fine, but with more pictures (lines are very bad) and text, the display gets grainy. I change the VCC to 5V and help a little. Is there another way?

[Egglestron]

I flashed my Waveshare ESP32 driver with the Wi-Fi Demo from Waveshare (https://www.waveshare.com/wiki/E-Paper_ESP32_Driver_Board#WiFi_Demo), and it doesn't exhibit the "grain" issue at all. There are still some banding on some images, but it's an overall very nice improvement over ESPHome's implementation.

However, I tried building a custom ESPHome component with the parameters from the demo, and couldn't get it to improve significantly. If anyone wants to give it a try...

[Egglestron]

I think I found the solution after giving it another shot during this long week-end in France. 😃

Using the datasheet and the Arduino examples of the screen, I came up with this configuration (modified waveshare_epaper.cpp source file, search for "MMI" comments to see changes):

void WaveshareEPaper7P5InV2alt::initialize() {
    ESP_LOGI(TAG, "MMI160723 initialize");
  this->reset_();

  // COMMAND POWER SETTING
  this->command(0x01);
  // 1-0=11: internal power
  this->data(0x07);  // MMI: changed it from 0x17
  this->data(0x17);  // VGH&VGL
  this->data(0x26);  // VSH - MMI: changed value from max voltage 0x3F to recommended datasheet value --> reduces black streaks on white vertical space. This setting is comparable to "Contrast" on old crystal liquid displays.
  this->data(0x26);  // VSL - MMI: same as VSH (High) but for Low
  this->data(0x11);  // VSHR

  // VCOM DC Setting
  this->command(0x82);
  this->data(0x24);  // VCOM

  // Booster Setting
  this->command(0x06);
  this->data(0x27);
  this->data(0x27);
  this->data(0x2F);
  this->data(0x17);

    // MMI: disabled command as not present in the Arduino example, disabling may not be needed
  // OSC Setting
    // this->command(0x30);
    // this->data(0x06);  // 2-0=100: N=4  ; 5-3=111: M=7  ;  3C=50Hz     3A=100HZ

  // POWER ON
  this->command(0x04);

  delay(100);  // NOLINT
  this->wait_until_idle_();
  // COMMAND PANEL SETTING
  this->command(0x00);
  this->data(0x3F);  // KW-3f   KWR-2F BWROTP 0f BWOTP 1f

  // COMMAND RESOLUTION SETTING
  this->command(0x61);
  this->data(0x03);  // source 800
  this->data(0x20);
  this->data(0x01);  // gate 480
  this->data(0xE0);
  // COMMAND ...?
  this->command(0x15);
  this->data(0x00);
  // COMMAND VCOM AND DATA INTERVAL SETTING
  this->command(0x50);
  this->data(0x10);
  this->data(0x00); // MMI: changed to value found in Arduino example, may not be needed
  // COMMAND TCON SETTING
  this->command(0x60);
  this->data(0x22);
  // Resolution setting
  this->command(0x65);
  this->data(0x00);
  this->data(0x00);  // 800*480
  this->data(0x00);
  this->data(0x00);

  this->wait_until_idle_();

  uint8_t lut_vcom_7_i_n5_v2[] = {
      0x0, 0xF, 0xF, 0x0, 0x0, 0x1, 0x0, 0xF, 0x1, 0xF, 0x1, 0x2, 0x0, 0xF, 0xF, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  };

  uint8_t lut_ww_7_i_n5_v2[] = {
      0x10, 0xF, 0xF, 0x0, 0x0, 0x1, 0x84, 0xF, 0x1, 0xF, 0x1, 0x2, 0x20, 0xF, 0xF, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
      0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  };

  uint8_t lut_bw_7_i_n5_v2[] = {
      0x10, 0xF, 0xF, 0x0, 0x0, 0x1, 0x84, 0xF, 0x1, 0xF, 0x1, 0x2, 0x20, 0xF, 0xF, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
      0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  };

  uint8_t lut_wb_7_i_n5_v2[] = {
      0x80, 0xF, 0xF, 0x0, 0x0, 0x3, 0x84, 0xF, 0x1, 0xF, 0x1, 0x4, 0x40, 0xF, 0xF, 0x0, 0x0, 0x3, 0x0, 0x0, 0x0,
      0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  };

  uint8_t lut_bb_7_i_n5_v2[] = {
      0x80, 0xF, 0xF, 0x0, 0x0, 0x1, 0x84, 0xF, 0x1, 0xF, 0x1, 0x2, 0x40, 0xF, 0xF, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
      0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0,  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  };

  uint8_t count;
  this->command(0x20);  // VCOM
  for (count = 0; count < 42; count++)
    this->data(lut_vcom_7_i_n5_v2[count]);

  this->command(0x21);  // LUTBW
  for (count = 0; count < 42; count++)
    this->data(lut_ww_7_i_n5_v2[count]);

  this->command(0x22);  // LUTBW
  for (count = 0; count < 42; count++)
    this->data(lut_bw_7_i_n5_v2[count]);

  this->command(0x23);  // LUTWB
  for (count = 0; count < 42; count++)
    this->data(lut_wb_7_i_n5_v2[count]);

  this->command(0x24);  // LUTBB
  for (count = 0; count < 42; count++)
    this->data(lut_bb_7_i_n5_v2[count]);

  ESP_LOGI(TAG, "MMI initialize END");
}

Please test and tell me if it works for you!

[Kumskaka]

Hi, thank you for addressing this issue. I've tried to test this, but I haven't used Github in this way to test changes in esphome. I forked esphome and put your code in the file as a replacement. And uses the function of the external component in esphome.

external_components:

• source: type: git url: https://github.com/Kumskaka/esphome ref: dev components: [ waveshare_epaper ]

But I get this errors. raceback (most recent call last): File "/usr/local/bin/esphome", line 33, in <module> sys.exit(load_entry_point('esphome', 'console_scripts', 'esphome')()) File "/esphome/esphome/__main__.py", line 1015, in main return run_esphome(sys.argv) File "/esphome/esphome/__main__.py", line 1002, in run_esphome rc = POST_CONFIG_ACTIONS[args.command](args, config) File "/esphome/esphome/__main__.py", line 433, in command_run exit_code = write_cpp(config) File "/esphome/esphome/__main__.py", line 185, in write_cpp generate_cpp_contents(config) File "/esphome/esphome/__main__.py", line 197, in generate_cpp_contents CORE.flush_tasks() File "/esphome/esphome/core/__init__.py", line 626, in flush_tasks self.event_loop.flush_tasks() File "/esphome/esphome/coroutine.py", line 246, in flush_tasks next(task.iterator) File "/esphome/esphome/__main__.py", line 177, in wrapped await coro(conf) File "/config/esphome/.esphome/external_components/835274e3/esphome/components/waveshare_epaper/display.py", line 156, in to_code config[CONF_LAMBDA], [(display.DisplayRef, "it")], return_type=cg.void AttributeError: module 'esphome.components.display' has no attribute 'DisplayRef' Do you know what I'm doing wrong?

[Egglestron]

I think the dev branch has some breaking changes related to the display integration. I would fork the code from the current version branch you have (mine is 2023.6.5).

I personally copied and edited the files locally:

external_components:
  - source:
      type: local
      path: waveshare_epaper_mmi
    components: [waveshare_epaper]

[Kumskaka]

Thank you, i used now the last release version 2023.6.5 and used the local way. Now it worked and I will see a better image and will let it run for some time and check, if there any changes over time.

[tunip]

@Egglestron I also tested your changes and it looks much better on my e-Paper. Thanks for your investigation!

[Draexl]

That sounds wonderful. How and when will the change come as an update? What are the next steps?

[prapador]

I've tested the changes, and it seems to look much better now. I tried applying those changes to void WaveshareEPaper7P5InV2::initialize (version not alt), and it appears to be working correctly.

I'll conduct some further tests in the next few days, but it's looking very promising. If it doesn't cause any issues, perhaps we could submit a pull request.

Thank you very much for your time, @Egglestron !

[napalmz]

I've tested the changes, and it seems to look much better now. I tried applying those changes to void WaveshareEPaper7P5InV2::initialize (version not alt), and it appears to be working correctly.

I'll conduct some further tests in the next few days, but it's looking very promising. If it doesn't cause any issues, perhaps we could submit a pull request.

Thank you very much for your time, @Egglestron !

Could you please give a link to the modified version for WaveshareEPaper7P5InV2? I've one to test. Tank you.

[requiemmg]

I second that request, just stumbled upon this issue when I was looking for a solution, so I'd be happy to test; I have 2 7.50inV2alt-devices up and running at the moment and they are both very grainy. Tell me how to test and I'll gladly do!

[prapador]

After some preliminary tests, the changes for version v2 (non-alt) don't seem to work. After disconnecting the ESP32 board, the image appeared with very little contrast, but while it was functioning, it looked fine. I don't know what could be causing it to work sometimes and not others. The changes I made were the same as for WaveshareEPaper7P5InV2alt. I don't have much knowledge of C, so everything has been trial and error.

On the other hand, the alt version seems to work consistently. I have tested the changes locally by downloading the code and modifying the part indicated by @Egglestron . Even so, I have created a fork with the changes so that they can be tested directly without downloading anything.

To use this, just add the following to the corresponding ESPHome YAML file:

external_components:
  - source:
      type: git
      url: https://github.com/prapador/esphome_waveshare_fix
      ref: dev
    components: [ waveshare_epaper ]

The fork only contains the changes for the WaveshareEPaper7P5InV2alt version.

[requiemmg]

Wow! This fix made it a LOT better! Only a little grainy when refreshing now, but the display now is absolutely great after the refresh!

[Egglestron]

I've made further changes to reduce the remaining graininess:

// COMMAND POWER SETTING
  this->command(0x01);
  // 1-0=11: internal power
  this->data(0x07);
  this->data(0x17);  // VGH&VGL
  this->data(0x3F);  // VSH
  this->data(0x26);  // VSL
  this->data(0x11);  // VSHR

Setting VSH at 0x3F made it even better for me! :)

[Kumskaka]

Thank you, I testet it and it is better. ;)

[napalmz]

Hi All, I've changed my config to use ALT version with @prapador repo and IT WOKS!!! Hope this will be pushed soon to main branch.