Expression to randomly run Global Reactions ?
-
Hi LibraSun
Something like that may work. I actually have a virtual switch in Vera and my previous rule was triggered when that virtual switch was turned on, it would then run the LUA code that in turn picked a random colour scene in Vera.
It would retrigger every 15 minutes and then run the LUA code again and pick another colour scene.
And if I turned off the virtual switch in Vera it stopped doing it and the lights were turned off etc.
-
In that case you could definitely include the virtual switch as one of the trigger conditions. That way when the switch is off the rule won't continue running every 15 minutes.
Also since you are not afraid of expressions, you could easily use them to create the random colors as well and use those expressions in Lua code with ${{ }} substitution.
-
In that case you could definitely include the virtual switch as one of the trigger conditions. That way when the switch is off the rule won't continue running every 15 minutes.
Also since you are not afraid of expressions, you could easily use them to create the random colors as well and use those expressions in Lua code with ${{ }} substitution.
What makes the expression run and generate a new number after a period of time?
This is what I have so far.
Trigger is the virtual switch in Vera.
Pulse every 1 seconds and repeat every 60 seconds.
Set Reaction - Groups that look at the expression named "ChooseColour" and its current number value
and then runs a Global Reactionnow directly sets that colour on the LED strip.
The random number generator expression named "ChooseColour" this is a rule expression not a Global Expression.
I added an 1 minute interval to the triggers and the virtual switch is true trigger is also pulsing every minute.
The expression is now changing numbers every minute, but the reactions don't seem to be running as the colour is stuck and not changing.
Also I think this expression generates the number zero which I don't have assigned to any reaction.
-
You can avoid the 0 value problem by making your expression look like:
floor(random()*6+0.5)+1// should produce integers from 1 through 7 inclusive.
From your description, I think you have more than just one Triggers condition pulsing. Stick with pulsing just the
device_695is TRUE condition for 1 second, repeating every 60 seconds. I don't think you need any other conditions in Triggers.And looking at everything you've shown us, it seems like it SHOULD be working at this point. If not, the reason is not obvious to me. You may have to poke around in the REACTOR.LOG to see what's happening (or isn't) and when. Make sure all your Rules are
Enabled! -
ANDing a pulse output with an Interval is not going to work as expected. You are trying, in effect, to synchronize two asynchronous events. You'll never get it. Remove the Interval condition. The pulse serves the purpose on its own that you're trying to get the Interval to perform.
-
Thanks guys. OK I have removed the interval and just have the trigger that the virtual switch must be true and I have a pulse for 1 second and to repeat every 60 seconds, just for testing, I'll set this to a longer time later.
I have also updated the expression with the new one to get rid of 0.
I have also changed the Reactions to directly set the colours of the light rather than calling the Global Reactions to do it.
It seems to be working, however there seem to be something strange going on with pulses and repeats ?
When the break count reaches zero the random number in the expression is changing quickly through 3 different numbers, which is weird.
Also if you set the pulse to say 15 seconds and the repeat to 60 seconds it's not behaving as I would expect ?
In this case when the break counter reaches zero the expression number changes to a different number, it then changes to a pulse counter for 15 seconds and when that reaches zero the expression number changes again.
I only expected it to change the expression number when the repeat count down from 60 seconds reaches zero not also when the pulse counter reaches zero.
Is this a bug or am I not understanding things correctly?
Thanks
-
Each change in the edge of the pulse necessarily causes a re-evaluation of the rule because the condition state may change, which in turn may change the state of the parent groups/containers. So the sequence of what you will see is: pulse true -> reevaluation -> rule set -> pulse delay -> pulse false/break start -> reevaluation -> rule reset -> break delay -> break end/pulse true -> reevaluation -> rule set ... etc...
Since your actions only run when the rule sets, you still only get one set per pulse; the change in the random value has no effect in any other evaluation.
-
...and I believe the only way to alter that arrangement (not that there's anything WRONG with how it's currently operating!), would be to affirmatively evaluate the random number using an expression tucked into the first step of your Set Reaction:
[Set Variable] [chooseColor] [ ${{ floor ( random ( ) * 6 + 0.5 ) + 1 }} ]Of course, for this setup to work, your
chooseColorexpression would have to be blank (otherwise, assignment doesn't work). I'm 99% confident that assigning the variable value at the outset of Set Reaction would indeed get it there in time for the subsequent case-by-case Group Constraints to utilize it as desired, but honestly I have not tested such a scenario. Worth trying, if your OCD doesn't like all those "extra" random values happening, LOL! -
This is also correct (a Set Variable can be used, and will evaluate/set before the groups -- in order shown, basically). In fact, this is the way I would do it for myself, for the very reason @LibraSun recommends: it stabilizes the value, and would do so in circumstances where the usage is more complex and the debugging would be made more difficult by the rapid changes otherwise.
EDIT/NOTA BENE: A bit of a trap here was discovered later. Be sure to read this later post. The recommended action for this purpose/implementation is to not use a Set Variable action to choose a random value. The linked post explains why.
Not that it much matters, but the random expression can also just be written as
floor( random() * 6 + 1 )(ever so slightly optimized).Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
This is also correct (a Set Variable can be used, and will evaluate/set before the groups -- in order shown, basically). In fact, this is the way I would do it for myself, for the very reason @LibraSun recommends: it stabilizes the value, and would do so in circumstances where the usage is more complex and the debugging would be made more difficult by the rapid changes otherwise.
EDIT/NOTA BENE: A bit of a trap here was discovered later. Be sure to read this later post. The recommended action for this purpose/implementation is to not use a Set Variable action to choose a random value. The linked post explains why.
Not that it much matters, but the random expression can also just be written as
floor( random() * 6 + 1 )(ever so slightly optimized).Thanks for the further suggestions.
I have made the "ChooseColour" expression empty and at the top of the Set Reactions I now have this:
The random number now only changes the once upon each repeat count down and the rule summary card now looks like this:
Its working but not reliably as the colour does not change on the light after every repeat count down. Sometimes it just stays on the previous colour that it was.
I have checked each Group Constraint action for each of the different colours and when pressing the Play button on each of them the LED strip does change to that correct colour.
And at other times the light seems to get stuck on one colour for a long time and many cycles, even though the rule is still generating numbers and then after a while it starts changing colours again, so it seems laggy.
Here is an example of how each Group Constraint looks:
-
As of this stage, there's nothing to prevent the same color from repeating 2, 3, ... infinite times. Such is the nature of random numbers. Was it one of your prerequisites that the color always change from what it was the previous cycle? Of course, that could occasionally lead to a ping-pong of %(#fb1004)[red], %(#0bf913)[green], %(#fb1004)[red], %(#0bf913)[green], %(#fb1004)[red], %(#0bf913)[green], .... which you may also find objectionable.
-
Also turn off the "Force re-evaluation of expressions" checkbox. You don't need that in this circumstance (since the use of the variable comes after the set explicitly), and it may even get in the way.
-
OK... wait up... apology here. Since conditions in reactions are a new feature, even I am not completely steeped in their particular behaviors, and limitations, and I just had a "but wait..." moment.
All conditions are evaluated at the same time. The group constraints are evaluated at the same time as the triggers. So, while the reaction's groups will run in sequence, the constraint result is determined before the reaction is run, and therefore doing the Set Variable action in the reaction has no effect on the then-current run of the reaction. That is, even though the reaction may Set Variable to a new random number, the constraints have already been evaluated using the previous value of the variable (what is was before the Set Variable action). So this would definitely account for the "lag" that @cw-kid is observing, because the value set by Set Variable on one run of the set reaction won't be used until the next time the set reaction runs.
And it's still the case that random numbers are not guaranteed to repeat or even be uniformly distributed over a small (less than several million, perhaps?) sample
So... setting your random number in the "Expressions" section of the rule, rather than by using a Set Variable action, is probably a better implementation for this purpose (at least, will be easier to follow/debug).
-
-
OK understood I will change the expression back to how it was and remove the set variable in the set reaction area.
I will increase the trigger repeat to 5 minutes and test it one evening when its dark outside.
Ideally I'd like for a different colour each time to be selected, but I guess the expression for the random numbers could select the same number again and therefore the colour would not change for that cycle.
-
Alternatively, you could randomize the color selection itself (not just limited to the 4-5 RGB choices you have now). More variety at the expense of slightly more complicated MSR expressions... but with a net savings in the number of Group Constraints required (just one instead of N for N colors).
-
Alternatively, you could randomize the color selection itself (not just limited to the 4-5 RGB choices you have now). More variety at the expense of slightly more complicated MSR expressions... but with a net savings in the number of Group Constraints required (just one instead of N for N colors).
-
OK understood I will change the expression back to how it was and remove the set variable in the set reaction area.
I will increase the trigger repeat to 5 minutes and test it one evening when its dark outside.
Ideally I'd like for a different colour each time to be selected, but I guess the expression for the random numbers could select the same number again and therefore the colour would not change for that cycle.
@cw-kid said in Expression to randomly run Global Reactions ?:
Ideally I'd like for a different colour each time to be selected, but I guess the expression for the random numbers could select the same number again and therefore the colour would not change for that cycle.
I use this to generate a random number that has not been used last time. In the reaction use express variable randomVal, once the reaction is over set randomVal to
${{int(split(join(split("1234567", randomVal || 0),""),"")[floor(random()*6)])}}
Then every time you get a different number. -
You've got me curious now: What make/model of garden lights do you have? And what is their ultimate color palette? Have you tried setting them to intermediate colors using the [Set_Color_RGB] action in MSR, for instance?
