I also have got a e1001 yest some days ago. I got issues with the screen flashing several time on screen updates. I tried instead model: 7.50inv2p. This variant supports partial updates. It works perfectly. And at least my e1001 supports it. Just give it a try. It is worth it.
I have designed a frame with my 3D printer so that the screen (both the reterminal E1001 and E1002) fits perfectly into the Ikea Rodalm frame. You can download it from this link (and, by the way, see a small spoiler of the ‘comic dashboard’ I created with the E1002 ).
I just got an E1002. So far managed to get a photo onto it via SenseCraft, but haven’t been able to get ESPHome to connect/write to it. The E1002 seems to do a LOT of flashing/rendering to get the colors all working, which is kind of annoying. We’ll see how it goes once I get more details set up.
It does! It is supposed to need more time to load the image because of the colors, but it wasn’t enough for me to use full color images, until i found a workaround
Can someone help me with this problem with a Seeed e1001? It displays sensor values form HA, but after waking up it needs too much time to display them correctly. So the values stay empty or say ‘NA’.
To save energy I send the device to sleep fo 4.5 min and make it wake up for 30s.
As a remedy I update the display a second time during every wake cycle. But this is not optimal since the missing information is still displayed between the intervals.
Is there a way to not update the display unless the sensor data has been retrieved succesfully? Or do you see an even better solution?
Hi. I am also using this ePaper after a long journey trying whatever different things. I like, that they are “complete”, and you just can hang them on the wall. My project is to show calendar data to have it hanging on a room that can be “booked” for meetings.
The E1001 is deep-sleeping most of the time, but wakes up, depending on the schedule of the room and if someone presses the green button. Problem I have with the green button, that the start takes “too long”, due to the flickering problem. Can you share a piece of code here, to give me a kickstart to make the start less flickering.
thank you in advance
Juergen
Many thanks. I do have to improve my spanish knowledge which does not exist at the moment, but as computer language is quite internation, I think I will make it.
I’ve been tinkering with (my first experience) the help of an AI for several days now and almost completed my first setup. Learned something on the screen and maybe even more on the AI and it’s flaws. Because the weather and an agenda list that I show are relative static my auto-refresh is set to 1 hour and the green button is used to start a direct refresh if necessary. Anyway ‘we’ bumped into more or less the same problem and came to the following solution. An ‘automatic pause button’ will refuse the reTerminal to draw pixels until it has verified via the digital line that Home Assistant is live and has delivered all data correctly. Because of this, there should hopefully never be “clutter” or empty areas during startup.
What is the problem without this code?
When the reTerminal starts up or the power has been off for a moment, the chip wakes up lightning fast. It wants to start drawing the screen immediately. But at that very first moment, it does not yet have a Wi-Fi connection to Home Assistant. If the chip starts drawing blindly at that moment, the data is unavailable. Because it is an e-paper screen, that screen remains there until the next refresh. In my case an hour unless the green button was pressed…
By placing this simple gatekeeper logic at the very top of the display lambda, we force the reTerminal to wait. The code explicitly checks the API status (node_status) first. If it returns false, the render cycle aborts immediately (return;) without touching a single pixel. Only when Home Assistant sends the green light—meaning all template states and calendar strings are fully synchronized—is the display allowed to refresh. This completely eliminates messy layouts or empty fragments during system boot-ups."
// ====================================================================
// ESPHOME DISPLAY LAMBDA: AUTOMATED PAUSE BUTTON (BOOT PROTECTION)
// ====================================================================
lambda: |-
// 1. THE GATEKEEPER: Check if the connection to Home Assistant is active.
// We read the state of 'node_status' (this binary_sensor tracks the HA API connection).
bool api_connected = id(node_status).state;
if (!api_connected) {
// Connection not ready yet? Hit the pause button immediately!
// The 'return;' statement forces ESPHome to abort the drawing process right here.
// The e-paper screen stays untouched, preserving its previous clean state.
ESP_LOGD("display", "Boot protection active: Waiting for Home Assistant API...");
return;
}
// 2. GREEN LIGHT: The API is connected and all template/sensor data is ready!
// Only now is the computer allowed to trigger the display driver and render the layout.
it.fill(esphome::display::COLOR_OFF); // Drings a 100% hard hardware buffer clear first
// Your C++ drawing functions (teken_links, teken_rechts, etc.) follow below...
ESP_LOGI("display", "API connected! Render pipeline starting flawlessly.");