How To Get Rule To Fire Once with Temp

Just throwing this out there but how about turning a virtual switch on when temp falls below 32.
Then put the switch 'changed' in your rule as a trigger.
Also, do you want them to turn off if mode is day?

1 Like

@bobbles I thought about a virtual switch instead of boolean but I thought maybe they were pretty much the same. Turn on a switch and then turn it back off or turn on boolean and turn it back off. Not sure. Last IF statement I thought would turn them off? No?

If you have more than Day, Evening, and Night modes, then use this:

IF (Mode in Evening, Night) THEN
   Color Temperature: Deck Light: 5000: 5
   Color Temperature: Front Porch Light: 5000: 25
ELSE-IF (Mode in Day) THEN
    Off: Deck Light, Front Porch Light
END-IF

If you only have Day, Evening, and Night modes, then use this:

IF (Mode in Evening, Night) THEN
   Color Temperature: Deck Light: 5000: 5
   Color Temperature: Front Porch Light: 5000: 25
ELSE
    Off: Deck Light, Front Porch Light
END-IF

@aaiyar Ok, I see the difference, now I just have to incorporate the temp thing in there.

I have another question. Why when I made a copy of the rule above it came in as this. Doesn't look the same.

Actually, the wording on triggers can be confusing, but a trigger of "Temperature < 32" will fire any time any temperature reading comes in and is < 32, even if it is not the first. For example, consecutive reports of 31 to 30 will match that trigger both times. Here's an example rule you can use to test that:

image

and the output you'd get (I left trigger and action logging enabled for maximum clarity, but if you're doing it on your own, the log action in the rule actions alone should be enough to see) when that sensor goes from 33 to 32 to 31 to 30:

image

What I would do to catch only one reading below 32 is the Private Boolean trick as suggested in the docs for other uses (and as attempted above, but you need to set it back to True when the temperature goes above that again, something you can't do if your only trigger is <32). The general format of that (you'd have to add in whatever you want to do here instead of my log action) would be something like:

Trigger: Temperature *changes*

Actions:

IF (Temperature < 32) THEN
  IF (Private Boolean is True) THEN
    Log: "This is the first time it's below 32"
    Set Private Boolean False
  END-IF
ELSE
  Set Private Boolean True
END-IF

You'll still have the issue that the "ELSE" (where PB is set back to True here) will run every time the temperature reads above 32, but I'm not sure exactly what you're trying to do or if that would be problematic for you. If so, you could create a similar rule that also triggers on temperature changes but checks for the reverse and tracks the threshold with PB in a similar manner.

1 Like

And you've actually tested this? This is not the behavior I'm seeing right now.

Edit: maybe I should have quoted instead of just replied. This is what I'm responding to:

I don't think it works this way.

Yes, that logic would definitely work for a one time <32 event. I have quite a number of rules that I did basically the same way (I prefer a dead band on the Private Boolean reset to prevent chattering) - and they all work.

See my edit-- was responding to @aaiyar, who I disagree with.

I see behavior consistent with @bertabcd1234-- private boolean needed for a single threshold-crossing behavior.

1 Like

Ah, sorry. I should have read more carefully. I do it similar to what bert said. I don't have any comments/adders to the mode conditions that @aaiyar mentioned.

OK, guys. How close is this one. Thanks for all your help by the way.

Should the first endif be above the else-if?

The "Set Private Boolean" action allows you to choose any rule, not just the current rule, in which to set the Private Boolean. Apparently, if you have "This Rule" selected, it keeps pointing to the original rule (not the new-current rule) even after a clone. Never tried that myself (I usually avoid cloning), but I assume that explains what you see.

I'd probably do that, too, unless the sensor isn't very sensitive or doesn't report in often. I left this out for simplicity, but you could certainly replace the "plain" ELSE with something ELSE-IF (Temperature >= 33) to create this effect.

Good luck!

@bertabcd1234, @JasonJoel, @bobbles, @andrewL, @aaiyar I am wondering if a new part to trigger could be added. "Do Not Repeat Trigger Once Triggered". Seems that would be a neat way to insure the trigger only fires once like in this instance.

None of us wrote Rule Machine. :laughing: @bravenel might be able to comment on whether he'd consider adding a feature like that. But the effect is nothing you can't already get yourself--Private Boolean is easy to use if you're only tracking one thing, or you could use a local variable for more (or a global if you want to keep things a bit cleaner and set it from another rule or have a need to use the value in multiple rules).

1 Like

That is why in these types of instances I use a virtual switch. It is either on or off and therefore will only trigger when the state of the switches turns on or off.

Lots of ways to skin that darned cat........ :wink:

1 Like

I didn't include his name because he never answers me anymore. I think he is still mad at me.

Where would I insert the virtual switch in the rule so it would keep it from re-triggering? Same place as Boolean? What is the advantage of one or the other?

The virtual switch essentially takes the place of the boolean. Where you set the boolean true, you'd set the switch "on" and where you set the boolean false, you'd set the switch "off". Then, you can trigger off of the switch state, which will only toggle when the temp threshold is crossed.

Personally I would have a very simple rule to turn the switch on and off.
TRIGGER
Temp sensor xxx CHANGED.
ACTION
IF
Temp sensor xxx is below 32.
THEN
Turn on Switch Virt temp below 32
ELSE
Turn off Switch Virt temp below 32
END-IF

Then for you rule
TRIGGER
Switch Virt temp below 32 changed.
ACTION
Switch Virt temp below 32 is ON
AND
The rest of your rule
You can now drop the PB.

This is just the way I like to do things.
It goes way back before variables were available and I have my head round it.
It also allows you to test things easily by just manually turning the virtual switch on and off.

I see the advantage to a virtual switch. Going to try that. Thanks