[SOLVED] Random ghosting of lights when Away
-
What happens when you do "power_switch.on" from the Entities list?
-
@toggledbits Here's a prototype for "Reactor Ex Machina"...
Lights to be cycled are placed in a global expression like this:
This is the "Cycler". It triggers when a variable it owns called
cycler_stimchanges (and is non-zero, which is the resting/deactivated state value).
When the cycler is "stimulated", it picks a random device from
REM_lightsand toggles it. Then it goes into a random delay between 10 and 30 minutes, after which it incrementscycler_stim, effectively stimulating itself (for lack of a better description) and the cycle begins again.This is the "activate" rule. It determines when light cycling should start. It just sets
cycler_stimto 1, and the Cycler will automatically start going.
This is the "deactivate" rule; it determines when cycling should stop. Depending on the complexity of your activate/deactivate rules, you could also do this in the reset reaction of Activate. It sets
cycler_stimto 0 and turns off all the controlled lights.
@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.
-
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...
-
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...
@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.
-
@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.
@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 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 }}@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.
*Hubitat C-7 2.4.3.149
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.11.1
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25310-dc2bb580
MQTTController: 25139
ZWave Controller: 25139 -
@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.
@gwp1 Agreed. Smart approach! I should have notated on my example that the
%operator stands formodulowhich 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_stimvariable from ever growing past 99. Hardly important; you may even prefer it the way it current behaves, growing by1indefinitely (which acts as a sort of historical counter). -
@gwp1 Agreed. Smart approach! I should have notated on my example that the
%operator stands formodulowhich 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_stimvariable from ever growing past 99. Hardly important; you may even prefer it the way it current behaves, growing by1indefinitely (which acts as a sort of historical counter). -
@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 }}@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==0is used as "not cycling/deactivated". -
@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==0is used as "not cycling/deactivated".@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.
-
@librasun I'm happy to share screenshots of the entire ruleset just in case I've missed something.
-
@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.
-
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/inenumerator withperformAction()buried inside, to grandioseRule A►Rule Bbehemoths. For me, the fun of it will forever be the question of "How?" -
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/inenumerator withperformAction()buried inside, to grandioseRule A►Rule Bbehemoths. For me, the fun of it will forever be the question of "How?"@librasun And to think all this waxing philosophical is due to my silly ask to ghost lights in the house
Thank you both for you wisdom and infinite patience!
Thank you @toggledbits for not just providing a path but explaining the path so I (and others) can learn -- really appreciated.
-
@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.
@toggledbits IT LIVES!! Set to 00:00:05 - 00:00:10 for testing and lights are cycling randomly as expected.
-
T toggledbits locked this topic on
-
G gwp1 referenced this topic on
-
R retireditguy referenced this topic on
-
K kellyjelly32 referenced this topic on
