I've created a rule for my bathroom fan using a humidity sensor but I feel like the available Trigger options under 'Comparison*' are missing something like a 'Rate of rise/fall' otherwise you'll have to keep changing the humidity figure as the weather changes which isn't feasible.
It's like the Sunrise/Sunset feature which is handy as those times change pretty much daily so something like that should be available for the humidity/Comparison options.
I ended up using a community based app for bathroom fans to turn the fan on as it has the 'Rate of rise/fall' option then I used a Basic Rule to handle the 'turn off' part based on a contact sensor.
If you are "fixing" not equal, could you spell out the other symbols in plain English please? I have seen a few posts over the years asking what those mean. It sounds silly to have to explain it, but not everyone uses those every day.
I wonder for accessibility how just the symbols would affect someone with dyslexia or someone using a screen reader? And just for consistency, shouldn't they match the other selections?
I had thought about offering the suggestion of using words, but felt that may be harder for those who don't speak English.... But maybe it can be managed....
Accessibility aside, I have to wonder that if you don't know what <= means you probably have no business trying to use it. This stuff is taught in middle school. RM is an advanced user app. So there is an inherent contradiction in your request. This is the usage context at stake:
Are you seriously suggesting that is incomprehensible to some users who could otherwise understand the concept of comparison? I'm sorry, but this is not happening and I don't think it's a reasonable suggestion.
@bravenel Would you consider my suggestion to implement a 'Rate of rise/fall' for the humidity trigger? As I mentioned on my original post, humidity changes every day (I am in Australia) so it's hard to pick an accurate value for the trigger. I did try picking a higher values so that the fan wouldn't get turned on unnecessarily but it took too long for the the sensor (konke) to update the humidity level twice before it could reach the trigger point (bathroom turned into a sauna before the fan kicked in).
@hpgurgel I don't see rate of change becoming an RM feature, as it's pretty full up and too complex already. You can trigger on *increased* or *decreased*. The event value can be put into a variable, and math done to come up with rate of change... Not simple, I know, but doable.
I've created a rule for my bathroom fan using a humidity sensor but I feel like the available Trigger options under 'Comparison*' are missing something like a 'Rate of rise/fall' otherwise you'll have to keep changing the humidity figure as the weather changes which isn't feasible.
I did try picking higher values so that the fan wouldn't get turned on unnecessarily but it took too long for the sensor (konke) to update the humidity level twice before it could reach the trigger point (bathroom turned into a sauna before the fan kicked in).
It's like the Sunrise/Sunset feature which is handy as those times change pretty much daily so something like that ('Rate of rise/fall') should be available for the humidity/Comparison options.
I ended up using a community based app for bathroom fans to turn the fan on as it has the 'Rate of rise/fall' option then I used a Basic Rule to handle the 'turn off' part based on a contact sensor.
Would you guys consider implementing the above please?
Just spitballing here, but if you created a rule that was triggered on every change of humdity reading by the device(s) to calculate your rise/fall rate and store it in a hub variable. And then use a second rule to trigger when that variable crossed your boundary would that give you what you need?
I never quite got my head around variables so perhaps it's a good opportunity to learn now - I've made it work with the below app so I am not in a rush at the moment, I might look at look variables on the weekend.
One way or another, the previous values have to be remembered, and then math done with the new value and elapsed time, to come up with rate of change. Do it on paper to figure out the steps. Then you can figure out from there how to put those values into variables, and what the math steps need to be. The problem for RM to do internally is that this is not a simple calculation at all, and requires remembering a lot of information.
By comparison, to come up with *increased* it just has to compare the new value to the prior value. Once it supported *changed*, *increased* and *decreased* came very cheaply using the same remembered value. Comparing two values is a core function of RM, but remembering information for complex calculations is not and can be done already by other means.
By the way, the in operator allows a range of values, to test if the event value is within a range, as opposed to > or < some specific value. That might help this case.
