Raspberry PI Automation and Wifi Configuration Project

Discussion Raspberry Pi
1

I am thinking to develop some custom FOSS for the Raspberry PI. I’d want it to be re-usable for other people, not just made for myself. I am thinking the project would be based on assuming the user has the following kit:

  • Raspberry Pi 5 (8GB) - ~$80
  • Pimoroni Pirate Audio: Line-out - ~$25-30: High-quality I2S DAC with 24-bit/192KHz audio, 240x240 display, 4 control buttons
  • Pibow Coupe 5 Case - ~$15-20: Slim, hackable case designed for Pi 5 with Active Cooler compatibility
  • Booster Header (40-pin) - ~$3-5: Needed to “lift your Pirate Audio board up a little” to work with the Pibow Coupe case Raspberry Pi 5 - Pimoroni
  • Raspberry Pi 5 Official Active Cooler - ~$5-8: The case is “designed to fit neatly around Raspberry Pi’s new Active Cooler”
  • Raspberry Pi 5 Official Power Supply (27W USB-C) - ~$12-15

Total Estimated Budget: ~$140-165

The way I started was out of frustration with design decisions in the Zynthian project where my use case really didn’t align with theirs. Eventually, I’d like to build a USB MIDI router which can also do some virtual instruments but the MIDI routing is really the main feature and not something Zynthian adequately supported. But then, as I got deeper into how I’d approach the USB MIDI router issue, I realized there’s actually a more fundamental problem my project should actually solve first which is more widely applicable than just for musicians.

There’s a “Chicken and Egg” issue that occurs when you’re trying to get one of these SBCs to start working for you at a gig as a musical performer – or using it for gaming at a friend’s house or on vacation or whatever. You don’t want to have to bring a full monitor and keyboard with you but unless you do, you can’t set up the wifi or even safely shut down the damn thing. That’s actually the first problem my device would need to solve, and then any additional functionality, like MIDI routing, could be configured later on.

The plan is first that the device would run Raspberry PI OS Lite. I’d make a C# Blazor Server web app which also has Avalonia UI as a service. The Avalonia UI would render to a framebuffer on the Linux system that would show on the physical display and would also be capable of sending frames as PNG to an HTML5 canvas in the web app via SignalR to make a “digital twin” of the physical display which would also have the four buttons clickable in the web interface to make a sort of “remote desktop” experience for the pirate audio display. That way, anything that could be configured on the physical device could also be configured on the web interface despite the reverse not being true. (the rest of the web interface would be dedicated to handling configuration that couldn’t work on the tiny screen and just four buttons)

So, if you’re at a new location and you want to connect the device to that location’s wifi, you could tell it to scan for wifi networks by using the physical display and buttons and it would record available networks to a text file. Then, you’d tell it to go into Access Point mode. It would show the wifi network it is providing, that network’s password and its IP address on the screen so that you could connect with a phone or tablet to the web interface. On the web interface, you could give it the necessary credentials to connect to local wifi and get connected. Or at least, that’s the plan.

Other options should include just sticking with Access Point mode or even just Ethernet where available. A further plan would be for additional software to be configurable via the web interface and then different software configuration states to be saveable in the web interface and loadable from the physical screen and buttons. But that’s a more long term goal after the initial wifi problem is solved. I think that could be the start of a powerful platform for automation if I could make it work.

My question would be: is this feasible? Is the hardware capable of supporting such a scheme? Am I re-inventing a wheel anyone else has already made? Are there any existing tools I should be utilizing instead of building any parts of this myself? Am I just spinning my wheels or am I making something there would be significant community interest in as a tool?

What should I even call this thing?

2

Yes, this is feasible, but you will find that it takes a lot of effort. And there are many parts that are already available out of the box (Linux is very powerful):

  • NetworkManager will support you for all the wifi stuff
  • configuration as read-only system will let you “shutdown” by just turning the system off
  • …

I have written a project (GitHub - bablokb/pi-webradio: An Internet-Radio built around a Waveshare 7.9" Display) that also uses a local screen in addition to a web-interface. My local GUI is also just a browser and I use SSE to synchronize state. In fact it also supports the Pirate-Audio: the buttons just use REST-calls to the web-server.

Regarding the hardware: I think the 8GB is absolutely oversized. The 2GB version should be fine.

3

Where the additional RAM might become relevant would be if I started using it as a music synthesizer.

I think your solution of the buttons doing REST calls to the web server is probably superior to my plan. I might be able to study your solution as a starting point so thanks.

4

The Pi 5 has an on / off button. Which should work even without a monitor. One click will have it boot up, and two clicks to shut down properly. The Pibow Coupe Case is configured to use the Pi 5’s onboard button.

5

You should test it. Set up your system, start the programs that should run, and then check with free -h.

Even a full-fledged desktop doesn’t use 25% of the RAM of a 2GB system, a lite system less than 10%. So there is a lot of free RAM for application programs. Users tend to overestimate the RAM they really need.

In the end, it is a matter of price-efficiency. More RAM does not hurt, but for a system with a dedicated use-case it also does not make sense to spend money on something that isn’t needed/used.

6

I wasn’t aware of this. The most recent models I’ve purchased were the 4B and 400 models so far as I can recall. If that is the case, then safe shutdown can definitely be implemented to work with the physical power button.

I’m still not sure exactly what software to use to render to the physical screen. I’d want it to be able to do that “digital twin” thing I had described so that the web interface can control it. I’d like to avoid creating my own system of GUI widgets if I could just use something that already exists. I’d want it to not use too many system resources and I’m also strongly inclined for it to use C# because that’s what I have most experience with, ideally so that it could be a service that runs as part of a Blazor Server project. Beyond those requirements, I’m not sure whether Avalonia was the best choice or if it should be something web browser based or what exactly. I’m also not sure whether sending PNG to the web app is the right way or if it should instead use WebRTC or something else. I’m still researching this whole thing trying to come up with a plan of how it would work.

The RAM would place a hard limit on the size of some virtual instruments, which can actually be pretty big in some cases, like there are some giant SFZ files that can be multiple gigabytes in size. I think having the 8 GB RAM model would make sense for such a use case but obviously not for everyone’s.

If a NetworkManager GUI specifically for embedded screens like the Pirate Audio’s already exists then maybe I should consider using that instead of writing my own, although I doubt anyone has worked out a way to input the wifi password on a screen with only four buttons so I doubt anything like this already exists. However, I definitely don’t want to reinvent the wheel where I don’t have to so I’d appreciate anyone pointing out any pre-existing options I might not be aware of. A big part of the point of this is making both my current and future projects as easy as possible.

I appreciate everyone sharing their ideas and suggestions.

7

What do you want to render to this screen? It is only 240x240, so there is not much you can put on it. Basically it is a ST7789, so you can use any software that has a suitable driver for it. The Pimoroni stuff uses PIL, the Python Image Library. They render on an image the same size and then just put the image on the screen. But there are other alternatives.

Beware it is not a OS-level display, so you cannot just use any software to do that.

8

Initially, just a simple menu to allow for configuring the wifi and other basic menu-driven functions. I thought I had described that in the initial post.

Later on, it would be nice to add things like a volume indicator or CPU graph or other such graphical feedback but for the initial proof of concept, just static UI elements should be fine.

9

Have a look at this repo: GitHub - BurAndBY/fbcp-st7789vw: A blazing fast display driver for SPI-based LCD displays for Raspberry Pi A, B, 2, 3, 4 and Zero It seems it supports also the Pirate-Audio displays. This is a basic OS-level display driver, so once this is actually working, you are free to choose your GUI-widget programming environment.

I am not sure if this really helps, because normal widget-libraries don’t have those very small screens in mind.

10

I think I noted before that there really isn’t much to change in the existing ST7735 driver in the kernel to get it to work with the ST7789, but the provision of drivers for these MIPI DBI displays should really be made more generic, perhaps even relocating the setup operations and panel configuration to the device tree or to some non-compiled file instead.

For some reason, the existing Sitronix drivers have been moved out of the tiny section of the appropriate drivers directory, meaning that when I get to update my own changes, I’ll be chasing the appropriate file around. However, it is just a matter of disabling the gamma adjustments that someone obviously needed (or thought they needed) for the ST7735, along with providing a panel configuration that can be activated on a device tree match.

The only setup operation I use with the ST7789 in the Pirate Audio Speaker board is to invert the display, which should be a generic operation controlled via the device tree. I’d even provide my patch here if I could attach it because quoting it might make the post a bit long.