This is Part 2 of a series in progress about building a dashboard application for my solar panels

I love being a backend engineer. I made the switch from a front-end developer position to a back-end developer working on analytics and reporting back in January 2020. I discovered that data is my jam. I love working with large data sets, figuring out how to efficiently move them around and represent them in ways they can be efficiently turned into data that we mere mortals can process.

No more having to worry about the quirks of web browsers!

Solar Dashboard UI - Mistakes Were Made

Working on backend APIs also means that the kind of hardware that I expect my code to be running on will have serious horsepower behind it. My code will be running on servers with high CPU clock speeds and multiple cores with several Gigabytes of memory to use as I please.

This was my problem with my first attempt at creating something to run on my raspberry pi.

Back in Part 1, I described how I wanted to build a dashboard that would show me real-time data from my solar panels as reported by the inverter connected to them. I built a web-based UI that looked good and would be cross-platform so I could write it on one system, and deploy it easily on the Pi.

Yeah…. about that. My particular model of Raspberry Pi is the Raspberry Pi 2 Model B+. NOT a Pi 3 like I thought it was.

It turns out that the model of Pi I actually have has a CPU that clocks in a whole 500 MHz slower than I thought. Somehow, I also thought I had more RAM than I actually did - only 1GB.

Have you ever tried running a modern browser on less than 1GB of ram? It doesn’t work.

Needless to say, It was time to go back to the drawing board.

Research isn’t always exciting

I’ve gone back and forth about whether I actually wanted to write this article - who cares about the research process besides the person doing it? I’ve been pondering this problem with my low-spec Pi for a couple of months now, and have been researching what options I have available to me to make something that would work on such a little computer that would still allow me to develop on a more powerful system than just the Pi itself.

Spoiler alert - I’ve decided on my next move for the project, but rather than just giving a quick paragraph of “I decided to use this thing” as if I knew what I was going to do all along, I thought I’d show a little humanity about how I had no idea what I was going to do going forward.

In our world of TikTok, youtube shorts, time-lapse photography, and montages, we’re just not used to the time it actually takes to learn or build something. If I had to guess, it’s probably because watching somebody do research would be really boring. Watching a carpenter sand a beautiful piece of wood would get boring really fast. (I do some woodworking on the side for fun, and even being the one doing the sanding gets boring!)

That said, the learning process is often times more important than even the final product. As it says in one of my favorite fantasy novels: “Journey before Destination” (The Stormlight Archives Series, Brandon Sanderson). It’s in learning how to do something that we grow the most.

With that in mind, I’ve decided that I would write some of my reasoning and learning that I’ve obtained over the last couple of months, in the hopes that I can show you that the learning process really isn’t all that bad. In fact, it makes the end result much more fulfilling.

We care more about interfaces than the underlying code

I mentioned in Part 1 that I had found an open-source library I could use to talk to my inverter written in Python. I got that working with my inverter, so no need to worry about much there. So why didn’t I write the UI with Python?

Because the default user interface builder (Tkinter) associated with Python makes ugly interfaces. I don’t have an interface put together (because I didn’t want to make one), so here’s a sample pulled from a StackOverflow question:

Gross.

Nothing against the developer who made this, but this just lacks the look and polish we have become so used to. I realize that it’s probably somewhat vain of me to worry about what it looks like, but if I’m supposed to be a good developer, then the things that I create ought to look good shouldn’t they?

And it’s not just me. Out of curiosity, I asked my wife this question which I now pose to you, good reader:

If you had two different apps on your phone that did the exact same thing, right down to the code, but one of them has nifty animations, and just looked nicer, which would you want to use?

My wife said she would use the one that looked nicer. I agree with her.

What if the one that looked nicer didn’t do everything that the ugly one did? Would you still want to use the nice one over the ugly one?

She said yes. I agree with her again.

As much as we would like to deny it, the way something looks and feels makes a huge impact on whether we want to use it or not - usefulness aside. Why do you think Apple puts so much effort into the aesthetics of their devices? Because having something that looks and feels amazing makes can make a huge difference to the perceived quality of the thing.

Before anyone assumes I’m an Apple fanboy, you should know that I have a custom-built home PC, an Android Phone, an iPad Pro, and a Linux server running in my home. Sometimes I’ll write something up about being technologically agnostic.

I needed to find a way to either use something besides Python for the UI or find a way to make a Python interface not look like garbage.

The Research Begins

Something I’ve used in the past is a framework called Electron. Electron is pretty amazing - using web technologies, you can build cross-platform desktop applications. You are probably already using some now. Visual Studio Code? Built with Electron.

Discord? Electron.

Slack? Electron.

Dropbox? Trello? Twitch? MS Teams? Notion? All are built with Electron.

Electron

Normally, if you want to create an application for something like Windows or macOS, you need to write two completely different applications. Sure, they have the same name and do the same things, but to function on two different computers with two different operating systems, you are going to have to write two different user interfaces because the way that UIs and programs work on different operating systems are completely different. This is why you cannot run a .exe file on macOS, or a .dmg file on Windows. The different operating systems have no idea what to do with these programs because they aren’t built for that system.

What Electron does is leverage the power of a web browser. Electron internally has all the code needed to interact with each operating system. It packages a Chromium browser (what Google Chrome is based on) and displays that instead, so your application interface runs as a web application.

It’s a bit more complicated than that, but what this allows you to do is write a single application, and deploy it on as many different platforms as you want - Windows, macOS, or in my case, Raspberry Pi.

There is a catch though, and from my experience, it’s the main reason why so many users hate Electron applications.

It runs a web browser. Not just any browser, but Chromium, whose memory usage is basically a meme at this point.

Remember what I said about the specs of my Raspberry Pi? Electron just isn’t going to work. Since I had already created a web interface for my dashboard, integrating it with Electron would have been perfect - I would just need to port the Python code to talk to my inverter to TypeScript, and Bam! All done.

Except my Pi doesn’t even remotely have the power to run a heavy Electron-based application.

Hope for Python

Since I couldn’t use Electron, I turned my attention back to Python. Python has been around for a long time and has recently become very popular. Surely somebody has created a library or a semi-simple way to create a user interface that doesn’t look like it’s straight out of the 90s?

After a lot of searching, I found a YouTube video that detailed what appeared to be a spin on the default tkinter library in Python (the one that I thought looked like trash). In it, the developer introduces “CustomerTkinter”. After looking at a couple of screenshots, I was convinced.

Now this, I can work with.

I know a little bit about Tkinter having done a few projects back in academia with it. It turns out that CustomTkinter is very similar - the only difference is just what some of the class names and functions are.

If I can use this library to create an attractive interface, then I don’t have to worry about porting the library I already figured out to talk to my solar inverter with - the entire dashboard can just be a python program - which the Raspberry Pi does great with.

Next Steps

With all of this in hand, it’s time for me to start getting familiar with CustomTkinter and what it can do. This is going to take some more time, but seeing what I can potentially make with a native python library without having to worry about different coding or tools to make the inverter work smoothly with the interface is exciting.

Stay tuned for the next part - hopefully, the creation of the dashboard application!