In a previous post, I talked about how I worked on a vaccine fridge monitor that was designed to alert me over Pushover if anything was going on with the fridge. At the end of that post, I mentioned that I had received some kits for some contests – both of which were hefty multi-sensor boards.
Arduino Oplà
While having alerts pushed to the phone and reading the temperature from a dashboard in the cloud could be considered sufficient, I wasn’t satisfied. When I saw the Arduino Oplà, I realized I could probably make it into a IoT display.
After reading about the Arduino Cloud and how easy it was to get a board online, I decided to buy an Arduino Nano 33 IoT to replace my D1 clone [reminder: the D1 served to send temp info over WiFi to a dashboard in the cloud, to save the Particle Boron from using up cellular bandwidth when there was no need to use cellular].
UART my friend
While I was in the process of expanding this monitor, I added an Adafruit SD card reader to log alerts and data. I also realized that there was no reason to have two temperature probes (one for the D1 and one for the Boron), so I decided to connect whatever was the WiFi board to the Boron over UART (which is stooopidly easy – well, mostly because I did such data transfer before).
I mounted everything on a perfboard. The SD card reader and the Nano were powered from the Boron, with the catch that the Nano was powered from the VUSB, meaning it’s off when the power is out (because if the power is out, there isn’t any WiFi anyway).
Additionally, the Nano was connected to the Boron via UART. Periodically, the Boron writes out pertinent data (and alerts if they happen) to the SD card, and then sends the same data to the Nano, which then sends it to Arduino Cloud.
Arduino Cloud
The Boron allows firmware update over the air, but I try not to do that much, as it consumes cellular data. But OTA update was helpful when I was tweaking some things after things were assembled.
On the Arduino Cloud side, provisioning the Oplà and Nano was quite pleasant – select your variables, fill in what happens when they change, upload the sketch. While trying to get the Arduino web editor to work over USB with my Mac was hit or miss, I was quite pleased with how easy it was to do OTA firmware updates over WiFi.* The only unpleasant surprise was I didn’t see that you can’t duplicate sketches in the web editor, almost losing a ton of code (I happened to have copied it out in a previous version).
Once in the Arduino Cloud, I could have the variable linked to another device (in my case the Oplà) that would respond to changes in the variables. And I could make a dashboard, as well.
Tying it all together
I now have a temperature probe connected to a Particle Boron. The Boron is taking readings and writing them to an SD card log. I can query parameters from the Boron through the Particle Console.
The Boron has a battery back up and can also sense power state (USB or Battery) and will alert me of anything by push message to Pushover on my phone.
For the WiFi part, the Boron sends data to the Nano. The Arduino Cloud makes it easy to work with multiple variables, I am able to report temperature, battery level, contacts status, Boron connection to cloud status, and SD card free memory.**
Once the Nano receives the data from the Boron, all it has to do is update its own variables. These variables then change in the Arduino Cloud, and the Oplà, linked to the same variables, updates its own variables, showing them on its display.
What’s more, because this is a critical device connected over cellular and WiFi and logging data, I have put in quite a few checks and module re-initializations, to ensure that all the services and functions I’m using are healthy, robust, and available. Plus I can update the firmware over the air, if needed.
That’s the IoT dream.
Filling slots
Ok, I will admit, part of picking five variables is because the Oplà has five buttons. I programmed the Oplà to always show temperature (see above). But if you press another button, it temporarily shows one of the other readings. Plus, if something goes wrong, the LED goes red and flashes the variable until things get back in range. Like a good display should.
In closing
This has been an interesting project. And there was a significant degree of complexity, made easy by how the vendors themselves (with great communities) make it easy to program and provision their devices. I can see myself tweaking things more, but I think I’ll let this rest a while. Plus, my wife is tired of me talking about it. 😁
*Now I understand what Adafruit is doing with Whippersnapper – this is indeed the way IoT needs to go
**The connection to cloud status for the Boron is partly because it could disconnect and I’d never know. I was also concerned that I’d run out of SD memory and not know. But after writing the code to handle all of the SD free memory calculation, I realized that the amount of data I was writing will take forever to fill up the SD.
