Save Energy with a Healthy Refrigerator

Use the zymbit.connect software and Raspberry Pi to monitor and determine the health of refrigeration systems.

Similar projects worth following
Refrigeration and air conditioning devices consume ~25% of all electricity generated on our planet! From small business owners to franchised restaurant chains to medical facilities the initial, operating, and maintenance costs of refrigeration and air conditioning units can be quite staggering.

The biggest factors contributing to power consumption are:

- Temperature difference between ambient and cooled area (the case).
- Machine “health” of refrigeration system.
- Door activity.
- Easy access to and visualization of data by different stakeholders (if you can't see it, it's not a problem).

To learn more about how these variables impact power consumption, Zymbit's Evan Fairchild set out to build a low-cost device for monitoring temperatures and door activity, computing the health of the refrigeration system, and presenting the data in an easy to understand format that could be quickly analyzed and shared with others.


Evan designed a simple two layer “motherboard” to integrate all the sensor inputs, three different display types and a basic capacitive touch engine to make “interactive” OLED displays. With the addition of an RPi compatible header the whole assembly snapped onto a Raspberry Pi, no wires required. (So basically, he built a large “Pi plate” of sorts). The processing and communication horsepower is delivered using a Raspberry Pi B running the Raspbian operating system. Evan chose the Raspberry Pi (RPi) because it’s a powerful and affordable quad core computer with huge community support.

All display components are easily programmed with custom Adafruit and Zymbit python libraries.

For temperature, Evan used the readily available DS18B20 temperature probes which were connected to a oneWire (digital) bus routed to the screw terminal at the bottom left of the PCB. Simply screw in as many temperature-probes you like and that is it! There are also pinouts for the I2C bus and SPi bus with up to 5 additional slave lines routed to the left side of the PCB. These leave the board open to virtually any additional sensors.

PROOF OF CONCEPT -- Built for convenience, not elegance

When building the motherboard, Evan needed it to be a quick process so he used standard ‘maker’ parts available from Adafruit and Sparkfun. Several of these came on mini PCBs of their own, making hand assembly and customization easy. Welcome to DIY IoT!

For a more finished product, which is cost optimized, the obvious next step would be to re-design the PCB to accept all chips directly and then machine assemble. But this is a proof of concept, and maker parts work great.


The refrigeration thermodynamic process is remarkably quite simple with only three primary components of interest for monitoring: compressor, condenser and evaporator. The figure below shows the refrigeration thermodynamic cycle and vapor dome, temperature-entropy relationship.

For the above process to work efficiently, there must be proper airflow for energy to exit the system through the condenser. Dirty or clogged condensers are a common problem and service matter for refrigeration and freezer units. Monitoring temperature here will help maintain thermal efficiency. This is best accomplished by placing DS18B20 temperature probes before and after the condenser. One placed at the compressor-out stage and the other at the evaporator-in/expansion valve-in stage. If you are building this yourself take time to understand where components on your refrigerator or freezer are located. Evaporators usually run vertically along the back of the case. Condensers can run parallel to the evaporator (that’s how mine is built) on the outside of the case or along the underside of the unit.

Temperature data is collected from four locations.

  • Tcase – temperature “case” (space being cooled)
  • Tamb – temperature of ambient air.
  • Tcin – temperature of condenser input.
  • Tcout – temperature of condenser output.

Each data channel is immediately reduced to event-specific publishing constraints. For this prototype, Evan generated and event for a change of 1° in temperature, within any sensor.


All code and detailed instructions can be found in the Zymbit community RPi Refrigeration Analyzer. Here, he summarize the basic steps needed to deliver a continuous stream of data via JSON, and some automatically created dashboards. Check out these links below to code and instructions.

  1. ACQUIRING data from the sensors into the RPi.
  2. PUBLISHING time series data from the RPi to zymbit services.
  3. SUBSCRIBING to time series data through zymbit services.


To make things really simple, the Zymbit console displays the real-time data with chart or dial widgets which can viewed on your profile’s dashboard and/or embedded elsewhere. The Zymbit dashboard is very easy to customize and it generates an...

Read more »

  • 1 × Raspberry Pi B+ (A, A+ also work)
  • 1 × Custom circuit board
  • 2 × LED 8×8 matrix display (Adafruit)
  • 1 × HT16K33 breakout board (Adafruit)
  • 3 × OLED 64×48 breakout micro displays (SparkFun)

View all 8 components

  • Lessons Learned - What’s Next?

    Zymbit08/28/2015 at 00:27 0 comments

    By Evan Fairchild

    This phase 1 proof of concept serves as a great benchmark and shows the possibilities of using maker parts to prototype applications.

    This was the first PCB iteration and so there were a few routing errors that were not found in the DFM checks. Luckily, nothing proved to be show stopping; many issues could be resolved in software. The board will be iterated upon soon. There will be four screw terminal routed to one bus to make sensor replacement painless. Also, the board will be extended to accommodate a prototyping area to further its customizability. The Eagle files will be published with the next blog update.

    The touch worked surprisingly well and proved to be very easy to use thanks to the CAP1188 self calibrate mode that initiates on startup. Once the ITO is set you may have to reboot the RPi a few times for the touch sensors to calibrate properly but other than that it is straightforward. The timing still needs to be improved. There is a lag (~1s) between when a touch is detected to when a command is processed. I predict the problem lies in how the commands are being queued on the server side; however, I need to investigate this further.

    Collecting and publishing data was very easy. The API was useful for debugging and testing my duty cycle model, especially when i could do it remotely from 350 miles away when I was up in the Bay Area!

View project log

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates