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...
1 Like
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.
3 Likes
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...
1 Like
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.
2 Likes
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...
2 Likes
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.
3 Likes
This simple point blew my mind. Once I walked through a scenario in my head, I realized that such a trigger would not behave as desired. Well, at least not reliably.
Consider a sequence of humidity readings: 50, 54, 62, 68, 76, 84, 90%. Most would agree that a vent fan should trigger somewhere in this range. Yet, it would never satisfy the trigger (increase by 10%).
The pump situation is complicated by more variables (which I admit that I do not understand completely). Not sure whether this is a better application for a "direction and magnitude change" trigger.
4 Likes
Same thing for power readings .....
3 Likes
Yes, my interest is in a single state change, not over time. Most sensors only report changes every so often (say, every minute), not continuously. So I expect sudden changes of large amplitudes to be seen as a single event. This is at least what happens with many of the sensors I have, the humidity jumps from say, 50% to 80% in one event, or the power draw from the pump goes from 500W to 480W in one event.
I think the specific use-case is irrelavent (besides trying to offer potentials alternatives) and I see the OPs point. Instead of trying to rationalize our particular use-cases we can just look at the functionality.
I can set a trigger to increased or decreased. That inherently means the hub is looking at the last event for that attribute and current event, and comparing the attribute values. It's even doing the basic math by subtracting them from each other to determine if the value went up (positive number) or the value went down (negative number).
Regardless of the use-case, in theory, it would be one extra line to pull in a user set variable to see if that value difference is above or below the user set threshold.
I'm sure there's more to it than that, but given that we can effectively do the same thing with a device comparison, I don't believe the request is too far fetched. The device comparison presumably has the same logic given that you can give an offset threshold.
diff = Device A - Device B
IF(diff > offsetThreshold) THEN
Trigger rule
END-IF
4 Likes
Exactly. Probably with an absolute value for the diff.
I take your point, and @FriedCheese2006 's, it would not be as simple as just using this trigger / condition, there would likely need to be some consideration to the way the device reports (how often for example), plus the scenario being monitoring and responded to. But it may be useful addition, and hopefully a simple one.
From memory I think this is why the smarter humidity fan app has both a threshold that will trigger turning the fan on as well as the option to detect a rapid increase in humidity, so a gentle rise in humidity can also trigger the fan.
1 Like
You are right that a rule with "changed", "increased", and "decreased" triggers stores the previous value to make the determination as to whether or not to trigger. It doesn't seem to me a feature that has broad use, and it would be fairly complex to add, and it's not difficult to implement with existing features of RM.
What you can do would be to maintain the reference value in a Hub Variable, trigger off the appropriate change, then test the new value against the reference value to decide whether to run the rule or exit, updating the reference value as appropriate.
6 Likes
Sad face. How I wish the Hubitat core would be open source and accepting PRs like HA does (that feature exists in HA, by the way)
Ah, a sure fire way to win friends here and up the prospects of your request ...
1 Like
Don't get me wrong, I understand time is limited, and you mention it is complex, so be it, I accept it won't happen, I just wish I could contribute and help with actual code. I contributed a community zigbee driver for a thermostat and a few items to existing community applications. (as well as numerous non-Hubitat related pieces of software out there).
Not only that, but we are a closed source company. There is a world of difference between what our engineering staff does and dealing with open source. You can't have it both ways. If you want an open source environment, you know where to get that. There must be some reason you're here instead of there, and whatever that is, it's the result of who we are and how we do our engineering.
If wishes were horses....
4 Likes
