TBH...just a chart I dug up. This is just a general dew point chart. First column is air temp, first row is RH, everything in between is dew point temp.
1 Like
@jtp10181 just discovering your work and the SHF app tonight. I haven’t dug into any of the code on either version yet but thank you in advance for putting in this work. Do you have any thoughts on using the time since last change to turn off the fan instead of a static target RH, so if the humidity changes < x% in y minutes we can assume we’ve reached some sort of equilibrium and shut off the fan.
@mluck interesting concept of dewpoint. Have you considered referencing absolute humidity instead? Could be useful to monitor the actual amount of water vapor when there are temperature deltas. I’m using this me this successfully to control indoor humidity by only operating my fresh air intake fan in certain outdoor temperature and humidity conditions.
So I think you saying on the decline to look for a low rate of change to determined when it has leveled off? That would not be a bad idea. Might have to have some sort of time out also in case the change becomes low enough to where the sensor stops reporting (due to not enough of a change).
Currently, I feel like my fans are running longer than needed. Especially in my master bath which has a lot of space. It can almost be turned off right away and then we leave the door open, but the app will kick it back on again next time the sensor reports in.
Need to figure something out.
This original app and your fork are well done and work great, but my fan would all-too-often run for too long too... Depending on ambient conditions and the sensor's temperament that day for coming back down, it was frustratingly unpredictable -- but not the fault of the app.
I've tried numerous sensors - nyce, zooz, aeotec and sonoff -- the zooz zse44 has proven to be the steadiest and most consistent performer for me.
Anyway, I ended up creating a time-based rule -- it's been working really well for us, but admittedly requires trial-&-error to figure out the timing periods and humidity spreads that work for your space, etc etc etc.
I use a local variable simply because I don't use the variable outside of this rule.
A couple of safeguards prevent the rule from running back-to-back, or for the full time if an errant high humidity reading comes in.
One vulnerability is that this rule doesn't accommodate 2 showers directly back-to-back, but that's never been an issue for the two of us (no kids).
Anyway, perhaps this example at least gives other folks some alternate ideas to kick around...
I changed line 183 to turn the fan/smart mode off when humidity hits the top of the range instead of bottom.
currentHumidity < maxHumidity
1 Like
Yes this is how I’ve always done it. But, from what I read, it sounds like dew point might be a better metric. Thought it’d be interesting to give it a try. There are a bunch of threads in this community that talk about the merits of dew point as an alternative metric. I’m no expert but check ‘em out if you’re interested.
Which begs one important question:; if the two of you have no kids, then why two showers? Just trying to be a good conservationist 
1 Like
Inference suggests they meant they didn't write the rule for back-to-back showers because it's not a concern for them.
Methinks you missed the joke — or my execution sucked. 
2 Likes
Yessir that’s exactly the approach.
Agreed. A timer as a backstop so you’re not waiting for a sensor update. I had been working to implement that in ST webcore but I think was getting caught up in parallel or nested piston executions which might not be an issue for an HE app.
Nice! Ok will poke around for the Relative vs Absolute vs Dew Point discussions. Thanks for the heads up
And when taking a single shower, back to back seems the least fun option.
1 Like
I see why its doing that, when the app turns off the fan, the app then catches the switch turning off (as if you turned if off manually), and runs the function a second time to shut off smart mode. Not hurting anything but I will check it out when I dig into this app.
How big of a deal would it be to add an option for a backup sensor? I have a ZSE44 and a ZSE40 in each bathroom. I use the ZSE44 since the ZSE40 will prioritize sending motion events. But it'd be nice to select it as a backup device if the primary device has been inactive for a certain amount of time. Even more awesome if it could flip a switch or send a notification when it decides to do this.
Was this ever officially released? Or is the gitpost still the best way to access this version? Thank you!
The gist is the most current still. Its getting closer to the top of my to-do list though! I had taken a little break from coding but picking up again, wrapping up all my lose ends on drivers then going to dive into this app again hopefully. I have been using it this whole time, works pretty good year round for me in the Midwest which has a lot of relative humidity swings.
1 Like
