Lately I'm been pinning for new and exciting things to build. When I came across PiHut's case for the Raspberry Pi Zero and Waveshare Epaper Display, I quickly snapped it up, knowing I could put it to use - at the very least I would have my own eink display, which is a technology I am very keen on.
sidenote: I will be using eink and epaper interchangeably in this post. "E Ink" is a trademarked term but is typically used in a more generic form of "eink".
Having never done much, if anything, with the Raspberry Pi's hardware and "hat" capabilities, the first step was figuring out how the two interacted. Thankfully, Waveshare has a repository containing examples in both C and Python, the latter being the languages I opted for due to my familiarity. Setup is relatively straightforward, requiring one or two libraries fetched via apt-get followed by a git clone of the repository.
Hold on though! The Pi Zero I have on hand does not have WiFi! How does one connect it to the internet? It's relatively straightforward, truth be told, when using Windows or macOS (Linux is another story, but we'll get to that). The Pi Zero (I am unsure if this extends to the full fat Pi) has a "gadget mode", wherein it can appear as a network adapter and allow your computer to connect over this. From there you can share your actual internet connection with it. Adafruit has a nifty little guide here.
With the internet connection sorted and the repository cloned and tested, it was time to create a minimal viable product. This was more or less taking the example code and extracting the valuable bits, giving it a smaller footprint and easier to navigate layout. This simpler version has been tagged for your viewing pleasure.
One interesting note about this particular display is that the Python library draws on the display upside down. Why, I am not particularly sure, but it's a relatively easy thing to compensate for until I can figure out the root cause. This is why in the code the image is flipped at the end!
This ran fine, but a few days after I made the leap to Linux full time (again) and left my Windows install behind. I was under the impression that sharing the connection would be just as straightforward, but it turned out it was a bit more complex than that (it's entirely possible I was trying to rush through it and missed a critical piece) and I quickly gave up after many failed attempts to configure the necessary rules. Without this internet connection, the Pi was unable to sync the date and time, which was a small issue for a device showing the time. Since my desktop and Pi did, however, have a solid network connection, I figured I may as well leverage it to the best of my ability, and set out to rework the script in a more traditional webserver/client configuration, with my desktop generating the image. This has the added advantage of lessening the work the Pi itself has to do, hopefully lengthening the lifespan of it or the eink display.
There's nothing particular to note about the new codebase, beyond the minimal dependencies and routing system that I borrowed from a previous project, which looks for properly named files and functions in the lib/ directory before returning the 404. It was especially important to keep dependencies on the Pi-side minimal since the lack of internet connection would require me to manually fetch them and sftp them up. This lack of connection also constrained me to Python 2, since the dependencies I had previously installed were done under that version. To combat the largest issue regarding the time and date of the Pi, I ran a small snippet over SSH that synced the time with my desktop's with a small offset to account for lag, and hope to integrate this sync directly into the script. While this single snippet could have solved the lack of internet problem without needing to rewrite the application, I think it was a worthwhile time investment for future expansion.
update: since this post, I have set up an ntp server local to my desktop to sync the Pi with, so a lot of the problems regarding time being out of sync are solved for good! This sort of invalidates part of the need for the client <-> server, but oh well.
Overall, I'm very happy with the end product, especially with the new client/server structure. It will allow me to do some more complex things without worrying about bogging down the smaller CPU. The clock can lag behind by a few seconds, but that's not a deal breaker in my case. Porting the client to another Waveshare eink display should be as easy as switching out the display library and adjusting the parameters in the script, and I hope to obtain a larger display in the future to have more real estate for information.
What would you do with such a device connected to your computer? What information would you find useful? I'd love to gain some more inspiration for this!
Top comments (0)