There oughta be an automated dehumidifier.

08 July 2020

Could there be a more exciting topic to start my new blog? Dehumidifiers. Warriors against mold. Not so exciting? Well, I have to start somewhere…

The problem

The use-case for dehumidifiers is rather obvious, isn’t it? There is a room that is too humid, so it need to be dehumidified. In my case it is the rather spacious basement of our house and more specifically the office and hobby rooms in it. It is a rather modern house and since we live in an area with a rather high groundwater level, the cellar has a waterproof concrete tanking and the basement should be perfectly dry.

In the winter, indeed, the relative humidity sinks close to the 40% mark (which is close to being uncomfortably dry). In the summer however, it can easily exceed 60%, which is definitely too high. If this does not surprise you, you can skip the rest of this section. If it does, let me explain how air moisture works.

One cubic meter1 of air can hold a certain amount of water before it condenses. At 20°C this would be 17g. If you add any more water, this additional water can not be added as vapor, but it will condense as a liquid. Relative humidity is just the percentage of maximum water vapor that is in the air. If you look at air at a temperature of 30°C, one cubic meter of air can hold 30g. So, 50% relative humidity at 20°C means that there are 8.64g/m³ water in the air while at 30°C the same relative humidity corresponds to 15g/m³.

And that is the problem in the summer. If it is a hot summer day with 30°C and a moderate relative humidity of 40%2, we have an absolute humidity of 12g/m³. Now if this air gets into my basement, it will sooner or later cool down to the basement temperature of around 20°C. During this process the absolute water vapor in the air remains the same, but for air at 20°C, this is now a relative humidity of whopping 70%! In the winter, the effect is the other way around. Cool air has a very low capacity for water vapor. That’s why we all perceive air from a heater as very dry. It is in fact dry, because at 0°C even 100% relative humidity is only 5g/m³ water. If you just heat it up to 20°C, you get air with 30% relative humidity, which is very uncomfortable.

Dehumidifier to the rescue

So, my basement is rather moist in the summer and, in fact, venting will not help, but would make it even worse. Therefore, I have to use a dehumidifier. The downside is that those consume quite a lot of energy3, so I really only want to run it when the humidity is too high. The model I bought can monitor the humidity itself and automatically turns off/on if it is above or below a certain threshold.

Problem solved, end of story.

Not exactly. I wanted to use this one dehumidifier for two rather large rooms (hobby and office) that are connected by a door. Turns out, that the dehumidifier rapidly lowers the relative humidity in its vicinity, but it takes a while before the air of both rooms mixes. The result was that at some point the dehumidifier rather rapidly switched between on and off4. The humidity dropped below the threshold and the dehumidifier turned off, but because moist air was just waiting in the next room, the humidity rose within minutes above the threshold and triggered the dehumidifier to start again.

So, I decided to automate this thing myself and take into consideration the humidity farther away, in the other room.

Hardware

This is a very simple automation job using a simple rule in openHAB. The dehumidifier can be turned off by simply cutting its power and it gracefully turns back on if the power is restored. So, I only needed a controllable power outlet and, of course, a humidity sensor.

Since this is done in the basement and at that point I only had a Zigbee installation upstairs that could not properly penetrate into the basement, I went for a DECT-based power outlet, because my Router is in the basement and an openHAB binding for the matching IoT devices was readily available:

Image showing a dehumidifier and a power-outlet.
The dehumidifier plugged into the DECT-controlled power-outlet.

The humidity is measured by a Xiaomi Aqara sensor. This actually is a Zigbee device and I use those everywhere in our house. After some testing I found a suitable spot close to the ceiling where it could reliably connect to a Zigbee repeater upstairs.

Image showing a close-up of a Xiaomi sensor.
The Xiaomi Aqara sensor measures the relative humidity in the second room.

For my Zigbee installation I use a “RaspBee” by “dresden electronik” as gateway. The RaspBee is a hat6 for my Raspberry Pi that runs openHAB, so I can also read this sensor with the accompanying openHAB binding.

OpenHAB automation

So, at this point I have two simple items in openHAB. plug_dehumidifier is a simple switch to turn on or off the power outlet and humidity_office yields the relative humidity in the second room, which is the office. I have also added a third item dehumidifier_auto which is not connected to any hardware7, but which I can use to enable or disable the automation. I could now set up a rule that immediately reacts to changes in humidity, but since I want to avoid rapid switching of the dehumidifier8 I went for a time-based rule, that simply checks the humidity every 10 minutes.

1
2
3
4
5
6
7
8
9
10
11
12
rule "Dehumidifier"
when
    Time cron "0 0/10 * * * ?"
then
    if (dehumidifier_auto.state == ON) {
      if (humidity_office.state >= 60 ) {
        plug_dehumidifier.sendCommand(ON)
      } else if (humidity_office.state <= 55) {
        plug_dehumidifier.sendCommand(OFF)
      }
    }
end

This is very simple: The condition for this rule is a cron pattern that triggers every ten minutes (seconds equal zero, minutes are a multiple of ten). When triggered, the rule checks if the automation is actually enabled. If so, a humidity above 60% causes it to start the dehumidifier and a humidity below 55% stops it. However, I need one little additional rule to stop the dehumidifier if I disable the automation. In these cases, I usually want it to stop immediately instead of waiting up to ten minutes9.

1
2
3
4
5
6
rule "Dehumidifier auto"
when
    Item dehumidifier_auto changed from ON to OFF
then
    plug_dehumidifier.sendCommand(OFF)
end

So, if I turn off the automation, the power outlet is switched off immediately.

Alerts

This all is very straightforward. However, if I want to leave the basement rooms unattended for a while, there is one little piece missing. The dehumidifier is not connected to a drain, but it has a tank, which once in a while needs to be emptied. So, the automation would work for a few days until the tank is full at which point the dehumidifier simply stops working. I would have to check it regularly, which makes this rather pointless.

Luckily, the AVM Fritz! DECT 210 can do a little more. It can measure the power consumption of the attached device, which is rather significant. If it is properly running, it easily pulls more than 200W, but if it is in standby, the consumption drops to about 3W. So, I added a third rule supervising the item power_dehumidifier to send me an alert if the power outlet is turned on, but the consumption is lower than expected.

1
2
3
4
5
6
7
8
9
10
rule "Humidifier enabled but not running"
when
    Time cron "0 0/10 * * * ?"
then
    if (plug_dehumidifier.state == ON
            && power_dehumidifier.maximumSince(now.minusMinutes(10)).state < 10
            && power_dehumidifier.minimumSince(now.minusMinutes(10)).state > 0) {
        sendBroadcastNotification("Warnung: Dehumidifier not running.")
    }
end

Again, I am using a cron trigger every ten minutes. In this case, the problem is that not every situation with low consumption is a full tank. In fact, after turning on the dehumidifier, it has a “cool-down” period of two minutes before it even starts and the same is true after emptying the tank. So, instead of just checking the current power consumption, I check the maximum power consumption of the past ten minutes (it might have just been turned off because someone emptied the tank before it was full) and I check the minimum power consumption of the past ten minutes (it might have been turned off entirely and is waiting its two minutes). Only if the consumption was below 10W (not running) and above 0W (but still turned on) for ten minutes, the rule will generate a broadcast notification to all members of our household that use the openHAB Cloud.

To be able to check older values in a rule (i.e. using minimumSince and maximumSince) you need to enable persistence in openHAB for this item. In this case a simple everyChange strategy is enough.

Running for about a year now

This setup is actually running for about a year now without needing any updates or fixes. Well, it is a fairly simple setup and for me it is more or less just a simple first article for my blog, but it is one of the simple setups that turned out to be very handy - and maybe someone searching for a simple answer will find the right code snipped here.

By the way, since I had to enable persistence for the power consumption item, I now have a good idea of the dehumidifier usage over the last year.

Plot of the power consumption over time.
The dehumidifier is almost exclusively used in the summer and kicks in less frequently when it gets colder.

You can clearly see that the dehumidifier is not used in winter and that the usage frequency decreases towards December as the absolute humidity of the cold air is lower while the temperature in the basement does not change that much. The gap at the end of August 2019 was a vacation during which I could not empty the tank. However, 2020 is a bit more complicated as I spend almost the entire spring in the office room due to the Covid-19 pandemic. Therefore the office was almost permanently actively heated and I left the automation disabled until the summer.

  1. Yes, this blog uses SI units. Not Gaussian, nor cgs or natural units. Those are nice, but unfamiliar to most readers. Imperial units might be used if they are commonly used for comparison, like screen sizes. Otherwise (and also in these cases) they are just plain silly and should be ignored. 

  2. 40% would feel ok, because the cooling efficiency of sweat depends massively on the relative humidity. Imagine the air was at 100% relative humidity. In this case, your sweat could not evaporate because the air already contains all the water vapor it can take. The less humidity in the air, the faster your sweat evaporates, which in turn cools your body. Whether summer heat is bearable depends a lot on air humidity. 

  3. For someone who does not R/C cool the building down to 15°C. 

  4. Rapidly for a dehumidifier. It has a cool-down period of 2 minutes, so it would probably not harm the dehumidifier, but it was still rather inefficient. 

  5. This is actually an outdoor version. The price was almost the same as the indoor version, so I thought I might as well get this one. 

  6. Or is it a “bonnet”? In the meantime I switched to the USB stick “ConBee II” anyways… 

  7. i.e. not connected to a thing in openHAB terminology. 

  8. This is actually very unlikely, especially as I added a hysteresis (start above 60%, stop below 55%) to the rule. Also the sensor usually does not update too often. 

  9. Usually in cases when the noise of the dehumidifier annoys me as I want to use one of the rooms.