This is a stereotypical love story of the shamelessly festive variety, of how two seemingly different storage mediums defy all doom-mongers and naysayers to conquer the world - together.
The premise of this story is so ludicrous, the ending so unsatisfying, that this is all we have to say about when Barry the SD card met Ally the S3 bucket... for now.
If you are allergic to even a little sprinkle of holiday sentimentality, it might be best for your health to abandon this post... right about now.
Sleepless in Seattle, Amazon HQ:After our recent intrepid detours taken outdoors, equipped with a bag full of electronics, we've been attempting to refocus our efforts on some things that are much closer to home. And to get back on to the AWS IoT portfolio devised by that cloud mega corp headquartered out in Seattle.
To this end, here's the shamelessly melodramatic screenplay that even Richard Curtis would find too embarrassing to draft for Nickelodeon.
- We will be using an ESP32 development board running MicroPython. We have paired it up with a breadboard, as we have quite a few modules to attach to its various pins.
- Speaking of modules, our production will be getting some screen time. We will be using an SSD1306-driven 128×32 OLED screen to display pointless stuff, a BME280 sensor to measure atmospheric temperature, humidity and pressure, and a SD card device to directly log our results .
- And because we do want to store all this data also in the lovey-dovey cloud, we'll be using AWS IoT Greengrass running on a Raspberry Pi together with AWS IoT Core to publish our readings via MQTT.
- Lastly, we'll store this data in an AWS S3 bucket to complete the holy matrimony between SD and S3.
Glueless:This is the fifth instalment in the dreary straight-to-video romcom series I-O-Mr-T - which Roger Ebert once described as a poignant, modern fairytale in which electronic components from different walks of life follow their destinies and find love in unexpected breakout boards, breadboards and power rails.
And in case you didn't pick these up on VHS in the local Blockbuster bargain bin back in the 90s, here are the instalments that defined romance for a generation.
Right - let's get on with the cooking up of this experiment because we're hungry for sweet, savoury IoT and there's just Something about Mary Berry.
And - no - no glue is involved.
"colin firth" not in "hill":
It is fast becoming increasingly hard to keep track of the actors and actresses appearing in an ever-growing list of romcom films.
For example, was it Colin Firth playing the recurring role of the bumbling Englishman in Notting Hill? Did Drew Barrymore manage to compress her sensor readings for LoRa into the 50 First Bytes? Did Tom Hanks demand that Meg Ryan drop the use of an unclassified personal POP3 server in You've Got Mail Server?
Thankfully for us, however, we have a pretty clear idea as to what activities will star in this little feature.
Here are the spoilers:
- After attaching all aforementioned electronic components to the ESP32 development board, we will first attempt to send a witty message to the SSD1306-driven 128×32 OLED screen like Meg and Tom, original developer advocates of the AOL "send email" functionality.
- Then, we'll use the BME280 sensor to measure atmospheric temperature, humidity and pressure because Punxsutawney needs a good weather station all year around.
- Should we be storing these readings somewhere local first, before we dispatch them to some anonymous server on the cloud? Yeah, go on then. Let's try saving arbitrary data to an attached SD card. Because that's Definitely, Maybe what cool kids do these days with their selfies and screenshots of someone's now-deleted Tweet.
- Yet, we all remember that quote from Dirty Dancing: Nobody puts ZigBee in a dormer. Sorry, not that one. This one: What's big, cuddly and is great at digesting inordinate amounts of data like Uncle Buck? Cloud, right? Which is why we'll send our readings to AWS IoT Core - via an IoT "Greengrass is Greener on the Other Side, especially when illuminated by a green LED" device - and store our data safely in a S3 bucket.
And, nope, it was the other Englishman (Hugh Grant) in Notting Hill.
How to Lose a
vi in 10 Days:
She was just a girl standing in front of
[email protected]:~, asking
vimto love her
Please excuse the format. We have inadvertently launched vi, and we can't easily find a way out.
We have spent many months demonstrating how we collect sensor readings from various modules using MicroPython running on an ESP32 development board. Similarly, we have used AWT IoT Greengrass Core running on a local Raspberry Pi device in the past to concentrate readings from our various microprocessors, and to act as a gateway to AWS IoT Core.
But - often - it is advantageous to store readings taken directly to a local storage device to ensure we retain a local copy. Secure Digital - or SD - is a widely used non-volatile memory card format commonly seen in smartphones, cameras and all sorts of other devices these days. They can store gigabytes' worth of data, and are tiny in size, so make an ideal storage device for IoT data.
Now the aim here is to also make an identical copy of the data in the cloud. Specifically, we want to create objects in an AWS S3 bucket. This will be achieved using a Rule in AWS IoT Core which will duly save the messages it receives from our device via Greengrass into the designated S3 bucket.
A little like this:
Some (Smart) Thing's Got a Sieve:Right, how do these festive feel-good stories normally start?
There's a snowstorm outside. Two bumbling protagonists - one preferably with an English accent - are stuck together in a local incarnation of an unnamed global coffee franchise with a
*in its name (not literally using epoxy glue... no, that would be a Saw film). They stare longingly at each other over a wall of iPhones, MacBooks and the latest super food smoothie made out of kelp and local pond water. Then, after entering some fictitious numbers into adjacent cells in Excel (Ally is obviously a work-obsessed high-flying tax accountant at Earnest and Dung), the tension is finally broken with the film's standout quote.
You had me at
And the two lovers frantically start to make... hardware!
We start by reserving two GPIO pins to provide HIGH and LOW signals to red and green LEDs. These LEDs are connected to ground using corresponding 330Ω resistors to limit the current through each semiconductor.
Next, we use two GPIO pins to form an I2C bus - one that will be shared between the OLED screen and the BME280 sensor. This coupling works, because they are both equipped with different I2C addresses and can therefore be reached over the same physical I2C medium. The modules appear to have built-in pull-up resistors too, which is very handy for us.
Lastly, we need four additional GPIO pins for the SPI connection which will be used to communicate with the SD card module.
Here's the famous table on which Barry the SD card will meet Ally the S3 bucket to exchange some pleasantries.
|ESP32 Pin||Connected to...||We should care, because???|
|GPIO 33||Red LED (with 330Ω resistor in series)||Provides current to the red LED so that it can warn the audience about the appearance of the idiotic (but inexplicably affluent) ex who will do everything to ruin the couple's relationship|
|GPIO 32||Green LED (with 330Ω resistor in series)||Provides current to the green LED to indicate that the ex has been safely disposed of... by a hitman (totally unnecessary back story: the hitman is actually a 40-year old gherkin)|
|GPIO 26||SSD1306 OLED SCL and BME280 SCL||This is used for the shared I2C Clock signal|
|GPIO 27||SSD1306 OLED SDA and BME280 SDA||This is used for the shared I2C Data signal|
|GPIO 18||SD card SCK||This is used for the SPI Clock signal|
|GPIO 23||SD card DI||This is used for the SPI MOSI signal|
|GPIO 19||SD card DO||This is used for the SPI MISO (soup) signal|
|GPIO 15||SD card CS||This is used for the SPI (mint choc) Chip Select signal|
Clearly, all the relevant power connections of the modules (3.3V, 5V and GND) are cabled up as well. Our SD card module, for example, appears to require a 5V supply unlike the rest (more likely to do with the built-in voltage regulator of the module than the SD card itself).
Here's the cute baby photos. Awww.
So, on what wholly unnecessary tangent does the story go on next?
The 92-minute running time can't simply consist of songs by Boyzone and scenes of completely indecisive human beings telling peripheral characters about how much they love or not love a certain individual, in ASCII.
Yes, let's proceed to create completely needless drama.
We have some blinky-blinky LEDs on hand, we can add some cheery sparkle to proceedings. Sending the GPIO pin HIGH raises the pin's voltage to 3.3V, and as such, sends current flowing to turn the LED on. Sending it LOW will turn it back off. Like Mr. Miyagi said. HIGH = on. LOW = off. HIGH = on. LOW = off. Get it?
Nice and simple; let's give it a go.
from machine import Pin LED_RED_GPIO = const(33) LED_GREEN_GPIO = const(32) led_red = Pin(LED_RED_GPIO, Pin.OUT) led_green = Pin(LED_GREEN_GPIO, Pin.OUT) led_red.on() led_green.on() led_red.off() led_green.off()
Wow, OK. That wasn't as satisfying as we thought it would be.
What's that? Didn't we connect an OLED display to the ESP32 development board as well? We sure did. Let's send it some poignant messages about true love.
We first initialise an I2C bus using our designated GPIO pins, and feed it to the SSD1306 MicroPython library. Running a
scan()reveals our two I2C devices that are already on the bus (OLED and the BME280), and we can simply use
show()methods of the library, after we initialise an
oledobject, to send characters to the screen.
from machine import I2C, Pin scl_pin = Pin(26, Pin.IN, Pin.PULL_UP) sda_pin = Pin(27, Pin.IN, Pin.PULL_UP) i2c = I2C(scl=scl_pin, sda=sda_pin, freq=400000) i2c.scan() import ssd1306 oled = ssd1306.SSD1306_I2C(128, 32, i2c) oled.text("ANOTHER BORING ", 0, 0) oled.text("IOT PROJECT... ", 0, 16) oled.show()
Aren't we that hilarious jester who is best friends with the aesthetically pleasing main characters, but has failed miserably to achieve anything meaningful in life by the end of the film.
The red LED it is, then.
Oh, did we say the story's backdrop was some fictitious town experiencing an unseasonable snowstorm? Yes, we think we did. Which is handy, as we now have an excuse to introduce an otherwise completely random temperature / humidity / pressure sensor.
Here, we have a BME280 sensor that we can interact with using the MicroPython BME280 library. Notice how this device is connected to the same I2C bus (pins) as the OLED screen so we're simply reusing the
BME280class does the trick just fine.
import bme280_float bme = bme280_float.BME280(i2c=i2c) measurements = bme.read_compensated_data() print(measurements)
Now, you don't have to be Richard Gere from Pretty Woman to overcome the moral dilemma of playing out your sins on-screen. The LED is now green - because we're winning.
Now onto the interesting bit... the SD card (or Barry as we have christened him).
We use the MicroPython SD Card library after we initialise a
SPIobject. Then, we simply mount it at
/sd. That's it. No, really. We can write to and read from the SD card as long as it has been formatted as FAT32 beforehand, and all the plumbing is sound.
Notice how SPI uses a distinct set of ESP32 pins.
import machine, sdcard, os from machine import Pin, SPI spisd = SPI(2, baudrate=80000000, polarity=0, phase=0, bits=8, firstbit=0, sck=Pin(18), mosi=Pin(23), miso=Pin(19)) sd = sdcard.SDCard(spisd, machine.Pin(15)) MOUNTPOINT = "/sd" os.mount(sd, MOUNTPOINT) os.listdir(MOUNTPOINT)
/sddirectory is now available for use from within MicroPython. Which means we can write something "hilarious" to it in the form of a
test.txtfile. Go on, under-achieving-best-friend, offer us some comic relief like you're supposed to.
FILENAME = MOUNTPOINT + "/test.txt" MESSAGE = "This is another boring IoT test. Please ignore.\n" with open(FILENAME, "w") as file_write: file_write.write(MESSAGE) os.listdir(MOUNTPOINT) os.umount(MOUNTPOINT)
After the SD card has been unmounted, we can safely eject it and insert it into a laptop to check that the content has been preserved.
...Which it has. Excellent!
Hang on a second. That was all about Barry. Where has Ally the S3 bucket been hiding all this time? Had that posh ex made an unwelcome return from a round-the-world yacht race sponsored by some sovereign wealth fund?
We have spent a considerable time chronicling AWS IoT Greengrass in Green, Green Grass of /home. And more generally, how we register and connect things in AWS IoT Core is described throughout the I-O-Tea series.
Clearly, to work with AWS IoT, we need our thing to exist in the device registry of AWS IoT Core.
thingy-thingy-thing-thingis what we've decided to call our ESP32 development board in AWS IoT Core.
Since we'll be publishing our sensor readings to MQTT topic
givememysensorreadings/ohhereitis, we need to give this device permissions to publish to this MQTT topic.
umqtt.simple client can be furnished with SSL details when establishing the onwards MQTT connection to Greengrass.
Now we should probably add the device to our Greengrass Group.
We've decided that Ally is a S3 bucket. Of course, she could just as easily have reprised her previous role as a DynamoDB table (Frozen Pi), IoT Analytics channel (Quantitative Wheezing), Lambda function (Have-ocado), Elasticsearch Service endpoint (Hard Grapht), IoT Events input (Pear Force One) or any other AWS service directly accessible using a supported Rule in AWS IoT Core.
In fact, we'll re-enable our Rule to forward our data to an AWS IoT Analytics channel anyway, since it's a convenient destination to store our sensor data.
But we also promised you a Rule for S3. In AWS IoT Core, we create a Rule that automatically saves messages received on MQTT topic
givememysensorreadings/ohhereitisas an object in a S3 bucket we have called
The key being used for the S3 Rule ensures that the data is actually being organised under a semi-legible folder structure consisting of the MQTT topic, and device name. The objects in S3 will be individually named as the timestamp.
givememysensorreadings/ohhereitisare immediately dispatched to AWS IoT Core in the cloud - and thereby invoking the Rule and getting saved as a S3 object.
Of course, we can test this manually by creatively fabricating figures on the ESP32 like Ally the high-flying tax accountant, and watching them come in on the AWS IoT console.
Here's actual footage of this mysterious device in action.
But in reality, we'd wrap this up in a MicroPython application that repeats this indefinitely, to ensure that sensor readings are taken, and dispatched, even While You are Sleeping.
Finally, we find this identical data stored away in Amazon S-3(Three). Not to be confused with Katherine Heigl's classic with slightly more S's - 27 S's in fact - an inspiring story of a Siamese cat that accidentally falls asleep on a very specific key of the owner's developer MacBook.
And of course, we can store the same data to the attached SD card to complete the story, and therefore bring this melodrama to a happy, symmetrical conclusion.
Well, that's that then. This is the sentimental end to this heart-warming tale of two storage mediums that were fated to be together. Like, forever. Or, until the next sequel. Whichever comes first, before the divorce.
We're now off to direct the next instalment, Four Beddings and an Urinal, in which a lonely Debenhams store assistant meets the love of his life (and more importantly the year's sales targets) selling Internet-connected futons, and a smart toilet from Japan. Or off on our next outdoor expedition; to be documented in It's Rab Actually, about a down and out mountaineer who has had his North Face sponsorship terminated.
Happy holidays everyone!
Don't miss Rage:MKR, in which we reaffirmed our eternal commitment to AWS IoT Analytics by connecting up AWS QuickSight and Jupyter Notebooks to our AWS IoT Analytics Data Sets.