IoT Temperature Monitoring

Cardinal Peak just completed the initial phase of an interesting IoT project that was slightly afield for us. Six months ago, a volunteer for the Emergency Family Assistance Association, a food bank in Boulder, asked me to develop a solution to track temperatures inside freezers and refrigerators. Embarrassingly, we haven’t done much pro bono work — and on top of this, I think EFAA is a well-run and worthy organization — so we agreed to see what we could do.

EFAA has a number of freezers and refrigerators, with nine monitoring locations in all. As we discussed project requirements, we identified two primary needs. First was simple automation: Previously, the EFAA staff had to manually measure the temperature at each location twice a day, in order to meet health regulations, and the food bank manager wanted to automate this task. Second was alerting: Ideally, the staff would receive a proactive alert via text message if a freezer or refrigerator went out of spec, with the hope that the problem could be addressed before food was lost. A third benefit emerged as we got into the project: The data, previously hand-written onto log sheets, became much more useful by virtue of being collected automatically into a database; by looking at temperature graphs over time, EFAA could learn more about how their freezers operated.

Fridge and freezers pic

Once we understood EFAA’s requirements, my initial thought was to build a solution from scratch using a thermistor connected to a Raspberry Pi Zero. That would be a fun project, perhaps ideal to assign to a junior engineer for learning purposes. And for a much higher number of monitoring locations, I still think this might be the right approach. But for monitoring nine locations, it was clearly more cost-effective to purchase an existing commercial solution, and it seemed at first blush that something like this should probably exist.

Sure enough, a bit of internet research turned up several interesting products. We ended up evaluating and eventually purchasing Temperature Sticks made by Ideal Sciences, a small company in Utah. A TempStick is about the size of a Twinkie and is powered by two AA batteries. It has no buttons and only one LED to indicate connectivity. It wakes up once per hour (though this duration is configurable), connects to Wi-Fi, and reports the temperature and humidity back to a cloud server. The user can log into to view and download historical data. The cloud server also supports both text message and email alerts, which can be configured to be sent when the temperature goes over or under a given threshold, or in the case where the device does not check into the server when expected.

tempstick web page pic

For the most part, the TempSticks work well, and although the site is really slow, it is easy to use and displays the collected data using nice-looking graphs. We encountered only two problems.

The first problem is with the alerting functionality for the TempSticks. First of all, it’s not entirely reliable. In our initial testing alerts were only getting sent half the time. Ideal Sciences did address this bug after we reported it, but the alerts are still not sent 100% of the time.

Even once this problem is addressed, the behavior is too simple: The alert will be sent if anyone reading of the temperature exceeds a configurable threshold. The problem, for our application, is that refrigerators and freezers have an automatic defrost cycle. In an ideal world, for a freezer, you might set an alert threshold at 0° or 5°F, since the freezer is supposed to stay just below zero. But in order to melt any frost, the temperature in a correctly-operating freezer will periodically burst up to just above 32°F. In order not to flood users with false alerts, it would be great to configure the behavior to “only send an alert if the temperature is above the threshold for 30 minutes.” (Combined with functionality where the reporting interval of the TempStick would be shortened in the event the first reading is out of spec, which does exist.)

The second problem we encountered is that the reports available from the website don’t meet USDA reporting regulations. To work around this problem, Cardinal Peak created an automated Python script to periodically download the temperature data and create a PDF report which can then be automatically emailed to the appropriate end-users for compliance reporting. We’re making that script available via the GPL — you can find it here along with some supporting project documentation.

efaa report pic