I come back with this topic again, as I’m still experiencing challenges with two very simple routines I have to turn on a dehumdifier when a certain humidity measurement is reached, and turn it off when that humidity drops to a particular point. The routines are that simple.
In the three or so months that I’ve had these routines in place, they’ve failed to activate about 10-12 times. The dehumidifer cycles between 15 and 20 times per day. I will either find the dehumdifier running well beyond its setpoint or failing to turn on and humidity in the space goes way up.
This continues to surprise me. In the 9 years I’ve been using Smartthings for lighting automation, the only time I’ve experienced glitches were with platform outages. Otherwise, my outdoor lights have turned on reliably at sunset and off at 10pm for years. I can’t think of a time when I’ve said, “it’s past sunset, why haven’t my lights turned on?” Nor have I ever had the experience where I’ve woken up at midnight to find the lights still on.
Why is it that my lighting automations have seemed incredibly reliable compared to my humidity automations? Is it the fact that the lights turn on and off only once per day, while the dehumidifier is being controlled every hour? Is it the fact that lighting is based on time while humidity is based on a sensor measurement? Could it be something different in my mesh between the lighting and humidifier controls?
I’m stumped, and I’m ready to throw away the humidity automations at this point.
I have also had issues at times with my Honeywell Smart Dehumidifier. The on board control cause it to cycle on and off too frequently, so I use the WiFi controls. This year has worked pretty well after a couple years of experimenting.
My dehumidifier actually connects to the SmartLife app and doesn’t integrate with ST, so I had to use the Tuya/SmartLife work around. With the work around I can control it using SmartThings and SharpTools.
I am only using a 1% differential between start (50%) and stop (49%) because my dehumidifier tends to ice up if it runs to long.
I use SharpTools to start the dehumidifier because I want to have a minimum 10 minute cool down period between runs to prevent icing and I could not do it with ST routines. I starts it at 50%.
I use a simple ST routine for shutdown at 49%. The 2nd “Then” is an extra command sent to SmartLife to help ensure shutdown happens if things get out of sync.
I also have simple ST routines to notify me if the humidity drops below 47% or rises above 52% to catch problems.
I also have a power monitoring smartplug on it, so I can quickly tell from SmartThings if it is running or not based on power consumption. I do NOT use the plug for control.
I’ve wanted to try a second OFF command, but Smartthings is smart enough to not let you send two commands to the same device in the same routine.
I’m still struggling with why I need the belt-and-suspenders approach for the dehumidifer but no other routines I have in place for lighting or otherwise.
Use a virtual switch for you second off command and link the virtual switch to your Dehumidifier using a Smart lighting mirror (if it will let you), or if not use 2 ST on/off routines.
I’m not sure how your Routines are written, but one thing that ST lacks that Sharptools does have, is the ability to trigger on just a state change with no state evaluation. In Sharptools, your trigger can simply be “humidity changed” and then in the flow, you can evaluate various states to decide whether an action should occur or not.
Another way to think about your situation is to consider setting up a way to do constant polling of the humidity sensor. This is where a driver like the Edge Counter Utility can come in handy. For example, I use this when my gate or laundry room door are open to check every 15 mins if it is still open. So, as long as the door or gate are open, I get a notification every 15 min. You could do something similar to trigger a check of the value of the humidity sensor every x minutes combined with a precondition of humidity sensor greater than or equal to y to initiate the action(s).
I appreciate all of the suggestions. And I like the counter/timer approach, particularly for notifications.
But I’m still very much hung up on why the routines are not running reliably. Without understanding that, I’m just adding more routines which might be equally unreliable.
For example @h0ckeysk8er - that timer will need to be reset by a routine after a certain period of time. If that reset doesn’t happen, do I need another routine to notify me that the timer didn’t reset? Or another timer routine to check the first timer routine? Where does it end?
It’s not clear where things are breaking down. I can’t tell if the routine is activating but the action signal to the switch just isn’t getting out through the mesh, or if the routine isn’t even activating. I’d love to be able to troubleshoot this further.
My Routines using the counter utility driver are very reliable and work consistently so I don’t have a concern about the counter not being reset every interval or turned off once the gate/door are closed.
To try and help you a little more, can you post the Routine(s) that don’t work consistently?
I don’t have any screen shots but the two at issue are the following:
If Humidity equal to or above 52% turn Dehumidifer ON
If Humidity equal to or below 50% turn Dehumidifer OFF
As simple as that. I’ll either find humidity as high as 55% or higher and Dehumidifer is still off.
Or the opposite - humidity as low as 43% and Dehumidifer has been running for 12 hours straight.
Humidity Sensor and Dehumidifer are in the basement. The Sensor is a zigbee Temp/Humidity sensor (I believe Sonoff), and the Dehumidifer is on a Zooz Z-wave Plus appliance switch.
Do we know the frequency at which the sensor reports its value? For example, if the sensor reports 51% at time x, obviously the Routine will not fire. If it doesn’t report its value again until x+5 minutes, you could observe humidity higher than your trigger value and the dehumidifier would not be running. The excessive on/off times are puzzling.
Have you looked at the history of the sensor values to see if there is some pattern as to when it does/doesn’t work properly? Also, I would do some driver logging to see if the appliance switch is being triggered, but not actually turning on/off. I would probably also do driver logging on the sensor as well to verify that it is reporting accurately and regularly.
Also, is there anything in the Routine that keeps it from running locally on your hub?
I have a number of those. I believe they are configured by the stock driver with a reportable change of 3% and a maximum reporting time of two hours. That seems to be consistent with what I see.
So roughly speaking, the worst case should be the dehumidifier turning on at roughly 55% and/or two hours ‘late’, and turning off at roughly 47 C and/or two hours ‘late’.
That said it should still work if there aren’t any other preconditions and conditions confusing the issue.
I’ve never really looked into how Routines behave at startup with regard to initialising attribute values and whether or not they trigger. It might cause some issues if the Routine is active for up to two hours before if even knows what its initial condition is.
Unfortunately, it is now impossible to debug anything in the event history for temperature, humidity or power. They have filtered the events shown and not all of them are shown, only those that meet the filter condition, which only they know (time??, value increase??) impossible to decipher by observation.
They have also removed the graph of temperature, humidity and power events for the last hour and have left only the daily and monthly ones.
The only reliable thing is the CLI logs, where all the values emitted by the device and the driver emits to the platform are seen, then the filter makes some events invisible in the history.
@mooch91 Have you looked at the app history of the routine execution? If it has been executed, it appears and if not, it does not appear. This way you can filter devices and check if it fails is the transmission of the commands or the execution of the routine.
