Digikey Parts

• LD1117V33 3.3V 800mA Linear Voltage Regulator - $0.55 - stepping down from 5V to 3.3V for the OLED and the thermocouple modules.
• 3x 0.1uF Ceramic Capacitor - $0.23 each - power filtering.
• 2x 10uF Electrolytic Capacitor - $0.27 each - power filtering.
• 2x 4.7K Resistor 1/8W - $0.10 each - for SPI.
• 2 Pin Screw Terminal - $1.26 each - for connecting the thermocouple to the board.
• 16 pin socket - $1.02 - micro controller socket.
• 12 pin socket - $1.82 - micro controller socket.
• 2x 4 pin socket - $0.47 each - socket for the thermocouple amplifier and OLED. Long term, it would be best to solder both components for stability.

Total = $104.60 + shipping + pcb cost

My project cost total 147.60 with shipping and pcb costs. this included double the parts from digikey (for a planned second PCB that was not made).

All of the devices I chose support 3.3V logic. All power will be supplied by the USB adapter. This is not ideal, but this is the only realistic option on the HUZZAH32. The LD1117V33 will be used to power the OLED and the thermocouple modules.

Ideation & Layout

Before starting on any software implementation for my OLED user interface I went through a design ideation process with pen and paper to create an intuitive user design. I first (first photo, first page) made a list of requirements. This included controls and indicators I needed to have on the display. I also drew the physical environment which my user would be using the board to set my mind in the correct space.

Next (first photo, second page), I explored desired functionality and some initial possible interface options. I thought about how the user might see and interact with information.

Finally (last two pages), I explored two possible designs for the OLED. The first design was a slider layout where the up and down buttons changed the screen and the middle button selected the option on the screen. The second design was a single panel layout. In this version, the up and down buttons selected the line and the middle button was an enter/select button.

I decided to move forward with the single panel layout as it made better use of the space on the OLED screen and was less complicated to use. It consisted of only two pages for the user to learn. This mindset of simplicity is also why I chose to not have any sort of heating profiles in the end. I found my final iteration of just one target temperature option on the display made the device much more usable.

Process

Unlike when working on the OLED interface, I was less focused on reaching a specific interface design. I was more focused on reaching basic functionality.

The first part of my process was identifying my key challenges. I made four key steps for myself:

1. Connecting to WiFi
2. Hosting a web page
3. Sending data to webpage that changed (not "static")
4. Receive data from web page from user

I found it quite easy to connect to WiFi. The microcontroller I picked, thanks to its IoT support, has a wonderful WiFi implementation from the espressif package listed in the github. Connecting to WiFi is as simple as: include the library, set the mode you want to connect (basically, are you a client, a router, or both?), and run the begin statement with connection info:

                    
                      #include <WiFi.h>
                      WiFi.mode(WIFI_STA);
                      WiFi.begin(ssid, password);
                    
                  

The next few steps were the harder ones. There are many packages for hosting a website on the ESP32, and most of them support sending and receiving data. However, many of them require continually relooping through the HTML code and printing it to the website. This has a high performance overhead, is difficult to functionize and organize, and makes it hard to perform other more complicated functions with the microcontroller - which I needed to do. In the end, I ended up using the ESPAsyncWebServer library.

This was by far the most complicated and most full featured library I tested. It is a bit tricky to get installed and going. However, the library comes with plent of documentation and I was able to implement full featured web based interface to pass on my data. More of my code for this package in the next section.

Key Code Snippets

For my final implementation of the web UI, I used ESPAsyncWebServer for my interface and for handling data. The built-in espressif WiFi library was used for connectivity.

Before starting the web server, all constants and variables are defined. This includes the wifi connection info and the port of the server. But it also includes the page information:

• HTML with variables that will be connected to the code
• A C function to connect the HTML variables with the C variables, converting them to strings. More information below.
• Heat slider code
• A simple yes/no function to control the button slider based on the heating value
• Bare bones 404 page

Code to connect HTML with C variables:

                    
                      String processor(const String& var){
                        //Serial.println(var);
                        if(var == "CURR_TEMP"){
                          // current temp status
                          return String(currentTemp);
                        }
                        else if(var == "TARG_TEMP"){
                          // target temp status
                          return String(targetTemp);
                        }
                        else if(var == "NEW_TARGET"){
                          // new target value in input field
                          return String(targetTemp);
                        }
                        else if(var == "HEAT_SLIDER"){
                          String buttons = "";
                          // replace button placeholder
                          buttons += (BUTTON HTML)
                          return buttons;
                        }
                        return String();
                      }
                    
                  

The var values are the variables coming from the page HTML. The return values are strings of values in the C environment on the HUZZAH32. The first two if statements are setting the values for the temperature status indicators: for current temperature and target temperature respectively. The third value is the new target field which is by default populated with the last target temp.

The last else if in this function is for the heater control slider. This replaces a place holder in the HTML code with a live button. I removed the button HTML code for simplicity in this example, but here it is isolated:

                    
                      else if(var == "HEAT_SLIDER"){
                        String buttons = "";
                        buttons +=
                        "<h3>Heating:</h3>
                        <label class="switch">
                        <input type="checkbox"
                        onchange="toggleCheckbox(this)"
                        id="2" " + outputState() + ">
                        <span class="slider"></span></label>";
                        return buttons;
                      }
                    
                  

This code is a modified version of Rui Santos's work, who has written many guides on the ESP32. This snippet creates an HTML button element. The most important items here for later for our are the sections after "onchange". The toggleCheckbox references a javascript portion embedded in the original code which sends a signal that something has been updated and changes a state. This is important because otherwise there is no way of knowing an event occured.

The outputState runs a C function to match the button with the local variable:

                    
                      String outputState(){
                        if(heating){
                          return "checked";
                        }
                        else {
                          return "";
                        }
                      }
                    
                  

The final key snippet of code I am going to put is the server initializing function which contains the monitoring code for updates, as mentioned earlier. Here is the monitoring code, once again huge thanks to Rui Santos:

                    
                      server.on("/update", HTTP_GET, [] (AsyncWebServerRequest *request) {
                        if (request->hasParam(PARAM_INPUT_1)) {
                          // if target temp change
                          targetTemp = (request->getParam(PARAM_INPUT_1)->value()).toInt();
                        }
                        else if (request->hasParam(PARAM_INPUT_2)) {
                          // if heating status change
                          int input = (request->getParam(PARAM_INPUT_2)->value()).toInt();
                          if (input == 1){
                            heating = true;
                          }
                          else {
                            heating = false;
                          }
                        }
                      });
                    }
                  
                

When there is an update signal sent by one of the two inputs, this part of the code will run (hence the server.on ... "/update"). The first if statement checks PARAM_INPUT_1 which is a pointer to the target temperature input. Thus if the update contains that param, it is a temperature input and that value is updated.

Alternatively, if the value contains PARAM_INPUT_2, it corresponds to a state change in heating. PARAM_INPUT_2 is a pointer to the state value of the button. So when that value changes on an update, the heating value is changed as well.