Testing Framework

As we start to develop our system across multiple environments (embedded and server), you may find it relatively easy to debug on the embedded side using the Serial monitor, but how could we debug our code on the server?

Since the majority of the code that we put on the server is intended to ultimately interact with HTTP requests, it would be really nice if we could somehow easily test fire GET and POST responses to our code and see how it acts.

There are online ways of doing this. For example, Google has a few, but you have to click on images of road signs and stores to make them work and that grows old fast.

For 6.900 we're going to strongly recommend you install PostMan. We as staff have no financial interest in Postman, but we've found from past classes that it works well in that it is both robust and relatively easy to use (and it has a GUI). If there's another piece of software that you like using for this (that isn't Google's sign-clicking thing), feel free to use it! We just want you to be able to debug server code easily!

Once installed, I can go into Postman and start sending GET and POST requests with ease! (This is much nicer than using your ESP32 to debug.)

On the right side, you can also see the RAW HTTP request as it was sent up by pressing the "Code" button! This can be really helpful when trying to figure out why a POST or GET from the ESP32 isn't going through, but you can get it working in PostMan.

GETs and POSTs

If you've taken 6.08 before we spend quite a bit of time obsessing over GET and POST requests. If you didn't take 6.08 that's fine too, but for reference I'm going to include this slide deck from 6.08 since I don't feel like typing all that info out here. It has some good notes about GETs and POSTs.

The BIG thing about GET requests and POST requests is that generally speaking a GET should be idempotent meaning that it should not cause changes to the state of a server. GET requests are meant for getting data from a resource but not modifying the data that is stored. POST requests should be non-idempotent meaning they can modify the data that is stored.

Wait a second, weren't we just using GET requests to log data on the previous exercise? Well yeah. We shouldn't have been doing that, but we shouldn't be burning fossil fuels at the rate we are either. It was easier to just do that set of exercises with a GET request, but going forward, in designing good APIs we want to adhere to the idempotency rule about GETs and POSTs.

Logging Temperature from your ESP32

So for this final part of the assignment what you need to do is:

• Revise your ESP32 code so that it sends the temperature, humidity, and soc data from Lab01 to your own RPi server's efi_test Flask application via POST requests. You can use the exact same query arguments as before (including your kerberos) to convey your data (don't need to use a POST body for this one, though you can if you'd like).
• The Flask application (via a POST endpoint) should log the temperature, humidity, and soc as floats (aka reals) as well as the time when the measurement was received. It should also calculate and store the heat index. You can log your kerberos (or not), or just use it as a simple sort of authentication (aka only update the db if the proper kerberos is provided).
• The Flask application should also have a GET endpoint that takes in one argument, kerberos, and will return back a list of the times, temperatures, and humidities that have been reported in the last time minutes. You can present as rows of text (we haven't done Flask Templates yet so it is tricky to do more complicated formating ))

The behavior needed on the server side is likely about 90% implemented already for you. Just expand your current efi_test application...add another endpoint to handle this and go through the Flask documents to determine how to discern a GET from a POST request.

Deliverable!

Set up your system and let it run for at least 12 hours on battery power. On or around Tuesday February 13, we will visit your server look for 12+ hours of data.

Enter the URL where we can view the data in the box below.

Enter your posting URL:

Loading...

Once Done

Once done, you'll have your very own entirely complete battery-powered IoT weather monitor. And only in one week!