[Project] Temperature controlled chest freezer



  • I've finally got my project off my desk and installed on my freezer. Keezer actually, a chest freezer for kegs.
    http://martinbuilds.blogspot.com/2017/02/the-webkeezer-omega2-powered.html
    It measures temperature and switches a relay to keep the freezer at beer temperature. As a bonus, it tracks a second temperature to show how even temperature is throughout, and it has a simple float switch to alert if beer is leaking onto the floor. (I've had two too many leaks happen in the last several years.)
    All this can be displayed while on a local network. No cloud integration yet.



  • Very nice, I'm planning something similar for a herms system. If I may suggest some improvements to your script.

    • Add a timeout. Cycling the compressor too often without time in between will shorten the life of your fridge/freezer.
    • Have you looked at PID control? Perhaps this could be integrated: https://github.com/ivmech/ivPID

    Great start!



  • Thanks for the feedback. I do have a temperature differential setting (not too well documented, I guess) that's the same idea as a timeout, right?

    # make relay decision based on tempC
    if tempC > (setpoint+deltaT):
            if relayState == 0:
                    setRelayOn()
                    print "turning relay on"
                    relayState = 1
    elif tempC < setpoint:
            if relayState == 1:
                    setRelayOff()
                    print "turning relay off"
                    relayState = 0
    

    This keeps the freezer cycling once every ~100 minutes for about 12 minutes. (Plots coming soon!)

    I've looked at using a PID library for another project (RIMS). I found it a bit hard to get the constants set properly so I ended up using a duty cycle setting for PWM control with that project.



  • Pretty cool...
    I love the fact you use 1-wire sensors, I use 1-wire sensors every chance I get. I like to epoxy the sensors directly to refrigeration plumbing so I can track superheat and subcooling in multiple locations, and sprinkle them everywhere in the system for more visible process control... So thumbs up for that!

    But you need to be sure to integrate a real hold-off timer, as short cycling the compressor can destroy it. It sounds like your duty cycle design may do this, but I can't be sure. And one source of short cycles can be power blinks caused by weather or substation switching, so hold-off time must be added to the startup of the unit after being powered off.

    On compressors with internal thermal protection, you will overheat the compressor until the thermal protection trips, and the resulting delay "resolves" the issue, until you eventually wear out the thermal protection switch, then the compressor is shot. On units without thermal protection, you simply overheat the compressor until the windings melt, and the compressor is shot. It is critical that the compressor not try to turn on before the pressures equalize between the low and high side refrigerant circuits. So every time the compressor is turned off, it MUST stay off for some minimum amount of time, and this time varies system to system.

    The PID control question is a completely different issue. PID's are great to prevent overshoot, but are mainly useful for heating applications. You CAN use a PID in a cooling circuit, but the PID must be designed to not result in short cycling. PID's general nature is to have pretty short cycles, and in my opinion are not suitable for refrigeration applications for small units like a kegerator. A small overshoot will not affect a large thermal mass like a keg, so the PID function is irrelevant to this application.

    Where a PID comes in handy is in heating circuits, like bbq smokers, where overshoot can affect the quality of your bbq. Overshoot is caused by the delay between the heat being produced, to the heat being detected. Undershoot is also a problem in some systems, so a PID is designed to slow heating as you approach the set point, to prevent going over. they are used in chemical plants on reactor vessels to prevent a chemical process from overheating and destroying the batch being produced... but there are many other applications for PID's. The PID output is typically a pulse width modulation, which works great for heating elements. But unless you force the PID to only use off-pulse widths longer than the minimum compressor hold-off time, it can't be used on a compressor. A typical PID will have the shortest pulse widths around 1/2 second or so, far too short for a compressor. Most chilling systems use a simple on or off thermostat, with an integrated hold-off feature, or the hold-off is incorporated in a time-delay relay or a controller board on the unit controlling the compressor. I've never heard of a system using a PID for chilling, but of course it is possible. I have seen systems that simulate a PID behavior, by reducing the compressor speed or compression ratio, like the new "digital inverter" compressors on some modern systems, but those compressors never turn off, they only turn down... And while they are controlled by something like a PID, it is not a PID, it is something else.

    Bottom line, I don't recommend a PID for most chilling applications.

    To determine what is a "short" cycle for your unit, get a stethoscope, and listen to the sounds in the cooling coils after the compressor is turned off. The best way to do this is to unplug the unit for at least an hour, so that is warms up several degrees. Then plug it back in, and watch it cool down. Before it reaches the set-point, and the compressor is still running, unplug the unit and note the time. While it is freshly off, find the place where the stethoscope produces the loudest sounds of the refrigeration gasses equalizing. Once you find that spot, listen as the sound diminishes, and when you can't hear it at all, note the time again. The begining and ent times are your "measured" equalization time. Now the actual equalization time is actually longer than your calculated time, and depending on how confident you had a good location to hear the gasses moving, you should calculate a time value to use. I would recommend at least 2 to 4 times the measured time, so if you heard the gasses hissing for 5 minutes, I would us a 10 to 20 minute timer value for the hold-off timer.

    In your thermostat routine, you should timestamp the time you turn the timer off, and the routine that turns the compressor on should check to see that the hold-off time has passed, and delay startup if it hasn't. Also, if the unit is turning on after being off, such that the time off is unknown, the compressor should not be turned on until the hold-off time has passed.

    The hold-off time is critical, otherwise you /will/ damage the compressor eventually.

    The problem is that the compressor has a hard time starting up when there is already pressure built up in the system. Hard starts are very bad for the compressor. Most compressors won't start at all under pressure, but some will eventually start, but not without overheating. Heat will shorten the life, and even destroy the compressor.

    I'm an engineer, I have a refrigeration license, I've designed PID's, temperature controls of various types, I ran an ISP for 20 years, and have designed control systems for a variety of applications, such as diesel engine computers , power plant systems and data center air conditioners. My passion is IOT, or at least networked control systems, so I love peeking into what other people are doing.



  • @George-Wenzel Wow, what a post! You've confirmed much of what I had a hunch would be true about PID and have some great words of caution about compressors.

    I forgot to include in my write up that I have the sensor in a jar with about a cup of water to keep the temperature stable as far as the thermostat routine is concerned. I also have the deltaT set to 0.9C. (The freezer turns on once ~100 minutes.) But protecting the compressor is key and I should include a failsafe measure to prevent frequent cycling in in case of who-knows-what.



  • Hi Martin
    Thanks for the webkeezer project it provided some great insight into the Omega2 and formed the basis of a web connected thermostat I want to build.
    I hacked it a bit to use a TMP102 temperature sensor on the I2C bus and used a while True and a sleep(30) to create a constantly updating thermostat (also reversed the relay action).
    If anyone is interested I loaded the python-smbus_3.1.2-1_mipsel_24kc.ipk package from http://repo.onion.io/omega2/packages/onion/ and added this to the start of the code

    while True:
    import smbus
    import time
    bus = smbus.SMBus(0)
    data = bus.read_i2c_block_data(0x48, 0)
    msb = data[0]
    lsb = data[1]
    current_temp = (((msb <<8) | lsb) >> 4) * 0.0625
    print current_temp
    sleep(30)
    getTemp = current_temp

    I have been trying to get a drop down on the web page to set the setpoint temperature (update keezerparams.txt) but have not had any luck.
    If someone from the community could give me a nudge in the right direction I would be most grateful. I have very little python or html experience but can usually stumble my way through some code and work out what is happening.
    Cheers Andy
    PS when I looked at the preview I had to change the line current_temp = (((msb <<space8) to (((msb <<nospace8) becaused it looked like this (((msb << 8)
    It should be " (((msb <<space8)"



  • I've made some wiring improvements and added plots. I've also gone back and forth on having the python script continuously run and waiting with sleep() statements vs exit and run again via cron. I've settled on cron and have written more data to file.

    @Andy-Burgess

    I have been trying to get a drop down on the web page to set the setpoint temperature (update keezerparams.txt) but have not had any luck.

    you'd need some server-side functionality (e.g. with PHP) for interacting via a webpage. For me, I rarely need to change the temperature setpoint so I haven't bothered.
    An onion console app on the cloud would be nice, but I haven't learned how to do that yet. Maybe Blynk?



  • @Martin-Oberg

    Looks good, Thanks for sharing! I tested out your code on one of my original Omega, and was also having issues with running out of space. When I have some time I'll try again with my Omega2+ and add more space with an SD card.

    I've been too busy with work to get anywhere with my own project, but am looking for the best way to add server-side functionality to this project. It would be great to be able to change the setpoint, show last off time, and set minimum off time. Any suggestions on the best way to do this? I'm trying to learn more about PHP, and also looking at node.js.

    Once I have an Omega controlling my draft cooler, my goal is to replace the arduino controlling my brewery now. Hopefully I will be far enough along with that project to have something worth sharing in a couple more weeks.



Looks like your connection to Onion Community was lost, please wait while we try to reconnect.