I have a question on the Triggers in Rule Machine 4.0. For a temperature related trigger, the text on the screen says "temp becomes" but it appears through testing, it will happen whenever the temp reading reading is above that point. So, a trigger set to >= 80 would happen if the temp was 81 and became 82. This is a little confusing as the text displayed under the trigger says "becomes".
With this very simple RM4.0 rule, it happens if the temp reading goes from 81 to 82 and if it goes from 82 to 83. It would be helpful if this trigger could be changed to allow a 1-time threshold trigger, as the name "becomes" implies. The other option would be an IS trigger. Temp of X IS >= would trigger for all temp readings greater than or equal to. BECOMES = 1 time. IS = Continuous. Just a thought.
Yeah, you can use PB too but it is a PITA. Especially when you have a rule with multiple trigger events and only the temp you want to happen once but the others you want to happen every time. It seems to me like there should be two options. Personally, I like the "becomes" vs "is" but some prefer "single" vs. "continuous" nomenclature. In the end...i'll take either as long as it works.
These words are basically arbitrary stabs at what is going on. A comparison trigger like this is going to fire on every temperature report. Do not read more into the word "becomes". If you want to only trigger something when the temperature becomes 80 but not 81, then why not just use temp = 80, instead of temp >= 80? That will trigger every time the temperature becomes 80. temp >= 80 will trigger every time the temperature is greater than or equal to 80. Each one is going to take a look on every temperature report.
Because a trigger of temp = 80 will never fire if the temp jumps from 79 to 81. If you don't want to implement a single threshold change it can be implemented manually through a Boolean variable. I just figured it would be easier for folks to be able to do it by default through RM.
It's not so much that I "don't want to implement ..." as it is a major departure from the way a trigger event is defined. You'd be doing the same thing with PB as the code would have to do, without gutting RM's trigger definition.
That's fine. But I didn't say you should get rid of the current Trigger, just that it should be renamed. I was talking about adding an additional trigger that had the PB for the trigger event built in. Since the concept already exists in RM, didn't seem like to would be that hard to implement. But I understand.
The trouble with using PB is that there is only one per rule. If you have two triggers that you want handled like a threshold instead of continuous, you'd have to create a Boolean GV. Or, if you're already using PB to restrict the rule, then you're out of luck and have to use a GV. If the option was build in, it would save the trouble. But like I said, maybe I'm the only one.
However, I maintain that the wording is very deceiving. IMHO, it should be "is" and not "becomes". "Becomes" implies that it happens only once and not continuously. Hence my confusion.
I just fell foul of this once again with a lux reading from Darksky. Set up a rule to trigger when lux went equal to or over 1000 and another when it went below 1000. Couldn't understand why they kept triggering. Re-read this post about "becomes". It's certainly misleading and should be renamed "is".
I just tripped down this rabbit hole in trying to simplify my rules (based on the KISS in the latest Habitat webcast.
I thing the nomenclature is very important here. I modified a trigger in my lighting rule from "changed" to "becomes > 70". If I follow the wording then that trigger will ONLY fire when the sensor reports crossing the "70" boundary. As is the case, the rule is firing every time the sensor is reporting. When something "becomes greater than" a threshold, does not mean the same as something "is greater than". So now I've wasted about a fair portion of my morning and will have to restore from backup. Not very happy with this.
Agree too. This has been discussed many times before and I thought Bruce eventually agreed. "Becomes" is a single occurrence. Which is definitely not the right way to describe a sensor sending a status multiple times that it is already at that level.
One more minor quibble with < > and >= <= symbols.
I always have to very carefully think about these and which is which. I am awful at math, and it makes it very tough to remember which way is greater than or less than, even though I can remember being told the alligator (or crocodile) thing 1000 times in the past. I cannot be the only one who is this way with math.
Could these just be plain English and not the symbol please.
