Projects Research & Design Hub

Dehumidifier Revamped for the IoT Era

Written by Brian Millier

Wireless Control

When his dehumidifier stopped working, Brian decided to take a crack at repairing it. In this article, he explains how dehumidifiers function, and shares his journey as he replaces the old control system with a modern electronic controller. The new controller enables several IoT-era features like Web-based control via smartphone, efficiency monitoring and time-of-day scheduling.

I’ve been using a dehumidifier in the finished basement of my home for more than 25 years. Modern units are probably more efficient than this old one, though I haven’t investigated this. However, some friends owning modern units have mentioned that their units died after only a few years. The modern units have an electronic control PCB, and the average consumer is hard-pressed to get these units serviced.

My dehumidifier stopped working late last summer. Given its age, I initially just rolled it into a storage closet and let it “rest in peace.” Later, when I had some spare time, I took a closer look at it to see what had gone wrong. Even after it had stopped dehumidifying, I could hear the compressor start up when I plugged it in, and the fan was still working.

I have some refrigeration repair experience from early in my career, and the above symptoms often mean that the CFC refrigerant (Freon 12) has leaked out. This generally involves an expensive repair. Also, in our Canadian province, you can’t simply throw out a refrigerator—or anything else using a CFC refrigerant. You must pay an HVAC repairman to have the Freon removed before it will be accepted for curb-side waste pickup. In this case, even if the Freon had already leaked out, I would still need to pay an HVAC repairman to put a sticker on the unit, stating it had been drained of any CFCs. One more reason to try to repair it.

After removing the covers and examining the unit while it was running, I determined that the evaporator coil was cooling down and frosting up properly. So, the Freon refrigerant had not leaked out, after all. However, the compressor should have stopped running after a good layer of frost had formed on the evaporator coil, to allow the frost to melt and flow into the holding tank, and allow the condenser coil to cool down. This wasn’t happening—the compressor was running continuously, and the unit wasn’t working properly this way.

What component had failed will be revealed later in this article. I’ll explain how a dehumidifier works. Then I’ll describe how I replaced the old control system with a modern electronic controller.

The new controller has several features that weren’t present in the original dehumidifier. Indeed, even modern units don’t have most of these features:

— ADVERTISMENT—

Advertise Here

1) A time-of-day scheduling function
2) An efficiency check to ensure that the unit isn’t running when humidity and temperature conditions are such that it is not efficient
3) A Web-based interface that allows control/monitor operation from a cell phone or tablet
4) A “tank-full” alarm that beeps and generates an email message that is sent to a phone or computer
5) A humidity display—not just an adjustment knob coupled to an uncalibrated mechanical humidistat

I’ll expand upon these features later in the article, but I’d like to mention here that my electricity provider uses time-of-day metering. I get electricity for half-price all night and on weekends. Since a dehumidifier uses a fair bit of electricity, it’s best to run the unit only when the electricity is at this low rate. Even before I built this new controller, I had used an external timer (a DIY unit with an Espressif Systems’ ESP8266) on the unit, to limit its run time to nights and weekends.

REFRIGERATION-MODE DEHUMIDIFIERS
First, let’s look at how a dehumidifier works. The most common dehumidifiers used in homes are based on the refrigeration principle. I also see dehumidifiers based on desiccants on Google, but I’ve never run across any of these, personally. For the refrigeration dehumidifier, the basic principle is that the colder the air is, the less moisture it can hold. At the left of Figure 1a is a coiled aluminum evaporator. To the right is a copper condenser coil with many fins—like a car radiator. To the right of that is a motor, which turns a big fan. It isn’t visible in Figure 1a, but can be seen in Figure 1b, along with the compressor that powers the refrigeration process.

FIGURE 1A (Left)- The side of the dehumidifier, showing the evaporator and condenser coils.
FIGURE 1B (right)- The compressor and circulation fan. My new controller is in the foreground.

Room air is drawn into the dehumidifier by the fan, passing first through the evaporator coil, and then through the condenser coil. The evaporator coil gets cooled down to around 0°C. Water vapor will condense out of the air when it flows past the evaporator coil, and will either condense on the coil and drip down into the storage tank below, or it will produce frost. This cooler, drier air will now pass through the warm condenser coil, where it will be heated up beyond ambient room temperature. This warmer air will then be exhausted from the dehumidifier cabinet. Once back in the room again, this warmer, drier air will mix with room air and pick up some of the water vapor present in the room air itself. Then it gets pulled back into the inlet port of the dehumidifier, and the cycle repeats.

This process will continue efficiently for a while, but not indefinitely. Within a few minutes, the evaporator coil will frost up, which is OK. However, as time passes, the evaporator coil would ice up completely, at which time the water-removing capacity would diminish greatly. But before this could happen, there is another thing to consider.

The condenser coil is located close to the evaporator coil. Since the refrigeration process is not 100% efficient, in practice, the condenser coil will always produce more heat than the evaporator coil can remove. Therefore, the heat from the condenser coil will eventually work its way over to the evaporator coil, thus cancelling out any cooling effect that it originally had. This will happen even though the fan is pulling the hot condenser air away from the evaporator coil. You would see the effect if you tried to operate a window air conditioner indoors, without it being mounted in a window—which places the condenser coil outside where it can dissipate its heat.

In my old dehumidifier—with its simple control system—a thermostat is mounted on the evaporator coil. After the unit has been running for a while, the evaporator coil gets cold enough to trip the thermostat off. Any frost present on the coil melts and drips into the storage tank. In the time it takes for the evaporator coil to warm up enough for the thermostat to close again, the condenser coil will cool back down to around ambient temperature. When the thermostat closes again, the cycle will repeat.

It turned out that the thermostat in my old dehumidifier was stuck in the closed position. Therefore, the compressor ran indefinitely, but the dehumidification process stopped working after the first 5 minutes or so. While I likely could have found a replacement thermostat, I decided to design an electronic controller that would not only control the compressor/fan, but also implement the added features mentioned in the first section of this article. This was an attractive option for me, as I have done several IoT projects lately, and this seemed a good fit for IoT.

THE CONTROL ELECTRONICS
I wanted the dehumidifier to be controlled wirelessly, and I figured that the control program, itself, wouldn’t be too involved. I considered using Bluetooth LE, but the control app for my phone or iPad would have involved a lot of programming. In contrast, I had already written a Web-based control/monitoring program for my home’s air exchanger (Heat Recovery Ventilator) that ran on Espressif Systems’ ESP32 microcontroller (MCU). This program was written and programmed into the MCU using the Arduino IDE. Being Web-based, it didn’t require a custom app on the iPhone/iPad, just a Web browser. Both projects called for a Web-based interface that displayed 24-hour time slots configured by the user, along with several other similar control parameters. Figure 2 is a screen capture of the unit’s Web page, showing the time-slot matrix in the middle.

— ADVERTISMENT—

Advertise Here

FIGURE 2 – Screen capture of the controller’s webpage. The time-slot matrix is in the center, and the other parameters are displayed below and above it.

The hardware requirements for this project were such that the less-expensive ESP8266 would work just as well as an ESP32. Adapting my ESP32-based air exchanger control program to this project wasn’t overly difficult. Programming for either Espressif device is very similar, though you must include different libraries in some cases.

The sensors that I needed for the project are itemized as follow:

1) Humidity sensor. I am using a Silicon Labs Si7021 humidity/temperature sensor. It’s inexpensive, uses the I2C interface, and there is an Arduino library for it.
2) Evaporator temperature sensor. This is what replaces the mechanical thermostat found in the original dehumidifier. I chose a simple 10kΩ thermistor, which can be measured using the single ADC input on the ESP8266. You can see it attached to the evaporator in Figure 1a.
3) “Tank-full” sensor. This condition in the dehumidifier was handled by a float coupled to a SPDT microswitch. I stuck with this design and monitored the switch state with a GPIO pin on the ESP8266.

For control, I used the following:

1) To switch the compressor on/off I used a small but high-current capacity TE Connectivity (P&B) RZF1-1A4-L005 relay. This is rated for 16A continuous duty.
2) I chose an Omron G5SB-1A4 relay for the fan. In the original design, the compressor and fan were connected in parallel and turned on/off simultaneously, but I did things differently here for reasons discussed later.

For the “tank-full” alarm condition, I added a few features. First, I added a piezo buzzer, which beeps on/off every few seconds when the tank is full. The tank float switch is “activated” when the tank is not full—that is, when the float is hanging in mid-air. Therefore, the N.O. contacts of the SPDT float switch are used to provide a ground return for the two 2N3904 transistors (T1 and T2), which power the fan and compressor relays, respectively. This ensures that both the compressor and fan shut off when the tank is full—even if the ESP8266 happened to get “hung.”

The N.C. contacts of the switch contacts are monitored by ESP8266’s GPIO12, allowing the processor to know when the tank is full (when GPIO12 is LOW). It responds to this condition by removing drive to the two relays—double redundancy, since it’s also handled by the float switch, itself, as mentioned earlier. It also sends out a packet to the IFTTT website, which responds to that packet by sending me an email message stating that the tank is full. More on this later.

When the tank is full, the program sits in a loop that produces a beep from the piezo every few seconds. The program no longer responds to incoming Wi-Fi messages trying to access its built-in Web server, since I assume that either the beeping or the email message is enough to get me to go down to the basement to empty the tank and cycle the dehumidifier power off/on to restore normal operation.

I made the piezo alarm loud enough to be noticed only in the basement or on the first floor of the house, but not from the bedroom on the second floor. Because the dehumidifier is programmed to run at night and all-day on weekends, the chances were high that the alarm would start beeping sometime at night, when we didn’t want to be awakened. I check my emails first thing in the morning, so I know if the tank is full as soon as I get up.

Given the Web-based user interface, I could have gotten away without any display on the dehumidifier, itself. However, things don’t always work as expected. The possibility exists that the ESP8266 might not connect successfully to my Wi-Fi router, or it might not be able to resolve the address of the NTP server that I use to set the system’s Real-time Clock. Possibly, the ESP8266 won’t receive the time packet returned by the NTP server. Maybe the humidity sensor isn’t responding to I2C commands.

If any of these error conditions occur, they are displayed on a 4-digit LED display that I have included in the design. Other than the possible error indication, the display normally shows the relative humidity in the room. The LED display is sold by Adafruit, and it’s interfaced to the MCU via the I2C bus (as is the Si7021 humidity/temperature sensor). The ESP8266 doesn’t contain many GPIO pins, so it’s important to use I2C peripherals whenever possible.

MODULAR SOLUTION
The components mention so far, together with other required circuitry, are shown in Figure 3. The ESP8266 device that I used is contained on an Adafruit Huzzah ESP8266 breakout module. It’s a bit more expensive than a bare ESP8266 module, but it contains a 3.3V LDO regulator, two switches to put it into programming mode and a few other necessary “glue” components. More importantly, it uses a 0.1” pin footprint, allowing me to mount it easily on a Vector board, rather than designing a custom PCB.

FIGURE 3 – Schematic of the controller. The ESP8266 MCU on the Huzzah module does all the control/monitoring/Wi-Fi functions.

Unlike the Adafruit ESP32 modules that I have also used, the ESP8266 Huzzah doesn’t contain a USB-Serial bridge chip (for programming/debugging purposes). Therefore, you must use a USB-Serial cable, such as the FTDI Serial TTL-232 USB cable (also sold by Adafruit) for programming/debugging.

Figure 4 is a photo of the finished control board. I chose a Hi-Link 5V 600 mA power module, due to its small size and low price. It is a switching power supply, so I added a 2,200µF reservoir capacitor to keep the 5V from dropping too much when the compressor starts up. The 5V powers the relays and piezo buzzer directly. The ESP8266 Huzzah module is powered by 5V via its V+ pin. It contains its own 3.3V regulator, which powers the ESP8266 chip, itself. The LDO regulator can handle about 250mA of external load. I power both I2C peripherals: the Si7021 and LED display from the Huzzah’s 3V pin (actually 3.3V). I intentionally program the LED display at a low-intensity setting (still perfectly readable), to keep the current draw low enough for the Huzzah’s regulator to handle easily.

FIGURE 4 – lose-up of the controller. The Huzzah ESP8266 module is mounted in a socket. The black item to the right is the AM2320 Humidity/temperature sensor.

I recall that my dehumidifier once had a sticker on the tank with a graph showing the temperature/humidity range under which the unit would work efficiently. However, that peeled off years ago. That graph was just a guideline. For it to be useful, you had to know the humidity somehow and turn the unit on/off manually.

— ADVERTISMENT—

Advertise Here

After doing some research, I found some data on the Internet on extraction rate vs. temperature/humidity for a modern, 14 liter/ day dehumidifier. I’ve plotted these data in Figure 5. While one could set any arbitrary lower threshold for liter/day efficiency, I decided that 5 liter per day—out of a unit rated for 14 liter/day—would be the lowest reasonable value. From the graph, you can see that at 10˚C, the humidity would need to be greater than 80% for the unit to run efficiently. At 20°C, this drops to about 38%. In my basement, it never exceeds 25°C, so I don’t consider this situation.

FIGURE 5 – This graph shows the extraction rate of a 14 liter/day dehumidifier at 40% and 80% humidity. The dotted red line is a 5 liter/day lower threshold of efficiency that I chose to use in the controller algorithm.

In the ESP8266 program, whenever the time-of-day time slot indicates that half-price electricity is available, and the humidity is above the user-entered setpoint, the unit will run—but only if room conditions are in a range where the graph indicates that running it is worthwhile.

ESP8266 FIRMWARE
To be honest, programming the Web-based control software for my earlier Heat Exchanger controller project was a lot of work. I started out designing that controller around an Arduino Uno (Atmel (Microchip) Mega328-based) and a Wi-Fi shield. Before I got the whole Web-server stack running, I ran out of SRAM memory space in the Mega328, and had to start over with an Arduino Mega2560 board. Later, I replaced that design with one based on an Espressif ESP32. Having this Web-server firmware already written, it meant less of a programming effort was needed to get this project operational.

In order to run, the Si7021 humidity/temperature sensor needs Adafruit libraries to be included in the program. A link to this procedure is here.

Here’s an overview of how the program works. First, there are several classes that must be instantiated:

WiFiUDP. This class handles the UDP messaging to/from the NTP server.
Adafruit_7segment. This class library handles the 4-character I2C LED display.
Adafruit_Si7021. This class library handles the reading of the humidity/temperature data from the Si7021 sensor.
WiFiServer. This class handles the controller’s Web-server tasks.
WiFiClient. Same as above.
WiFiClientSecure. This is a secure Wi-Fi client needed to interact with the IFTTT cloud server.

Next, the setup() routine runs. The LED display is initialized and tested using an “8888” display for a few seconds. All the GPIO lines are configured, and then the EEPROM subsystem is initialized. Connection is then made with the Wi-Fi access point. The Wi-Fi SSID and passphrase must be defined in lines 48,49 of the code. Next, I start up the ESP8266 mDNS server, which allows me to access the controller from my iPad using the URL “esp8266.local.” Without this, I would have to know the actual IP address of the controller. I can set up my Wi-Fi router to assign a fixed IP number to any device that uses DHCP, but it’s easier all around to just use the mDNS service and access the controller by name. You don’t have to use the name “esp8266.local.” You can assign a different name on line 53 of the program. Note that the “.local” part is not used here—it’s implied.

Next, we must contact an NTP server (Network Time Protocol) to initialize the Real-time Clock (RTC). I’ve been stung in the past by designating the fixed IP number of a common NTP server in my program. Oddly, the IP numbers of these large NTP servers seem to change frequently. In this program, I designate the NTP server as “time.nist.gov” on Line 58, and use this function to get its current IP number:

WiFi.hostByName(timeServer, timeServerIP);

The last things done in the setup() routine are to start up the Web server, and access the EEPROM to load in the user-set humidity setpoint.

After setup, the program enters the loop() structure, where it iterates repeatedly until the unit is powered down. The loop() function contains the following basic functions:

1) Checks the water-level switch for a “tank-full” condition. If full, sounds the beeper and sends an IFTTT message saying that the tank is full. More on IFTTT later.
2) Once per minute, executes the ControlLoop() function, which I’ll describe in more detail later.
3) Prints out all relevant parameters/co
ditions via the serial port, for debug purposes.
4) Checks the Wi-Fi connection, and if it has been disrupted, shuts off the compressor/fan and tries to re-establish it.
5) Once per hour, checks the time-slot array and determines whether the unit should be active or not for the next hour. Every hour, runs the DetermineEfficiency() routine to monitor the temperature and humidity, and decides whether conditions are such that the unit can operate efficiently (Figure 5).
6) Once per day, at 1400 hours, re-connects to the NTP server and re-synchronizes the ESP8266’s RTC.
7) Checks for incoming messages from a Web client (initiated by the user accessing the ESP8266.local URL in a Web-browser). If found, serves up the webpage shown in Figure 2 (filled in with current parameters). Then checks for the presence of parameters that the user may have entered into the three windows or five buttons on the page, and sets the appropriate SRAM variables.
8) Toggles a panel LED on and off- to act as a “heartbeat” indicating that the software is running properly.

THE CONTROL LOOP
This routine takes the humidity/temperature sensor readings and decides whether to activate the compressor and fan. The humidity reading is compared to the humidity setpoint, and if the humidity is above setpoint, it activates the compressor. However, this only happens if the current time falls into a time slot that is user-programmed as being an active one. In my case, electricity is half-price between 11 PM and 7 AM every day, so those eight time slots are set to “active.” Alternately, if it is during the weekend (also half-price) the unit is active 24 hours a day, for both days. Overriding the above decision process, if the temperature and humidity fall outside the efficient range (from Figure 5), the unit will not run.

For test purposes more than anything else, I include an OVERRIDE button on the webpage. This allows me to set the unit’s “active” status to the true state, regardless of the time of day or day of the week. I set this override interval as 5 hours, but this can be changed in line 45 of the program.

There is one important consideration that complicates the operation of the control-loop routine. The refrigeration function of the dehumidifier is performed by a compressor, evaporator coil, compressor coil and a pressure-reducing device. The pressure-reducing device is merely a capillary tube. The compressor takes the incoming Freon gas, pressurizes it and pumps it through the condenser coil. The gas condenses in the condenser coil. At the end of the condenser coil is the capillary tube, which takes the liquid Freon at high pressure, and reduces this pressure. This pressure reduction causes the liquid Freon to evaporate in the evaporator coil, thereby cooling the evaporator coil. The gas exiting from the evaporator coil returns to the inlet port of the compressor.

SIDE EFFECT
A side effect of this process occurs when the compressor is switched off. For several minutes, the high pressure developed by the compressor will remain in the condenser coil, until it can slowly bleed off through the capillary tube. The compressors used in refrigerators, A/Cs and dehumidifiers are not designed to start up with this high “head pressure.” They will just stall out if you try to re-start them soon after they are shut off. This stall condition will result in the compressor drawing 4 to 10 times its normal run current. If this were allowed to persist, either a circuit-breaker would trip in your electrical entrance panel, or the compressor windings themselves would fail if it occurred too frequently.

For domestic appliances, a small, cylindrical device is mounted on the side of the compressor, next to the power inlet terminals. These protection devices (called Klixons) interrupt the power to the compressor when either an over-current condition persists for more than a fraction of a second—the normal motor start time—or the compressor case itself over-heats. They are simple devices containing a small bimetallic strip/heater, which opens a switch contact when the bimetallic strip deforms due to heat—from either over-current or a hot compressor case. Even though the compressor is protected by a Klixon, we want to avoid a situation where this protection is needed, since we don’t want high stall current flowing through the compressor relay contacts.

The controller software must therefore keep track of the time when the compressor is turned off, and must wait awhile to let the gas pressure bleed off. I chose an off time of 4 minutes before re-start, which is quite conservative. This 4-minute interval also applies when the controller is first powered up, even though the compressor was not likely running in this case. However, this particular timeout exists in case the user turns the unit off and back on quickly. It would also protect the compressor in the event of a short power interruption.

As mentioned earlier, I don’t switch the compressor and fan simultaneously, for a couple of reasons. First, I was a bit concerned that the starting current of the compressor might be more than the P&B relay could handle. I measured the compressor run current to be 7A, and I know from experience that compressors like this draw about 4 times this current for a fraction of a second, while starting. The P&B relay can handle 16A continuously, but the datasheet didn’t actually specify its rated surge current. Since I didn’t want to push the compressor relay too hard, I decided to switch the fan separately. It draws an amp or so.

Second, I believe that switching the fan and compressor separately allowed me to improve efficiency. I didn’t see any reason for the fan to be running for the first minute after the compressor started, since it would take at least this much time for the evaporator coil to cool down. Similarly, after the compressor shuts off, the coils remain cool for a few minutes, so I leave the fan running for a few extra minutes. I can’t prove this is more efficient, but the compressor relay rating issue mentioned earlier enough reason to implement this split-switching arrangement.

The error codes displayed on the LED display are as follows:

Err1. Can’t find Wi-Fi access point.
Err2. Can’t set up mDNS service.
Err3. Can’t find NTP URL via DNS server.
Err4. Haven’t gotten time packet back from NTP server.
Err5. Can’t find Si7021 Sensor after second I2C scan.

IFTTT (IF THIS, THEN THAT)
This project uses the IFTTT cloud server to send an email message when the water tank is full. The ESP8266 is already connected to the Wi-Fi access point, and it sends out a TCP/IP packet to a specific URL. This URL is assigned uniquely when the user registers with IFTTT. The IFTTT cloud server will respond to this “trigger” by:

1) Sending a TCP/IP packet back to the Huzzah Wi-Fi module, to acknowledge receipt of the original packet sent out by the ESP8266 Huzzah module. This is useful during the debugging phase of the program development.
2) Sending an email message indicating that the dehumidifier tank is full.

Let’s look more closely into the IFTTT cloud service available on the Internet. It’s a free service, which is nice. Its primary use, from looking over the available applets, is to allow people to associate the occurrence of some Internet-based event (the “trigger”) with the generation of one or more Internet-based actions (“services”). The combination of a trigger and one or more services is called an “applet.” You can either write your own applet, or merely use one of hundreds of applets that others have written and posted on the IFTTT website.

When you visit the IFTTT website it’s immediately obvious that most of the applets are centered around social media such as Facebook, Instagram and Twitter. Social media are very popular these days, and the IFTTT cloud service is also very popular. The fact IFTTT is centered on social media activities is why it can be a free service: the users are not really the customers, they are the product. In other words, IFTTT can make money selling the “big data” generated by all the social media events that are captured when they are used in the many IFTTT applets.

I don’t use any social media sites, so whether the big social media companies are profiting from all the information that its users are freely providing it, doesn’t concern me. For this project, the small amount of “non-interesting” data that they’d get from my dehumidifier is of no interest to me, apart from appreciating that I am getting a very useful service for free.

To use IFTTT, you must visit the ifttt.com website and register. Registration is simple. You can register using your Google or Facebook account ID. I have a Google account, so I used that. The IFTTT registration procedure has security features to ensure that random people can’t set up IFTTT apps in your name—assuming they knew your Google credentials. During registration, they will send you an email message which you must respond to properly, to verify that you are actually the person that is attempting to set up the account. Like most websites these days, the IFTTT website uses cookies, so when you visit the website later, it will recognize you and you’ll be automatically logged in.

SET-UP PROCEDURE
I am going to briefly cover the procedure needed to set up your IFTTT applet for this project. However, I did not “invent this wheel” myself. I found an online tutorial that explained how to use IFTTT in detail. This tutorial describes how to send SMS messages, but sending an email is similar. I had used this feature about 6 months earlier in a Wi-Fi water-leak detector, and my IFTTT applet for that project was still working. In fact, it saved me a bundle of money when it alerted me to a small leak that had developed in a pipe in my basement.

Once registered with IFTTT, search for the email applet. You will have to enter your email address. Here again, there is security to ensure that some rogue individual doesn’t write an applet that floods you with email messages. After you enter your email address, IFTTT will send you an email message with an ID number that you must re-enter into the webpage that you have just used to register your email account.After you have set up the action that you want performed, you must then set up the “trigger” that initiates it. To do this, you use the “Webhooks” applet, so search for that. Then press the Connect button and you will see a screen like the one shown in Figure 6. Notice the long URL that is displayed. (I have hidden the last few digits of the personal ID part at the end of this URL.) It is a template of your personal URL at IFTTT that must be accessed by the ESP8266. Note that in my program, the first section of the URL
(https://maker.ifttt.com ) is assigned to the const char* host, which is used by the sclient.connect(host,httpsPort) routine (Line 784). The rest of the line from /use/ onwards must be customized for your applet, as described later.

FIGURE 6 – This shows a sample of the IFTTT Webhooks settings. The long alphanumeric ID string (partially redacted because it’s my ID) must be placed in the controller firmware, as detailed in the article.

Also, note that if you hit the “Edit Connection” button, it will generate a new URL. If you have already embedded the existing one in your program code, don’t hit this button! It will generate a new URL, and you can’t revert to the old one!

You have now created a custom “service” applet and a custom “trigger” applet. You must link or “sync” the trigger and services together in your own custom applet. To do this, navigate to My Applets -> New Applet. You will see a screen as shown in Figure 7a. Here it is a bit confusing. To choose the trigger event, click on the blue “+” icon, search for the Webhooks applet and choose “receive a web request.” You then must name this trigger with an event name—something that is meaningful to you (and will be used later).

FIGURE 7 – (a) To define the “trigger” for your IFTTT applet, you press the blue “+” icon shown here. This isn’t immediately obvious to the first-time user. (b) To define the “action” or service for your IFTTT applet, you press the blue “+” icon.

Next, you must add the service that you want to have performed. You will see the screen shown in Figure 7b, and this time click on the blue “+” icon next to “that”. Search for the email icon, and fill out the “message box” as you would like the email message to read, then click “Create Action.”

At this point, you are basically finished setting up the IFTTT service. You will see a block describing your applet. Make sure that you have toggled the applet ON.

The only thing remaining is to determine the format of the message that the ESP8266 must send to your personal IFTTT URL (as mentioned earlier). When you are on the Webhooks page, you will see a button marked “Documentation.” When you click on it, you will see the format of the message that the ESP8266 must send. In the URL, where the {event} appears, replace this with the event name that you chose earlier—when you were configuring the Webhooks applet. You can test the triggering of your applet at this point by clicking on “Test it,” after you have done the {event} replacement.

That line of code that you have just seen/edited must be inserted into the ESP8266 program code for the project. If you look at the “sendITFFFmessage() routine in my program , you will find the line:

String url = “/trigger/humidifier tank full/with/key/

That’s followed by the long personal ID string described earlier. You will have to fill in the rest of the URL as I described above in the Document section of the Webhooks service.

When the ESP8266 program code has been customized with your own URL, if you were to perform a call to the “sendIFTTTmessage() routine, at the end of the setup() function, it should send IFTTT the proper packet at the custom URL, and you should receive an email message shortly thereafter. You can also test just the IFTTT applet alone by selecting your applet from “My Applets” and clicking the “Check now” button.

CONCLUSIONS
Where I’m located on the East coast of Canada, I don’t need to run a dehumidifier until mid-summer through fall, when the hot, humid outdoor air gets into the cool basement. At that time, I’ll likely get mildew or mold developing if I don’t lower the humidity.

It was early summer when I developed the project and wrote this article. Even though this dehumidifier is more than 25 years old, the compressor and associated refrigeration components—called the “sealed system” in the trade—are still in good working condition, so I hope that I will get many more years of service out of it.

Figure 8 shows the unit with my new controller tacked onto the front panel. While it’s not pretty, I wanted the controller on the outside, so that its temperature/humidity sensors would get a better sense of the ambient air. The red LED on the right is the “heartbeat” LED, which flashes every second, as long as the program is executing properly.

FIGURE 8 – The unit with the finished controller mounted on the front panel. The red LED to the right is the “heartbeat” LED, described in the main article text.

When I started using the unit in mid-summer, I ran into an issue with the humidity sensing. The humidity value that was displayed when the unit was first powered up correlated well with two other humidity sensors in my house. However, after the fan had been running for 15 minutes or so, the humidity reading would drop by about 20%. This made it useless as a setpoint control sensor.

At first, I blamed it on the low-cost AM2320 sensor that I had originally mounted. However, replacing that with a better Si7021 sensor didn’t improve matters. It seems that the strong airflow from the fan disrupts the sensor’s ability to read properly. I am not sure how commercial dehumidifiers handle this issue. Possibly they just add 20% to the readings, and control the compressor based upon that. I decided to add 6’ of cable to the Si7021 sensor, and placed it at that distance from the unit. That cured the reading discrepancy. I suspect that the AM2320 sensor would have worked fine under those circumstances as well. 

RESOURCES
See article code archive for code for this article.

Setting up the Adafruit library for Si7021 humidity sensor:
https://learn.adafruit.com/adafruit-si7021-temperature-plus-humidity-sensor

Tutorial “How to Send Text Message (SMS) using ESP8266″:
https://circuitdigest.com/microcontroller-projects/sending-sms-using-esp8266

ESP8266 Programming using the Arduino IDE:
https://github.com/esp8266/Arduino

ESP8266 Huzzah module schematic:
https://learn.adafruit.com/adafruit-huzzah-esp8266-breakout/downloads

Adafruit Products-
4-Digit LED display with I2C backpack:
https://www.adafruit.com/?q=878

Si7021 Humidity/Temperature Sensor
https://www.adafruit.com/product/3251

ESP8266 Huzzah Module:
https://www.adafruit.com/product/2471

Adafruit | www.adafruit.com
Espressif Systems | www.espressif.com
FTDI | www.ftdichip.com
Hi-Link | www.hlktech.net
Microchip Technology | www.microchip.com
Omron Electronic Components | www.components.omron.com
Silicon Labs | www.silabs.com
TE Connectivity | www.te.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MARCH 2020 #356 – Get a PDF of the issue


Don't miss out on upcoming issues of Circuit Cellar. Subscribe today!

 
 
Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.


Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Become a Sponsor
+ posts

Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.