Here is my new rule to control hood light:
Trigger "increased by over" is working as expected but "decrease by over" is not triggering rule.
Here is a related log portion from Power Meter device:
Here is a related portion from a rule:
PS.
C-7 HE is on a latest platform 2.3.5.146
Looks like you are running into the documented issue using multiple triggers referring to the same attribute on the same device:
Well, you are 100% correct but logically this makes no sense. This triggering feature is half baked
and to my eyes is next to useless. Now this will require two rules instead of nice and clean single.
The way Rule 5.1 is implemented, given that this is coming from a device event, RM has no a priori way to know which trigger caused it, and has to figure that out. It is not possible for it to know which of the two triggers it should be applying.
So what? Would you rather it work, or be "nice and clean" but not work due to ambiguity? As a complaint, this doesn't make sense.
Actually, two rules would be much cleaner anyway.
Combining multiple rules into a single more complex rule is rarely the right thing to do. This is to focus on the wrong thing (how many rules are in the list), and miss the point that the idea is to have functioning automations, not the fewest number of rules.
Again, this is all about maintainability. This already was mentioned millions time.
I.e. maintaining multiple rules which handles the same logic and taking in account
there is no something like folder for grouping the related rules makes it very hard
to maintain all these related rules (specifically when time is passing).
Yes, I need this working and will use two separate rules instead of one.
Maintainability surely comes second to working.
These two rules would have different logic, one about increase and one about decrease. If the body of the two rules would be the same, then one of them simply runs the other's actions and there is no increase in "maintenance".
Well, I got it working with two simple rules. Sure, this is better than nothing but over time
I will think why do I have two rules instead of just one.
Rule for light On:
and rule for light Off:
This of course, works as expected.
Maybe I used a bit incorrect wording:
Single rule should have logic for turning light On and Off.
But yes, Light On and Light Off logics are different.
These are much simpler than IF-THEN-ELSE-IF of original rule, and also more efficient. Like I said, the urge to combine logic into a single rule is not wise. KISS is wise. Your original rule was not KISS, while these two are.
Maybe if you had designed and implemented Rule Machine you would see it differently. But, having been the one to do that my orientation is always toward KISS solutions, not convoluted complexity. It is the case that RM allows one to do complex things, but allowing that doesn't make it the right thing to do.
I am 10000%+ for this statement!
BTW, I am EE and designing different logic for around 45+ years with different tools and
available components (staring with vacuum tubes and finally now FPGAs and CPUs).
I know very well what the price is when design maintainability was not a priority.
Again, if I can have an ability to keep all related RM rules under one hood many of my
complex rules will be significantly simplified and split into multiple instead of one gigantic.
Attempt to group the related rules with prefixing (my current approach for grouping rules)
in the name works but this makes rule names too long.
Have you considered using emoticons? As they say, a picture is worth a thousand words… I have started using them and am finding that it makes things much more easy to find.
No, I never thought about this option. But Thank You for the idea, I may try it.
How about using something like the Mirror App to mirror a virtual sensor to Range Pw? You can then us Range Pw for increased and the virtual sensor for decreased as triggers. You'd still use Range Pw in both the IF-THEN and ELSE-IF. You'd still have two "rules" but it might be easier to manage.
Thank you for the idea but I already have two very simple rules solution (posted above).
BTW, these two rules are acting as a 2-states State Machine. For many reasons my
preference is State Machine approach vs. complex IF-THEN-ELSE_IF-THEN .... statements.
Unfortunately in RM implementing State Machine requires multiple rules. Basically it is one
rule per each state.
Or, one rule per state transition, using Required Expression.
I rarely use if/then statements in rules anymore, abandoning fewer rules each with significant logical complexity in place of multiple, much simpler automations to accomplish the same tasks.
As my setup has grown increasingly complex over the years I’ve personally found this approach to not only be FAR less resource intensive for my hub but much easier to maintain and most importantly much much simpler and faster to diagnose in the event I need to troubleshoot something.
Big fan of conditional statements and trying to minimize the amount of “thinking“ my hub has to constantly do in the background with well over 100 devices actively connected.
For my curiosity I enabled log on one of my rule which uses “decreased by over” as a trigger.
Here is a little portion of the related log:
Now i am very confused about this statement:
Both triggers should fire a rule but Actions must have an extra logic to figure out the direction
of value change. I am not asking for any changes to the existing RM implementation but simply
thinking loudly.
When a rule is first created, it does not have a "previous" value for a device to compare an event value to, until the first event happens. Perhaps it should store the current value (at the time of rule install or update) of the device attribute in the case of increased or decreased trigger, but it doesn't do so right now. When the second event comes along, it has the previous event value to compare to in order to make the determination as to whether to trigger or not. This only happens once for a new rule, and from then on it has the previous value stored.
When an event happens, where there are multiple triggers on the same device attribute, RM has to find a corresponding trigger when the trigger must be evaluated (e.g, increased or decreased). It does this by looking at each possible trigger until it finds a candidate trigger that matches the device and the attribute of the event. It assumes that the first candidate found is the one to evaluate -- it does not go on to inspect all of the other triggers for multiple candidates. For this reason, having both an increased and a decreased trigger for the same device attribute will fail, because it will see the first trigger in the list, and assume that it has found the one to evaluate.
I've put this in, it will be in a future release. That way it will trigger on the first event, not the second.
Thank you for the explanations and for the differential trigger improvement.
Download the Hubitat app
