Hi, I am also looking into upsmarting a dehumidifer.
I want at least the possibilty to control on/off from Home Assistant to use it in automations.
I found on Amazon an Aeocky ARION-001 and in a user review this schematic was posted.
Do you think this device has potential for making in smart. The WIFI PCB option sounds promising.
Alternative would be to use a smart plug, but I don’t like that way of cutting the power in a hard way with a compressor. Probably not to healthy for it in the long run.
I spy CN2 with the following pins clearly marked TXD, RXD, O, 5V which would tend to indicate a possible 5v TTL serial interface to explore. Over to the right there is also TX1, RX1, 5V and 0 with the connector already soldered. Would be very curious to know what the numbers are on that multi-legged chip on that board.
Heads up before you dive in: Please remember an ESP32 is only rated for 3.3v, and TX goes to RX, and RX to TX, for when you connect your isolated USB serial port for decoding. The resistors and driver transistors @tom_l used are for voltage translation. I note this thread was started five years ago - the chances of any recent WiFi device containing a Tuya based SOC are very high.
Where is that mentioned? The FCCID website has no mention of any WiFi capability for that device, something you would expect for a popular device. Any indication or photos that show where it would be connected?
You might be making it harder than it needs to be.
Many of the cheap dehumidifier’s do an awful job of efficiently controlling humidity and frequently have an early death because of it.
I got a dehumidifier that has some memory and will auto start after a power failure. I have it configured to keep the humidity very low and control it with an external power plug. I have a separate device(s) that measure humidity.
My goal is to keep the average humidity in the basement reasonable. I have a NodeRED function that looks at the average humidity over the last hour. When that gets too high, it turns on the dehumidifier. When the average gets somewhat below the set point, it turns off the dehumidifier.
All compressor based devices have a delay before they will turn on the compressor (power failure fail safe) so my control system doesn’t add extra delay (though it would be easy to add).
My current dehumidifier is over 8 years old. Previous one lasted a year or two at most. I used to depend on their control systems. They tried too hard to keep the humidity constant and would cycle on/off frequently. That is very hard on the compressor and inefficient too.
There is a humorous review of the dehumidifier on reddit, but it looks decent. I didn’t find any WiFi boards for it, so it will be a project to get that to work assuming they even implemented any control.
Reviews on Amazon say it has auto start on power failure and remembers settings so should be good to control with external power plug.
hOme labs 70 pint one, but they don’t make the exact same one anymore.
The one you are looking at looks decent.
The ratings on dehumidifiers used to be exaggerated to say the least, so the 70 pint one (old rules) is probably about a 25-35 pint one (new rules).
The old rules allowed measuring at 90+% humidity at 80°. That is much easier than more normal humidity and temperature.
The key to a long life is not too many start/stops of the compressor (AND a good design AND manufacturing). That is why I do the one hour averaging and minimum run time.
I would like to borrow your idea here. Could you help share how the automation looks like, regardless it is in NodeRED or in HA automation? I’m like to learn how this logic works.
Not cheap indeed. How many hours they are running per day (on average in the summer)?
Yes, I noticed that. In the beginning I set the target humidity to lowest setting (40%) and it was constantly running, only every 8 hour was short cycle.
Two days later I changed it to 50% and then it started to constantly cycling.
So if I understand it right, the best approach would be, set it to constant max power and cycle it manually with a power plug and an automation depending on an external humidity sensor.
One question I have on my mind.
Is it bad for the compressor if the power plug cuts the power in the midst of its operation? Isn’t this preventing some shutdown procedures?
Or is this not relevant, as long as there is a long enough pause between the power cycles?
Agree with simplicity. My overall requirement is the same, keep the basement from getting musty. I have a standard off-the-shelf dehumidifier sized for the space. It plugs into an on/off module I control with a carefully placed humidity sensor and yaml.
That seems like a lot for something that the dehumidifier could do that on its own other than measuring humidity where its most important, but I have one more requirement: Between 3pm - 7pm weekdays my power provider enforces significantly higher pricing per kwatt, its much more expensive to run the dehumidifier then.
The logic is:
manage on/off of the unit with a couple % hysteresis to avoid rapid cycling
No matter what, its off 3pm - 7pm weekdays and it can catch up after that.
It actually could be. Depends on how it’s designed.
What about doing it somewhere between, try to set it the way it’s still cycling but not often. Then control the “custom cycles” turning it off only when your PM plug sees compressor off cycle.
What do you think the humidistat in the dehumidifier does?
Mine turns off the compressor while it is running, whenever the hygrometer says the humidity is low enough. It does leave the fan on for 30s or so. This has the disadvantage of increasing the humidity, since it evaporates some of the water that it just condensed.
The thing you do not want to do is turn off a compressor and then immediately turn it back on again, which is why most have a timer to prevent you from doing that. The reason you don’t want to do that is many motors don’t have the starting torque necessary to do it. Letting the system settle means the motor sees a more normal starting torque.
The technique I use minimizes the reintroduction of moisture that was just condensed, so slightly more efficient. It’s been working well for me for almost a decade, so I am going to stick with it. You need to decide for yourself if you want to try it or not.
I have heard of some dehumidifiers that use a more old school approach and run the compressor for longer. It all depends on your goal. My goal is keep the average humidity low enough to avoid problems. Reasonably short excursions above the target are fine. I shoot for a minimum run time of 30 min. It typically takes 5 to 10 minutes to start condensing water so I want to stay at the efficient state for most of the period (to increase overall efficiency of removing humidity).
What does your automation look like, to ensure minimum run time? Could you share the yaml of your automation, as an example? I want to achieve the same but not sure how.
It has what you need and seems easy enough to understand.
esphome has the climate control and bang bang controller that say they can be used for humidity, but the names are all temperature so it could be confusing.
Many people here feel the control should all be on one device. I like using power plugs that can measure power. All of those are dangerous to use with external sensors, so I am okay with having my control and sensing separate. The way my system is setup many things have to be working correctly for the control to work correctly. This generally works fine. If it doesn’t, the consequences are the humidity in my basement rises. I will generally notice that before it is a real problem. It was years before I decided to get a dehumidifier, so not a real problem, more of a nice to have.
I have a sensor (I actually have many, but use an SHT15 that is on the other side of the room) for control. It publishes a new value every 30s.
I have an automation in NodeRED that sees the MQTT post, waits 5s (to give InfluxDB time to process it) and then queries the database to get the average for the last hour.
I have a maxHumid set point: 57
I have a humidDelta: 3
If the avgHumid is greater than maxHumid, it turns on the dehumidifer.
If the avgHumid is less than maxHumid - humidDelta, it rurns off the dehumidifier.
Since it is using the 1 hour average and a delta, the humidifer doesn’t short cycle.
Here is a nice graph from last year that shows the startup of the dehumidifier after I fixed the automation that had been broken for many months (since I moved some computers around).
at 13:50 the automation turned on the power and you can see the fan running (72W) and then the compressor ramping up as pressure builds. It takes about 5min before it is fully working.
At 15:55 the automation turned off the dehumidifier. Notice how quickly the humidity ramps up. The yellow line is from the sensor across the room. The green line is the sensor at the input of the dehumidifier. (I have a sensor at the output, but that really isn’t helpful and that sensor now has a permanent shift.
At 16:42 the automation decided to power on the dehumidifier. Again you can see the fan turn on. This also highlights why I cut the power and don’t want the fan to run. It has been over 45 min since the dehumidifier last shut down. Yet, you can see the humidity in the room rise by almost 5% from left over water that hasn’t drained out yet. But, as soon as the compressor ramps up and cools the evaporator the humidity starts dropping fairly quickly.
So, if you want close humidity control it will be difficult and expensive. If you want efficiency, you have to accept that there will be a decent swing as the compressor cycles on and off.
