Hi,
I have at least two occurrences where I would need a trigger of the form:
Value increased/decreased/changed by more than X.
For example:
if humidity reported increased by more than 10, it means somebody is in the shower, therefore start the fan.
if the sumpump reported power changes by more than 10W, it means it is no longer pumping water, therefore shut it off.
It is possible to do such things by using local variables to register the previous value, but it is very convoluted to do. Would it be possible to add these as options for triggers ?
That isn't a trigger. It is a trigger and a condition.
"If humidity changed by more than 10" Doesn't have a starting reference. There isn't a driver out there that saves the last recorded value that I am aware of. That would be the only way for it to know how much it has changed since the last poll. That is why you you need variables (local or global) or static values to tell it the starting point. This is true even if you are talking about between reporting periods. So, you would need to record a starting value, and then compare that value to the current value no matter what.
I'm confused... how do the existing "changed", "increased", and "decreased" triggers work then, if not by comparing with a previous value internally ? The only way for this kind of triggers to exist is to actually have a previous value somewhere, isn't it ?
For the sump simply add a power monitoring outlet like a zen-15. That said the above is more the way to go because the sump will turn off rather quickly and if you have that turning of your fan it's unlikely to evacuate all the moisture. Doing the 2 sensor way ensures that the bathroom is brought down to the same levels as the rest of the house.
I already have power monitoring, but no way to trigger on by how much it changed. Triggering in any change is not viable, because it can change by very little, but pumping water vs air will make a big difference. That is precisely the point of this post: being able to trigger on Ā« large Ā» changes
Then use the double sensor method so that if changes by a large amount the fan comes on, and when the sump drops it turns the fan off. It doesn't have to be in the same rule.
Double power sensor makes no sense, and what does a fan have to do with a sumppump ?
I would appreciate no more workarounds that require more sensors and rules more complex than they can be. If Hubitat has triggers on changed, increased and decreased, then it compares against a previous value, and therefore it should be possible to have triggers based on how much it changed
In your original method you want the fan to turn on when someone is in the shower. Use the change in humidity compared to a hallway (where the second sensor is) to turn on the fan.
Then you say you want the fan to turn off when the sump changes power by 10w. You can do this simply with a second rule similar to using the 1 humidity sensor but with the outlet. The monitored outlet will show the sump on (which will be at a minimum draw) simply use anything less than that draw as a signal to turn off the fan. If it's going off and on simply add a wait time to the rule..
I said I want the sump pump to turn off when itās no longer pumping water. Has nothing to do with the fan. Thereās no fan or humidity or whatever involved in the pump. Itās just the pump and how much power it draws.
I read that wrong then. The way you wrote it you wanted to turn off the fan with the sump. At that point simply note the minimum draw on the sump when pumping water and write the rule as pump changes as trigger then if power <less than minimium when pumping water, turn off.
I am trying to help. If you feel it's not, I'll bow out now,. I'm giving you the basics but how am I supposed to know it's not alone on the circuit. Good luck...
Nobody has answered of a reason why itās not possible to have a threshold for the size of the change. Again, if Hubitat can trigger on change, increase or decrease, it means it is comparing against a previous value. There is necessarily a previous value somewhere internally, that is accessible to Hubitat, but somehow not accessible to the end user.
Fair question. I am not certain how relative increase/decrease is determined without having both previous and current value.
You will find that the community is full of problem-solvers. Some folks will want to solve the academic problem of how relative triggers work. Others will want to solve the underlying problem of having a rule that provides the desired behavior. The friction tends to occur if you insist that a problem be solved in a very specific manner - it doesn't compute in most of our minds.
Without having read all the posts in between.... (sometimes dangerous)....
What I expect others have tried to explain is that a trigger for a rule is an event, a moment in time where the state of a device moves from one state to another. So a switch moves from being on to off, off to on, or indeed either of those (referred to as changed). I would re-iterate this is a moment in time when this state change happens. That is what triggers the rule.
Once you introduce a comparison into the mix, the increased by....
Actually, it depends on what exactly you are referring to when you say increased by.... Do you mean the increase occurs between two readings the HE hub receives? In that case, I could understand the request. If you want the increase to have occurred over a period of time, I expect that is less likely to get accepted.
This may need to be confirmed, if it hasn't been already...
I'd also add.... If you are looking at humidity in particular, there are a few Community Apps that may be of interest. I personally use the Smarter Humidity Fan App.
I see now you have various uses, hopefully someone will get a use out of the Smarter Humidity Fan reference...
My point still comes back to whether you are interested in the difference in a single state change. If not, then I expect the approach taken by apps like the Smarter Humidity Fan to detect significant changes in a short period are likely what you are after. Whether these should be built in... That could be debated... Though I tend to lean towards some kind of built-in feature.... It may not fit within the current event-driven model exactly, but there are genuine use-cases which means it makes sense (to me) to build something re-usable. Exactly where that fits... not sure...
Increased/decreased can be made relative to a variable or another device. [EDIT: strictly speaking, increased/decreased can't be relative to other things, but you can use ">" or "<" ]. What I understand is you want difference relative to the device itself, as RM appears to be able to make such a comparison.
Perhaps only @bravenel can answer that question definitively.
However I wonder if there would be a material difference (in terms of perf - obviously a bit more work/maintenance) of just triggering on "changed", doing the comparison and updating a variable or virtual device in the actions.
