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.
3 Likes
Which brings up an interesting question - are there any recommendations for sensor settings? My ZSE11 exposes "Humidity Change Report" threshold in Hubitat and defaults to 5%, which I changed to 1%. My other Zooz sensor exposes a reporting interval as well. Since these settings affect battery life there may not be a good universal value, but possibly some additional info in the behavior docs about how tuning affects behavior would be helpful?
Also, a possible feature request would be an option to force the fan on in the Smart Range rather than above the max. This accommodates the situation where the bath/shower fan is shared by the commode. The app controls the fan for humidity, and the relatively short time-out setting controls it for exhausting (ahem) the VOCs.
My use case for the "Disable Smart Mode with switch" is that the outdoor humidity is greater than my reference indoor humidity by more than a few points. If the house is relatively dry and it is raining outside, I don't want to pull in make-up air that is saturated, especially in the cooling season. (Probably a good argument for using Dew Point here.) I am thinking I can make a virtual switch and code a rule to compare readings to toggle it.
Thanks for investing in the app and new features!
I've been running the fork for a while now also. I still have times where I have trouble that I want to hunt down, but need better optics.
I finally got influxdb and grafana up and running, and your preconfigured dashboards have been a great help in learning how things work.
I've started working on an SHF dash view.
I would like push the SHF config parameters (like min and max % for smart zone), min. offset etc, into influxdb so I can use them as graph thresholds to observe the operation over time and look for edge cases. As far as I can see, there's no way to get them in with influxdb logger since its device (and not app config value) driven.
I was digging around to see if there's a way to maybe drive a variable-> connector to get an app config value but didn't come up with anything.
2 Likes
@jtp10181 Just wanted to add that I have been running this for a while now and it works great! During the past winter here in San Antonio, the outdoor humidity, and resulting indoor humidity, varied considerably depending on when the cold fronts came through. Yes, it does get cold here.
Your revised app has done a good job of controlling the humidity in our master bath.
Thanks for all your work! Thanks also to @erniemiller for the base code.
3 Likes
