2025-07-06, 9 minutes reading for Electronic Hobbyist
TL;DR
This project started because I had a spare raspberry pi zero laying around, being a resourceful guy, I didn't want to leave it there. After seeing a few E-paper related projects, I decided to make a dashboard of my work calendar.
So I ordered the Inky Impression 7.3" 7-colour e-paper display(the 2024 edition), however after drawing my first image onto it, I realised that it took 30 seconds to full refresh, it didn't support partial refresh :(.
The refresh rate was not advertised on the website when I ordered it! this was a no go for me as the refreshing was too distracting 1.
So after a few months of sitting idle, I pivoted to creating a Weather Dashboard as a gift for my parents. I started by putting down my requirements
There are plenty of weather dashboard projects out there, almost all are black and white, none checked all boxes of my requirements, however the esp32 weather EPD stood out the most. Unfortunately, it was written in C++.
So I decided to write mine in Rust.
I started with what I thought would be the hardest part which was creating an SVG graph. Thankfully there was already a guide on how to create one.
The implementation can be found in charts.rs, it supports both Bezier curves and straight lines.
<!-- A Bezier curve with control points at (0,0) and (50,100), ending at (100,0) -->
<path d="
M 0 0
C 0 0 50 100 100 0
">
<!-- A simple line from point (5,5) to (15,15)-->
<path d="
M 5 5
L 15 15
">
There is a small problem though, given the y-axis bounds are dictated by the actual or feel like temperature, when interpolating the points, the curve might slightly overshoot outside the bounds axis bounds(top and bottom), I have yet to find an algorithm that is smooth and only overshoots in the x dimension.
The design took way too long, after going though several SVG icons packs, I settled for these beautiful icons by Bas. I overhauled the ones I used, so that the shapes and colours are fit for the display. This manual process was extremely time consuming.
The icon pack provides three types of icons, Fill, Line and Animated, the last one opens the option for using animated icons when high refresh rate E-paper displays become cheaper and more colour rich.
When display saturation is set to 1.0, the display supports the following colours without any dithering:
[0, 0, 0], // Black
[255, 255, 255], // White
[0, 255, 0], // Green
[0, 0, 255], // Blue
[255, 0, 0], // Red
[255, 255, 0], // Yellow
[255, 140, 0], // Orange
As of writing the Waveshare EPD offers a full colour version! Just like LED display, they can show every colour by mixing multiple colours to form a solid colour when seen from a distance. See this video that explains the colours on a microcapsules level.
When an image contains a colour that is not supported natively, the Inky image generation script reverts to Dithering using pillow python library
I have intentionally chosen gradients in some of the icons to force dithering, such as portraying heavy clouds.
This one required a bit of learning, I used an existing 3D frame for a different model as my base and adjusted it using Blender software to my EPD dimensions and features, I then printed the 3D frame at a local library makerspace using a 2mm nozzle.
The STL files and How to Assemble are on my Inky impression 7-3-colour case repository.
I expected the handwriting fonts to look good on such display, however after going through a dozen, I settled on trusty plain Regular-Roboto.
However, given that I use Green and Red in the graph, these colours are hard to distinguish for colour-blind people, so I needed to differntiate them. I created my own Dashed Roboto font using Font Forge software for the digit charachters only, since no such font existed before.
The design took the longest and I iterated several times, before I was satisfied2. For example, I attempted to use icons over words like "Now" and "Max", however
I wanted the dashboard to be look beautiful without much clutter.
So far I have not explained what some of the shapes/elements represent, and this is intentional, because I chose not to follow Human Centric Design.
“Human-centred design is a creative approach to interactive systems development that aims to make systems usable and useful by focusing on the users, designing around their needs and requirements at all stages, and by applying human factors/ergonomics, usability knowledge, and techniques. This approach enhances effectiveness and efficiency, improves human well-being, user satisfaction, accessibility and sustainability; and counteracts possible adverse effects of use on human health, safety and performance.” [ISO 9241-210:2010(E)].
Conveying the meaning of these shapes on the display without adding a legend or words is quite challenging.
--- You are now entering a Roast-Friendly Area ---
So folks, I introduce:
“The goal of Human Guessing Design is to produce software products that pragmatically use space instead of adding clutter, it does so by strategically concealing the legend within other elements. The high priority elements act as clues or building blocks steer the user in the direction of understanding the meaning of other more lower priority elements. This process is carried from the very beginning of the development process. The moto is The legend is in the details”3/
I think this sort of design is similar to how video game first introduce a new mechanic to the player(usually in a tutorial).The first encounter of said mechanism includes many clues, and the number of clues in subsequent encounters follow an exponential decay curve.
Note, this is different from Bad Design, bad design doesn't take users into account. An example of bad design is in IOS where you have to shake your phone to undo keyboard entered text, seriously who thought this was a good idea when typing on your phone!
--- You are now leaving the Roast-Friendly Area ---
Given this image:
A gif can be found in the main repo.
Version 1: very minimal
So what the client actually meant to say, the font is too small
So what the client meant to say, the values had no unit. I guess I can't assume the degree symbol ° refers to local temperature unit
Version 2: close to final
Here I realised that I should have picked a different time to seek feedback
The Final Dashboard is an SVG file, which then gets rendered onto PNG. Overall, I'm very happy with it :)
The 2025 edition takes 12 seconds to refresh↩
The table graph lines are intentionally not straight to serve a reminder for me to stop refining, or you can think of it as the artist touch↩
ISO 9241-666:2025(E)↩