What have you tried? If I were you, I would try the native ePaper component with model '4.20in-v2’. I will admit though that I’m not sure what driver differences, if any, for the ‘old version’ vs current there would be.
Anyway, not knowing what you’ve tried means it is difficult to suggest any help…
So I investigated ottes42 github code and that is someone who has forked my code and then renamed the custom_component directory to component/weact_epaper. They have not updated their LOG_PIN(…) pin code and therefore their repository is currently outdated and won’t compile with current ESPHome (they last updated their code 4 months ago). In addition they are outdated with my code since theirs does not implement the is_display_busy() function which is very useful if optimizing when your device can go to sleep (this function actually tells you when the display has finished updating in the background).
What it looks like they tried to do is change the WaveShare epaper base code into WeAct without considering the impact it would just turn around and have to WaveShare. They renamed the waveshare_epaper.h file into weact_epaper.h. The problem is…this requires all the waveshare_XX.h files to also use weact_epaper.h (instead of the original waveshare_epaper.h) and from a coding perspective this just renamed the dependency and now waveshare relies on weact_epaper.h. From ESPHome’s native ePaper component code…it now diverts from it instead of just adds to it making maintenance and syncing more difficult.
Since many ePaper drivers have common commands (regardless of the manufacturer of the ePaper…it’s the driver that’s important), having two separate components that use the same base code is redundant and not good for maintenance. The more preferred method would be to take WaveShare_ePaper and just make it something like ESPHome_ePaper that now supports multiple manufacturers while still using a common base. Of course the reality is that we can still call it the WaveShare_ePaper component and have it support other manufacturers…which is exactly what I’ve done.
Anyway, I chose not to divert from ESPHome’s native code knowing a change like that would be a huge breaking change (for all current WaveShare ePaper users). When I submitted my code to Espressif (or whoever is maintaining the ESPHome library) I did it exactly the way you see in my repository which doesn’t break any current code. Because of that I believe in the next ESPHome update it will finally become part of the native code (not sure about the is_display_busy() function though, but I don’t see why they shouldn’t include it).
In the end it’s up to you which repository you want to use…but, you should always do some research about the coder, the repository, where the code came from (if it’s forked/cloned or original), how often it is maintained, etc. When looking at forks, pay special attention to why it was forked. For some people they just want to have their own repository of some code snapshot and it just sits there and becomes stale. In those cases track back the original code provider and use that instead…it’ll save you some headaches.
I don’t know how & what you did 
but I can tell: today, after whole weekend spent with this creature, ESPHome different variants, models, then PlatformIO approach, Copilot, Chatgpt and nothing, I finally made it displaying some readable text.
- platform: waveshare_epaper
id: epd
cs_pin: GPIO5
dc_pin: GPIO17
reset_pin: GPIO16
busy_pin: GPIO4
model: gdey042t81 # <- Game changer for WeAct 4.2" BW
reset_duration: 2ms
update_interval: 15s
rotation: 0
lambda: |-
it.fill(COLOR_OFF);
it.print(10, 30, id(f20), COLOR_ON, "Test E-Paper");
Maybe it will be useful to someone.
That’s definitely a different driver than what is currently being used (and what I would’ve expected). Wonder how many units of this older model are out there?? How long ago did you purchase it and from where?
Also…have you tried drawing a rectangle around the border to make sure all pixels within the screen are accessible? I know sometimes using a driver not specifically intended for your screen ends up causing problems with the pixels at the bottom not displaying correctly (assuming you get anything to display that is lol).
It was ordered ca. two weeks ago from Aliexpress, so pretty fresh. Didn’t try a rectangle, currently I’m fighting with forecast, how to make it working properly with HA, but will try.
OMG FINALLYYYYY THANKSSSSSSS
i’m nearly go crazy for make work correctly the Weact Studio 4,2 inch display. Now i need to try to avoid the full reset screen blinking 
Now i tryed the normal 4.20in-v2 with option display_mode: partial and now works good, no ghosting, perfect display no blinking…
mi code `display:
I see in the end you used the suggested ‘4.20in-v2’ model for the WeAct 4.2" BW display…glad partial refresh works. I’ll have to try it when I get my BW screen back out. I’m currently only using the BWR display because I need the red color for highlighting key information over just black text/icons.
I’ve just tried your setup with 4.20in-v2 and custom components - screen is empty. Need to go back to gdey042t81.