Damien Boisvert

Note: All code will be available on my GitHub if you want to check it out.

Do It Better!

My favorite things are programming, starting a new project, and a good meal. So it comes off as no surprise that when I had the option to continue with my original plan for the Robot Art Show project, that is, take it to 11 and make something original and, I’ll be the first to admit it, overcomplicated. (yes, I said it. big shocker.)

My Options

I started with an idea so outrageously complex that, looking back, I’m glad that I jumped ship before I spent too much time working on a project that I could not finish within the allotted time frame. That project was Flappy Bird, running on 3 separate Arduino boards, each controlling its LCD. I planned to have one master node controlling 3 worker nodes. It only occurred to me how long this would take when I was in the middle of writing the protocol that the boards use to communicate with each other, synchronized via the master’s heartbeat on pin 2. (I learned a LOT from those couple of days so I might write a blog post about it. It was super interesting! The link will be here if I get around to writing it.)

I then jumped to making an Arduino morse-code translator, got it working the same day, and realized that I didn’t learn anything from doing that. Sure, I read almost the entire documentation for the Arduino INPUT_PULLUP input mode, but I just didn’t feel satisfied with my work. It just felt like I was not challenging myself. Sure, I didn’t just copy and paste code to play “Happy Birthday” using one of those old buzzers you might still have on your PC to communicate POST error codes during boot.

I then went home and noticed on my desk, a NodeMCU microcontroller. A NodeMCU is an Arduino-compatible board (NOT an Arduino), that is essentially a Wi-Fi system on a chip, so is meant for doing things that involve Wi-Fi, like being a sensor for your automatic heater (This was a project that me and my father did a while back called Thermopi using a Raspberry Pi and NodeMCU microcontrollers), and thought… “Why not make a NodeMCU host a website of some sort?”… So I did.

The Process

I got started writing the software (Luckily, I had a lot of leftover code from a previous project to convert HTML (*.html) files to C++ Header (*.h) files, which was a lifesaver for uploading my web pages to the board. (Now, I don’t have to worry about escape sequences each time I use a quotation mark. Saves me a lot of trouble). This was a quick and simple Python script I made.

I had a rough prototype, and I noticed a problem that could single-handedly kill this entire project. You might think I am being dramatic or joking, but what if I told you… YOU CAN’T EVEN ACCESS THE WEBSITE AT SCHOOL!

The Pains of the NUSD-STAFF Wi-Fi Network.

For those of you who do not know basic networking like IP addresses, I’ll get you up to speed:

NUSD-STAFF has some odd functionality where devices cannot talk to other devices using their IP addresses. This means that, while the NodeMCU board can connect to the network fine, no one can access the website on it. I then did the only logical thing and made my own Wi-Fi network on the board. (yes you can do that, I will spare the details)

So I have a Wi-Fi network that can present the website, by visiting http://192.168.4.1 in your favorite web browser, but then my stupid ADHD kicked in and then I started learning about Captive Portals (those Wi-Fi sign-in screens), with the idea of using a Captive Portal to display my web application so you don’t even have to open your web browser. Just hit the little notification that says “Sign in to DAMIEN_STEM_PROJECT”, and you’ll be greeted by NOT an actual sign-in screen (that would be pointless in this case), but my website to turn on and off the LEDs that are plugged into the board. I didn’t spend MUCH time learning about captive portals but here’s the gist of how it works:

Your device tries to load a web page at http://connectivitycheck.gstatic.com/generate_204, expecting the response to be a simple webpage saying “OK”, but the board sets all domains to point to itself, so it does not get its “OK” response, rather, an entirely different webpage. This triggers your device to know that something is up, and you should probably sign in to the Wi-Fi network (as this is what Captive Portals are usually used for), but in this case, it just sends you to my website! No IP addresses are required! (although http://192.168.4.1/ still works.)

The WebApp itself

The website provides you with a real-time view of all the LED’s statuses (ON, OFF, etc.), using a JavaScript framework called HTMX. (NO, HTML and HTMX are ENTIRELY DIFFERENT things.) HTMX allows me to tell your browser to pull the most recent data for all LEDs, without you having to refresh the page. (If you know backend web development, you know how big this is) Press the button saying “ON” or “OFF”, and it will send a message to the board saying “Toggle this LED to be on or off” /led/1/toggle in the API. The board just responds with “OK!” because… I needed a response, OK? Also, this shows the HTTP code as well, “200 OK”, or “404 Not Found” (you might have heard of the latter a lot)

Conclusion

So there you have it, a board that hosts its wifi network presents a website via the WI-FI LOGIN SCREEN and works. Looking back, I can see a LOT of poor decisions being made, such as not using my phone’s hotspot as a wifi network (although that might have been for the better, as I might have multiple people using it), and also I might clean up the code because it is a MESS! (also sorry SMHS if you noticed an unknown wifi network!)

Cheers,

Damien