[Reactor] Problem with Global Reactions and groups

[toggledbits]

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.

[toggledbits]

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).

[LibraSun]

Glad you explained all that, because I had a sneaking suspicion that the timing (and not just the order) of the [Set Variable] was important here. Kinda hard sometimes to keep it all straight, insofar as the human is not the most "logic"-al of engines!

[cw-kid]

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.

[LibraSun]

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).

[cw-kid]

@librasun

Sounds great but I don't know how to do it LOL.

As is I have 7 predefined colours which are the primary hex codes for those colours, red, green, blue, purple, orange, pink, yellow.

[LibraSun]

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?

[Elcid]

@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.

[cw-kid]

@librasun

It's a Fibaro RGBW module v1

[cw-kid]

@elcid said in Expression to randomly run Global Reactions ?:

I use this to generate a random number that has not been used last time

That's what I needed!

[Elcid]

@cw-kid This is probably more efficient

${{int(substr(replace("1234567", randomVal || 0,""),floor(random()*6),1))}}

Then I looked at moving this to MSR as I have it in Reactor, . I found the remove function and this is now easily expanded to larger number and you can easily set a range

${{remove( 1..7, randomVal - 1)[floor(random()*6)]}}

@toggledbits , possible bug
list(1..7]) gives [[1,2,3,4,5,6,7]] a nested array.
Is that expected.

[toggledbits]

@elcid said in Expression to randomly run Global Reactions ?:

@toggledbits , possible bug
list(1..7]) gives [[1,2,3,4,5,6,7]] a nested array.
Is that expected.

Yes, because 1..7 on its own produces an array. So wrapping it in list() gives you an array containing an array.

FWIW, list() is basically deprecated, because lexpjs lets you use common array notation (e.g. [1,2,3,4,5,6,7]) to define an array.

[LibraSun]

@elcid said in Expression to randomly run Global Reactions ?:

@cw-kid This is probably more efficient

${{int(substr(replace("1234567", randomVal || 0,""),floor(random()*6),1))}}

Then I looked at moving this to MSR as I have it in Reactor, . I found the remove function and this is now easily expanded to larger number and you can easily set a range

${{remove( list(1..7)[0], randomVal - 1)[floor(random()*6)]}}

GENIUS! Gonna borrow this.

@toggledbits , possible bug
list(1..7]) gives [[1,2,3,4,5,6,7]] a nested array.
Is that expected.

Yes, that's expected, since 1..7 itself creates an array – namely, [1,2,3,4,5,6,7] – while list() (now deprecated = avoid in MSR) also turns its argument into an array. I suggest omit list and see if things improve.

[Elcid]

@toggledbits just discovered that as you posted, is it mentioned in the docs, as I had not come acreoss it?

[toggledbits]

Yup. That's in the docs.

[Elcid]

@toggledbits
Its a bit confusing, i read this
"[5,7,9], so this function is now obsolete and may be removed later)"
and tried [1..7], when that failed, I assumed the only way to spread was list(1..7)
May be add a note about 1..7 being the same as list(1..7). As I found it some what unclear.

[toggledbits]

@elcid , it says:

I think this is pretty clear. The range operator is documented separately.

May be add a note about 1..7 being the same as list(1..7).

But it's not. That's how we got started.

[Elcid]

@toggledbits said in Expression to randomly run Global Reactions ?:

May be add a note about 1..7 being the same as list(1..7).

But it's not. That's how we got started.

I mean 1..7 being what I assume list(1..7) would produce a single array. That's why I found it confusing, I think that I expected a array to have [ ] around them.
Maybe add "also see range operator".

[LibraSun]

@elcid said in Expression to randomly run Global Reactions ?:

I mean 1..7 being what I assume list(1..7) would produce

Funny you should mention this, since all yesterday, I grappled with the question, "How can I find the minimum of an array in MSR?" (Answer: Not easily at all!) Turns out the min() function only works on a list with 2 elements, not arrays of arbitrary length. In other words, min(1,2,3) yields 1 without a hitch, whereas min([1,2,3]) returns null (for good reason: There's no guarantee the argument will always be a 1-dimensional numeric array!). Same for max().

Which led me to the realization that there's no direct way in MSR to "convert" an array into a list. Seems your brain encountered the same type of mental collision while trying to work out your imported expression.

[toggledbits]

@librasun My notes in the code:

Guess it's time to get to work.