Everyone these days knows the importance of keeping vaccines safe and functional. This is the same, of course, with veterinary vaccines.
A local veterinarian I know stores all her vaccines in a special vaccine fridge at her home (she’s a mobile vet, so has no clinic). She asked me to create a monitor that can log the fridge temperature, alert her when the fridge is out of temperature range or out of power, and pass on any alarms from the fridge itself (there are exposed contacts for that).
Brainstorming
I first wanted to see what was on the market.
An online search failed to uncover any fridge monitors that could easily send text message, log data to the cloud, or was easily programmable. For the most part, the fridge monitors I found were geared toward professional environments with a cost and operational profile very different from a home environment: built for local logging, alerts through building Ethernet or WiFi network (not useful if the power is out), and closed (can’t modify the code).
I knew I wanted the solution to be connected to a mobile network, battery-powered, use a temperature probe (there’s a hole in the side of the fridge specifically for that), be connected to the fridge’s alarm contacts (they were designed for someone to interface their own alarm system directly to the fridge), log temperature (locally on SD or over the air to a dB), and be connected to some text message service.
Something to look at
I regularly look for dashboards I can send data to, such as Adafruit.io or Thingspeak. What’s interesting is that most IoT system vendors are focused on device management, not helping someone visualize their data. And IoT tools from folks like AWS and Google just seem too complicated to whip up a dashboard attached to a device. I ended up using Adafruit.io, but Thingspeak was pretty good as well. The rest of the ones I have seen cost more than I was willing to pay. And as I said, almost all IoT services that connect to devices aren’t geared toward visualizations or easily connecting to visualization tools. Really.
The design
The Particle Boron comes with most of what I needed. It’s cellular-connected, so it doesn’t need a WiFi network to send data (Do you realize how many IoT boards are WiFi or Bluetooth only? How useful are those during power outages?). The Boron also has a battery connector and has easy code for you to know when the main power is out and it’s running on battery (bonus: it can tell you the battery level, too). The Feather format of the Boron also means there are a lot of pins for the temperature probe, wires, and SD card reader I was adding.
Therefore, the main use of the Boron is sensing temperature, logging to the SD, and issuing any alerts.
Wait, you may ask, what about sending data to the cloud?
As I was building this, I realized that using cellular to send temperature data or constant status messages was a waste of bandwidth (I must say my old Nokia-days frugal-data mind-set came back in force). So I decided to snag a cheap LOLIN D1 and temperature probe for a cheap, WiFi-based temperature reader, sending data to Adafruit.io. That data is really to just see how things are going. The logging by the Boron is the main data log, because it’ll still be able to do so under battery-only power.
About those alerts
I spent a lot of time thinking of all the ways to get a notification. I thought of an Adafruit.io or IFTT kinda notification. I also looked at Twillio. And there were some hacks one could do to email a text message.
In the end, I stumbled upon Pushover, which integrates really simply (thank you, tutorials here and here) with the Particle system. I set up different levels of alerts, such as critical for power outages, silent for daily proof of life messages. And it works really well to alert me to changes in the system.
Leveling up
I am so used to living in the Arduino and CircuitPython world of ample examples, easy programming tools, great set of libraries.
For the Particle, the libraries are the same or ported from Arduino. So there was familiarity there. But for me to program, I ended up using the VS Code-based SDK. There were some good first-use tutorials that helped me get a clue. But for sure it was all one step removed from my usual maker world. And, overall, developing for the Boron took a bit more effort on my part than my usual boards, partly due to less examples and community resources.
But the Particle system has some cool tricks, like being able to call a variable or function remotely over cellular from the device console in a browser. And there are some system health stats for when I want to know how the system is running. [That’s what most IoT providers offer – device management]
For me, learning a new SDK, doing local and over the air firmware updates, coding the board to return variable or run functions remotely all really leveled up my skills.
Where I’m at and where I’m going
I’ve had the Boron running for a while. It’s been silent, mostly because no alerts are needed. And the D1 is streaming data points to Adafruit.io, so I can see how the fridge is behaving.
Moving forward, I’m not too keen on using two temperature probes. So I am thinking to use the D1 simply as a WiFi bridge, receiving data from the Boron via serial. That way, the Boron does all the work and then tells the D1 to upload the data to Adafruit.io.
Also, right now, while I’ve been prototyping, the whole set up is on a breadboard and in a zip case. I need to permanently bring all the parts together and put it all in a decent enclosure.
Yeah, feature requests never end.
Finally, we’d really like to figure out how to control a power switch to the fridge backup battery to ensure uninterrupted power.
But for now, I’m just excited to have an LTE board sending alerts to my phone to ensure that the fridge is taken care of. Now I really need to clean it all up.
And then something unexpected:
Both Electromaker (with Nordic Semi) and Arduino are running contests around IoT, with free kit. I pitched this project to them, mostly because I didn’t think I would be awarded anything, but BOTH awarded me.
One project sends the Nordic Thingy 91, the other the Olpà IoT Kit. These boards are BEASTS – chock-full of sensors and functions – way overkill for a fridge sensor. And, in any case, they’d still both need a temperature probe for a fridge monitor, as one really wouldn’t place the whole board in the fridge, for various reasons.
While I pitched a fridge monitor, I feel a bit disappointed these guys are actually not well-suited for that. On the plus side, my brain is racing thinking how to use these multi-faceted devices.
One thing these devices taught me, tho, is they are really a multi-faceted dev platform. They have way too much to actually deploy anything with them. But that’s the point. Tho the Boron, also meant to be a ‘dev’ board, is priced and featured right that it can be the core of a deployed solution. As I am doing here.
In any case, look for more adventures in IoT as I figure out what to do with these two devices. 😁
[One more thing: Yes, you did notice that I have NO pics of the setup. Partly, because so much was happening in software and I wasn’t taking many pics. That’s not normal for me. I promise to do better next time.]