[Reactor] Assignment to alarm ignored -- expression-driven global cannot be set by assignment

[toggledbits]

That's another reason I really want to see how they get used and what opportunities are possible to add rule or reaction features to alleviate the need. Those interfaces more or less put the options in front of you -- they are Reactor/MSR's expression builders.

On a related note, anecdote: in the late 90s/early 2Ks, I was a Perl power user, big time. Maybe half of my projects and output were Perl at that time. Then tides shifted and until just a few days ago, I had not touched Perl. But I had a file-handling task that was tailor-made for Perl, so I dove in. What a mess. What would have taken me a half hour 20 years ago took me hours that day, much of it Google-searching. C'est la vie.

[LibraSun]

@toggledbits Given your affinity for logic charts and equivalences, I think it bears asking at this juncture: What can performAction() do that a carefully-iterated Set/Reset Action cannot?

After all, if a user can already set up a device array, use Expressions to advance its index step-wise, and loop (or call) a Rule (or Reaction) repeatedly based on Conditions... is there a particular use-case where performAction() simplifies things or enables something otherwise impossible?

Please show me to the door if I've overstayed my welcome on this topic.

[toggledbits]

I'll answer a question with a question: what would the Cycler rule look like without performAction()?

[LibraSun]

Here's a naive stab at one solution. It uses a single expression to decide which of N "channels" will get toggled on the next cycle.

The rule itself runs so long as the Trigger condition remains TRUE. For testing purposes, I have it set to Pulse true for 5 seconds and repeat every 10 seconds, but the 'Repeat' interval would normally be much longer as in your example, above.

Since the 'Reset' reaction would normally engage after each Pulse, I included a Group Constraint to check whether my Trigger condition (in this case, the Fireplace light being ON) has gone FALSE. Only then will the ghost lights all be turned OFF.

The fun part in between happens in the 'Set' reaction, comprising 3 groups (one for each "channel"):

As should be clear here, I was forced to "hard wire" my selection of ghost lights by naming them explicitly within each Reaction. This illustrates just how convenient the new performAction() function is, allowing enumeration of an arbitrary (and easily editable) set of ghost lights listed within a single array as with your example.

Unquestionably, performAction() brings much value to the table for users who strive for compactness, readability and ease of maintenance in their Rules.

[LibraSun]

To answer my own question about, "How do you find which Actions a particular device can do using performAction()?"

The answer is: ENTITIES

Go to the left menu, click Entities, scroll down or filter to find the specific device or class of devices, pick a device and then scroll down to its list of "Actions". There, you will find all possible arguments for performAction(), such as power_switch.off. Enjoy!

[LibraSun]

@toggledbits I know you made a conscious decision that performAction() should return null, but would you consider having it return an object of the form:

{device: "vera>device_138", action: "power_switch.off", parameters: {<parameters>}, time: 1620912239172}

instead? I'd find this useful in troubleshooting Rules, especially those using enumeration as in the above examples, without having to resort to Log inspection every time.

• Libra

[toggledbits]

What happens when you do "power_switch.on" from the Entities list?

[LibraSun]

DISREGARD. Further testing reveals everything is fine!

[gwp1]

@toggledbits sanity check: shouldn't this equate 00:00:30 - 00:01:30 for cycling time? (Testing purposes.)

It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

[toggledbits]

Good eye! I realized that after taking the screen shot, was too lazy at that moment to reshoot it, so I left it suspecting that it would be a while before someone caught on. You beat my estimate! I'll amend the post text to highlight the discrepancy in situ, but yes, what you see there are my "test" values, and you should set them according to whatever timing you wish.

Edit: Mystery intensifies. It turns out my memory was incorrect, and I did go back and fix the screen shot. Capture below is what I am seeing in my post:

Notice the green "modified" bar on the left as well. So, I have no idea where that image you have is living right now, where you saw it. Is it possible we can see two different versions of the same post? That would be... unhelpful...

[gwp1]

@toggledbits This is on me for not being clear: the screenshot in my reply was of MY system - I wanted someone else's eyes on it as I've stared at it so long any obvious error will be lost to me at this point.

If mine IS correct then this takes me back around to wondering what I've broken elsewhere in this that the cycler isn't kicking at no more than 1 1/2 minutes but, rather, taking 12 minutes.

[LibraSun]

@gwp1 said in Random ghosting of lights when Away:

It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

Weird. From your screenshot, I definitely would have expected a Delay time of 00:30 to 01:30, not twelve minutes! And you're certain none of your Trigger conditions have a "Delay" or "Latch" or really long "Pulse" condition?

FYI, in case it matters, where you increment your Cycle Timer by 1, if you don't want that number to grow indefinitely large over time, consider:

${{ (cycler_stim + 1) % 100 }}

[gwp1]

@librasun No "delay", "latch", or "pulse" conditions. I'm not strong in expressions so my path forward is usually to emulate EXACTLY what the sample shows... then work backwards poking, editing (re: breaking) until I understand it better.

[LibraSun]

@gwp1 Agreed. Smart approach! I should have notated on my example that the % operator stands for modulo which in MSR (as with most modern programming languages) yields the "remainder" after division by the whole number on the right side.

Thus, this would have the effect of keeping your cycler_stim variable from ever growing past 99. Hardly important; you may even prefer it the way it current behaves, growing by 1 indefinitely (which acts as a sort of historical counter).

[gwp1]

@librasun I'm happy to share screenshots of the entire ruleset just in case I've missed something.

[toggledbits]

@librasun said in Random ghosting of lights when Away:

${{ (cycler_stim + 1) % 100 }}

Careful here... this will produce a 0 after 100 iterations and stop cycling, because cycler_stim==0 is used as "not cycling/deactivated".

[gwp1]

@toggledbits Good catch. I wasn't going down this path any time soon - but - as I said, I poke at things I'm new at and prob would have at some point.

[gwp1]

@gwp1

[toggledbits]

@gwp1 I was playing with this a bit more. Timing-wise it works fine for me but I did notice occasionally it would stall. This seems to be a race condition between the way the Set reaction's group executes vs the reevaluation of the Cycler rule. The purpose of the group is to stop cycling when deactivated, so we can do this differently and get rid of the race:

New "Deactivated":

And then remove the Group from "Cycler" and do the "Set Variable" directly:

---

Detail of the problem/race: Groups in Reactions are queued as sub-reactions of the parent reaction. The parent blocks in the execution queue while the child group runs, and when the child group finishes, the parent is allowed to resume. But these are, in effect, two different threads of execution. As originally offered, the child thread can finish and the parent, having nothing more to do (since the child is the last thing), signals completion and is removed from the queue. The problem comes from the "Set Variable" requesting a re-evaluation inside the subgroup. Once the subgroup thread stops, it is likely, but not guaranteed, that the parent reaction will get control next; when it doesn't, it's the evaluation that occurs, and when this happens, it sees cycler_stim has changed and is non-zero, and tries to queue the Set reaction. But a reaction can only be queued once: if a reaction is already executing, it will not be queued again. So, the evaluation succeeds as expected, but can't queue the next run of Set reaction because the prior run, which is effectively at its end but hasn't declared itself finished yet, is still on the queue. So the new Set doesn't get queued because the old one is there. The old one, with nothing more to do, finally gets to execute again and declares itself finished, and at that point, no reactions are queued and the process stalls.

The fix: By making the stop of the Cycler Set reaction explicit, we ensure that it stops when needed and is removed from the queue. By removing the "Set Variable" from the group (and removing the group entirely), its update of cycler_stim is done in the main reaction thread, which finishes before the re-evaluation is allowed to begin, thus allowing the re-evaluation to queue the Set reaction again as it must.

It's worth noting that this is a side-effect of writing a rule and reaction that attempts to perpetuate itself, to run in an effectively infinite loop. In that, it works against some internal design choices meant to prevent such behaviors that might otherwise be "runaway" in normal circumstances.

[LibraSun]

One of the most tantalizing, yet ultimately frustrating, aspects of MSR is its potential use for "looping" of this exact type. I think by now we've all taken a stab at it (I know I have), but many of those attempts run into a wall which I call "chicken or the egg".

That is, on the one hand, you have to somehow "bootstrap" a looping Rule so that its Trigger conditions get it going ... but on the other hand, those conditions must not simply remain "true" or else the Rule will not loop at all. So the user is forced down one or more alleyways involving "pulse" or "interval" or revolving variable values, or -- as in this above example -- externally launching and un-launching the Rule from another rule. Whichever method you choose (I've tried them all, lol), there are potential stumbling blocks along the way.

Few, if any, users can "see" all of those prospective hazards ahead of time. MSR in some instances is designed to push back against looping: Do it too quickly, and throttling kicks in. Do it without careful synchronization, and child processes get tripped up (as has happened here). Do it with callous disregard for memory-hogging subroutines and you can bog the system down to a halt.

Ask me how I know.

By now, I think I've made every possible mistake one can make in MSR -- always my own fault -- and nearly every time I've botched a "looping Rule" I have had to fight the impulse to ask @toggledbits for a formalized "Loop" action within reactions. Like, "Why can't we have a DO..WHILE crutch here?"

Then I think, no, it's best we don't. Because (a) we're talking about a fairly advanced construct here, that (b) probably does not belong in the hands of beginning users, and (c) looping by its very nature stands at odds with an engine designed to carry out deterministic procedures in a synchronous, queued fashion.

NOTE: It's not coincidental that a Reaction's ability to directly re-run itself was removed early on in the development of MSR!

I know I'm waxing philosophical here. And I'm sure we'll all carry on crafting custom loops of one type or another -- from the simplest each/in enumerator with performAction() buried inside, to grandiose Rule A ► Rule B behemoths. For me, the fun of it will forever be the question of "How?"