E-Ink Dashboard

The impetus

I’ve always liked E-Ink displays; honestly, I think everyone does. They strike the perfect balance between analog and digital, like VFDs and Nixie Tubes. To that end, I’ve always wanted an E-Ink Dashboard to greet me on my desk, telling me the time, the weather, and other important information. At some point, I found a video on YouTube by David Zhang called “The E-ink Desk Accessory I’ve Always Wanted.” He used the old version of a device called the LilyGo T5-4.7, an all-in-one 4.7” inch E-Ink display with battery circuitry and an ESP32 with Wi-Fi, a pretty good package.

David Zhang used ESPHome alongside a Home Assistant server to send the dashboard the image to display. This setup is really nice and common, as it treats the LilyGo as a dumb terminal while a more capable computer handles the overhead. While I found his video intriguing, it wouldn’t work for me; while I have a Homelab (that does run Home Assistant), the overhead and hassle of ESPHome didn’t seem worth the result. Furthermore, while I am in Madison for school, I don’t have local area access to that server. The ESP32 in the LilyGo is a fairly capable processor, so I figured I could write some client code for the display, and run a light server on my PC to send over data to the display.

Getting Started

The first step was ordering the LilyGo T5. Once I got it, I was pretty pleased with the product I received. It came with the backplane which holds the ESP32, GPIO pins, the Wi-Fi chipset, and a JST connector for a Li-Po battery, and even more! I downloaded the example code from the LilyGo GitHub and began poking. This was actually my first time using PlatformIO and it was a fantastic experience. You configure the device and its build settings in a configuration file and it handles the rest for you.

My first goal was to write strings of text to the display. Luckily, the E-Paper Display comes with a library to handle writing strings. The way it works is also rather interesting. It relies on bitmapped fonts. Basically, you take a pre-existing font and convert each character into an image. Then, to write a string, you use each character in the string as an index in a look-up table where the value corresponds to that character’s corresponding letter. From there, you paste each letter’s image in sequence to write a string on the display. Bitmapped fonts are nice because they are simple. There is no font overhead; the same routines used for drawing images are reused for writing text. The downside is that this is memory intensive and not scalable. Since each character is an image, all of the characters need to be stored as full PNGs in RAM. Furthermore, since the font is just a sequence of images, for every single font size we want to use, we need to generate new bitmaps for these different sizes.

Getting Hardware Information

This was the part of the project I assumed would be easy. My goal was to run a light server to send data to the display, either over IP or USB. On Linux, most of the information I wanted, RAM usage, CPU/GPU usage, temperature, and watt, is easily accessible via the /sys/class/thermal virtual file system. Past that, there are packages, such as sensor that could pull that information which could then be forwarded to a flask format in a nice format, like a JSON. From there, the client could pull the data from the server, extract the desired strings and print them out.

However, when it comes Windows, it is a different story entirely. You have to use special applications that grab this information from system drivers and publish it, such as HWMonitor and CoreTemp. For my purposes, I decided to try and use Open Hardware Monitor. It publishes all the information it gets to the Windows Management Instrumentation (a giant bus for data sharing between windows apps).

With all of the parts set, its time to put them together. The idea is to use the python library WMI to grab the data and present it via a Flask server a nicely formatted JSON