esphome
esphome copied to clipboard
Fix partial update for waveshare 2in9 v2
Based on https://www.waveshare.com/w/upload/7/79/2.9inch-e-paper-v2-specification.pdf and https://github.com/waveshare/e-Paper/blob/master/Arduino/epd2in9_V2/epd2in9_V2.cpp
What does this implement/fix?
Partial update of waveshare epaper display 2in9 v2 did not work properly.
Types of changes
- [x] Bugfix (non-breaking change which fixes an issue)
Related issue or feature (if applicable): fixes [https://github.com/esphome/issues/issues/2334#issuecomment-991962779](https://github.com/esphome/issues/issues/2334#issuecomment-99196277
Test Environment
- [x] ESP32
- [ ] ESP32 IDF
- [ ] ESP8266
Example entry for config.yaml:
spi:
clk_pin: D0
mosi_pin: D1
#miso_pin: D7 #not connected
display:
- platform: waveshare_epaper
cs_pin: D2
dc_pin: D3
busy_pin: D4
reset_pin: D5
model: 2.90inv2
#id: mydisplay
update_interval: 30s
full_update_every: 180
rotation: 90°
#brightness: 100%
lambda: |-
//Header
it.strftime(0, 0, id(font4), TextAlign::TOP_LEFT, "%a %H:%M", id(esptime).now());
it.print(0, 50, id(font3), "TESTING");
Checklist:
- [x] The code change is tested and works locally.
- [ ] Tests have been added to verify that the new code works (under
tests/folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in esphome-docs.
Could you either merge dev into your branch, or rebase it on dev, to fix the merge conflict? That would allow CI to run.
Hello! does this need a ping somewhere to get it merged? From https://github.com/esphome/issues/issues/2334, it looks like this fixes the 2.9 v2.1 display.
I just tried the fix from jonOfrie applied to the dev branch and it's working far better for me with the following config:
full_update_every: 30
reset_duration: 2ms
With the current code in dev, the 2.90inv2 display is unusable - slow updates, flashing, snow, it's unreadable.
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.
Hi, I just want to point out that the problem exists with the 1.54" v2 epaper display as well and unfortunately, this is only a fix for the 2in9 v2 display and it doesn't work for 1.54" v2, I have tried to include it via external_components. It's probably useful to double check if there are other modules with partial updates with differing refresh rates in order to fix this problem for all supported waveshare models. I'll try to get this fixed for my device maybe next weekend.
@bzeiss The change I posted on Feb 14 is specific to the 2in9 v2 display as it is the only one I have to test with. Could you see if you can adapt it to work on the 1.54 as well?
Hi, I just want to point out that the problem exists with the 1.54" v2 epaper display as well and unfortunately, this is only a fix for the 2in9 v2 display and it doesn't work for 1.54" v2, I have tried to include it via external_components. It's probably useful to double check if there are other modules with partial updates with differing refresh rates in order to fix this problem for all supported waveshare models. I'll try to get this fixed for my device maybe next weekend.
I only have the 1.54 v2 display and wanted to get it to work so I implemented @LukasK13's fix for the 1.54v2. Although I didn't add support for the 2.9v2 version in my fork, I could add it pretty easily, but since I don't have that screen and have limited time, I didn't do it yet.
To use my external component add this to your yaml file:
external_components:
- source:
type: git
url: https://github.com/Ricostyle21/esphome
ref: dev
components: [ waveshare_epaper]
I'm working on getting my seeed XIAO ESP32C3 work with the waveshare 2.9 inch v2 eink display, and this PR helped me tremendously. I does observe several issues that need to be addressed before this get merged in:
- Donot use 5v ! For whatever reason, even though the spec says 3-5v all good, my display will display garbled noise on 5v. Switch to 3.3v works immediately. Might be an issue with my 5v power? IDK but if you have issue check if you are on 3.3v.
- init depends on reset pin, thus making reset pin a required property. I have tried to not do reset on init, and eink display doesn't work without it.
- busy pin seems to be a required property right now. if no busy pin defined, wait_until_idle_ will return false too fast, making the display garbble or display wrong information? I tried adding a delay before returning false, and it seems to fix any display issue without busy pin. So maybe we need to add a generic safe delay for reset, partial refresh, and full refresh.
- CS pin can be made optional, if the display is the only one on the SPI lane, CS pin can be connected straight to ground. I can set CS_PIN to a non existing pin right now and it works just fine. I guess this is due to requirement of the SPI module?
- I tried to merge this change to the latest esphome dev branch, and it doesn't work well for some reason. I did took a quick look at display and waveshare modules, didn't see anything that should have broken it, but it is broken.
I will be doing more reading in the coming days, thanks for all the work, it saved my project.
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.
This issue still persists in esphome and is waiting to be merged. The issue is not stale.
This issue still persists in esphome and is waiting to be merged. The issue is not stale.
Lukas, did you get a chance to try my variation that I posted on Feb 14th 2022? It works without the delay. I have been running it on my 2.90inv2 since then and it is working great. I suspect the 1.54v2 needs a very similar change. Since nobody seems to have both a 1.54v2 and a 2.90v2 it might need some cooperation to get this in. I only have a 2.9 but would be willing to test with it if someone with a 1.54 wants to make a combined 1.54/2.90 fix.
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.
I think this issue still persists. what are the next steps?
On Sun, Jul 23, 2023 at 5:45 PM github-actions[bot] < @.***> wrote:
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.
— Reply to this email directly, view it on GitHub https://github.com/esphome/esphome/pull/2912#issuecomment-1647033807, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6BENCMQQNPMY5MTEPZK53XRXATRANCNFSM5J6EIIEQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
--
Hi, any updates for this PR? The 2.9inV2 it's trash :(
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.