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.
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
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.
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.
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.
I looked into this feature, and it turned out to not be as difficult as I first thought it would be. Basically it's just like any other comparison only with tossing in the increased amount instead of a specific value. This will be in an upcoming release.
