Triggering Whole House Dehumidifier

I’d like to use W2 to send power to my dehumidifier, in order to lower the humidity in the house. It is a Honeywell Whole House Dehumidifier, so it takes the 24V AC signal just like anything else. Currently its on a Nest Thermostat, and attached to the “*” terminal. I think I can use W2 on the Hestia.

I’ve been poking around, and in the /etc/openhab2/sitemaps/default.sitemap there is a 7 line section for Humidity. I copied that, put it up higher and attached US to it. So now I see the Humidity data. But it feels like this is for adding humidity, not taking it away. Looking through the openHAB config on the device (through the UI), I see “Humidifier Dehumidifier Controls and Settings”, and in that are 3 channels defined: Humidity Mode, Humidity Switch, Humidity Boost Time.

These reference /hestia/local/stat/{humiditymode,humiditystate/power} and the boost I don’t care about. Now, I see /home/pi/scripts has a humiditymode file, but not sure what it does or the in that same directory. I don’t see humiditystate anywhere in the directory tree when using the find command.

I’m still looking for documentation that helps me understand these more, but I wonder if it isn’t too difficult to write up a dehumiditymode and dehumiditystate to power the W2 terminal (whatever that ID might be). Especially since openHAB seems to already have “Humidifer Dehumidifier Controls and Settings” and Hestia is apparently using Humidifer already.

Thoughts? Pointers?

Ah, and there are Items called Humidity (MyHumi) and Humidity (HumidityPin) and Humidity [%.0f %%] (MyHumiProxy) and a few others. Ten items in all that seem relevant for Humidity, and can likely be copied somewhat for DeHumidity is my guess.

In my opinion, the best place to get started on this is the Paper UI, which is at (substituting your HestiaPi’s IP address in for

In OpenHAB, at least in our setup, the Rules are what determines when relays are enabled.

If you look at the Humidity Control rule, you’ll see the general format for a rule, with is basically an if/then/unless statement (in case you’re familiar with programming languages that have the “unless” construct).

The “If…” says when HumidityCtl is fired, which we’ll come back to in just a minute. The “Then…” is the code that is executed. This is worth clicking the gear icon to edit and look at the JS code, which takes a couple seconds to load. Here we can see there’s a HumidityPin defined somewhere. By looking at this code, now you know that you’ll need to figure out what that is and potentially change it.

Next there’s the “but only if…” section which says that this only applies when the SystemType is set to EU. This is a little confusing since the UI says the system types are “Generic” and “HVAC”, but those are listed as “EU” and “US”, respectively, under the hood.

So if HumidityPin is correct, then it looks like this rule pretty much does what you want it to do. You already spotted HumidityPin in the Configuration → Items section, but if you try to edit that, there’s really not much there. So we need to keep looking.

Honestly, I still grep for things when I need to find stuff like this. Grepping /etc/openhab2 on the HestiaPi shows that it is set in ./automation/lib/hestia/defaults.js. This is one of those things that, as far as I know, is never exposed in the web UI anywhere. You also might have noticed the load(OPENHAB_CONF + '/automation/lib/hestia/utils.js'); line in the rule earlier, now you know where to find that utils.js file.

Looking at defaults.js, my guess is that we’ll have to add PIN_MAP.put("US_HumidityPin", "Pin16"); but lets wait to make that change until we see where it’s used. We also see that Pin16 is also mapped to Heating2Pin, which is fine as long as you never turn on second stage heating. I know this because I’ve reviewed the code in the rules related to second stage heating, but you might want to review them as well just before you make changes so you can be confident that this won’t cause trouble. You could also probably remove it, but then things might go wrong that would be very difficult to detect and track down.

The last thing I’ll point you to in order to prepare you for your journey is the Humidity Check rule. If you look at the “Then…” part, you’ll see it ends with events.sendCommand("HumidityCtrl", cmd);. This is what fires the Humidity Control rule.

That should be enough to get you started in tracking down where the code is that you need to change. Just keep going through the rules, grep for things you can’t find as an Item/Thing/Rule, and if you get lost or have questions, post back here and I should get back to you within a few days.

As for other hints that I can think of off the top of my head:

  • HumidityType is “humidify” or “dehumidify” (see the Humidity Type rule for details)
  • Initialization rule is run on boot and kicks off a ton of things (including that HumidityCheck value)
  • Items that are of type Switch should always be a toggle between two things (ON/OFF, US/EU, etc.)
  • Items whose names end in Pin are basically the relay state (or the GPIO pin state, same thing)
  • Items that end in Proxy are generally confusing, but check out this post for more info on those

@jdhoover Were you able to make any progress on this? Were my rambly notes helpful in getting you pointed in the right direction?