[SOLVED] Random ghosting of lights when Away
-
@toggledbits some quick questions about the new
performAction ( )construct you've just presented:- Will there be a "Builder" button to help create these expressions in the same way
getEntitycurrently does? - Is the semicolon
;a one-for-one alternative to comma,as a separator in multi-part expressions? or only when used as a terminator foreachblocks? - Why did you elect to place that
[Set Variable]sequence inside a separate rule's Set Reaction, rather than have it inside the Reset Reaction of "Active Period". - Any documentation available at this stage for
performAction ( )showing what the optional{ }parameters can do?
This is clearly powerful mojo you've just unleashed. And your implementation example takes us into
while/doterritory without explicitly introducing alabel/looporrepeatelement.(But your example does have me wondering whether "Condition Options" for Triggers and Group Constraints should offer "Randomize" drop-downs in "Pulse" for Output Control?)
e.g. output goes true for [fixed/random] __ (to __) seconds [once/repeat] after [fixed/random] __ (to __) seconds, up to __ timesThoughts?
- This is a tough one; which is to say, I'm developing a tough stance around the expressions in general. I'm more likely to remove the existing builder for 1.0. Expressions are an advanced user feature, and putting training wheels around what is really two simple core concepts that are foundational for an MSR user to understand in the system (i.e. how to identify a device and how to pick an attribute from it) isn't helpful in my view. In fact, your earlier suggestion of a full point-and-click expression builder actually set off alarm bells in my head and has pretty much cemented for me where expressions live in this ecosystem. As/if MSR is used by more people, I will be looking at how expressions are used and why, and trying to find ways to address those needs with conditions and actions instead, so that the need for expressions is reduced to the minimum (i.e. make more powerful tools available in the simpler interface, rather than growing the power of the most complex interface). I'm also not afraid to decide that not every automation problem needs an MSR solution. At least for version 1.0, I'm feeling just at or slightly over the limit of what I'm willing to do with expressions until I get more users and more perspective.
- Semicolon and comma are treated the same in lexpjs.
- Which one?
- Yes. Start at the "Manual" link in the left nav, go to Creating Automations, then Expressions.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
- Will there be a "Builder" button to help create these expressions in the same way
-
- This is a tough one; which is to say, I'm developing a tough stance around the expressions in general. I'm more likely to remove the existing builder for 1.0. Expressions are an advanced user feature, and putting training wheels around what is really two simple core concepts that are foundational for an MSR user to understand in the system (i.e. how to identify a device and how to pick an attribute from it) isn't helpful in my view. In fact, your earlier suggestion of a full point-and-click expression builder actually set off alarm bells in my head and has pretty much cemented for me where expressions live in this ecosystem. As/if MSR is used by more people, I will be looking at how expressions are used and why, and trying to find ways to address those needs with conditions and actions instead, so that the need for expressions is reduced to the minimum (i.e. make more powerful tools available in the simpler interface, rather than growing the power of the most complex interface). I'm also not afraid to decide that not every automation problem needs an MSR solution. At least for version 1.0, I'm feeling just at or slightly over the limit of what I'm willing to do with expressions until I get more users and more perspective.
- Semicolon and comma are treated the same in lexpjs.
- Which one?
- Yes. Start at the "Manual" link in the left nav, go to Creating Automations, then Expressions.
@toggledbits said in Random ghosting of lights when Away:
Which one?
I was referring to the placement of the "Reset to 0" action inside of a "Deactivate" rule (see https://smarthome.community/post/7946) rather than just resetting the variable in the Reset reaction of "Active Period" (since I believe, perhaps wrongly?, that the same thing would be accomplished either way).
As for the "Builder", it was just my natural response to an inner dialogue I had upon first seeing
performAction ()... namely, "How will I ever remember the function 'performAction'?" and "How am I going to keep its syntax straight between uses?" and "What are the myriad valid actions it can perform on a given device?"Such a powerful tool! But chances are, without a Builder, I just would avoid it entirely because I can't keep all that in my mind. Just like I currently use the "Expression Builder" of Reactor for Luup and its counterpart in MSR every single time.
-
@toggledbits said in Random ghosting of lights when Away:
Which one?
I was referring to the placement of the "Reset to 0" action inside of a "Deactivate" rule (see https://smarthome.community/post/7946) rather than just resetting the variable in the Reset reaction of "Active Period" (since I believe, perhaps wrongly?, that the same thing would be accomplished either way).
As for the "Builder", it was just my natural response to an inner dialogue I had upon first seeing
performAction ()... namely, "How will I ever remember the function 'performAction'?" and "How am I going to keep its syntax straight between uses?" and "What are the myriad valid actions it can perform on a given device?"Such a powerful tool! But chances are, without a Builder, I just would avoid it entirely because I can't keep all that in my mind. Just like I currently use the "Expression Builder" of Reactor for Luup and its counterpart in MSR every single time.
@librasun As I said, it depends on the complexity of your activation and deactivation. I made them separate because I think that's a more general approach -- not all "not activate" means "deactivate". But for sure, it can be done just in Activate if that is implied.
@librasun said in Random ghosting of lights when Away:
As for the "Builder", it was just my natural response to an inner dialogue I had upon first seeing performAction ()... namely, "How will I ever remember the function 'performAction'?" and "How am I going to keep its syntax straight between uses?" and "What are the myriad valid actions it can perform on a given device?"
Such a powerful tool! But chances are, without a Builder, I just would avoid it entirely because I can't keep all that in my mind. Just like I currently use the "Expression Builder" of Reactor for Luup and its counterpart in MSR every single time.If everybody thought like this, none of us would be here because nobody would use any API and none of these tools or systems would exist. I do not expect users to get through using expressions at all without referring to the documentation from time to time. The R4V "getstate" tool is not an expression builder, it just handles that one function, as does the analogous tool in MSR. But expanding on that seems folly to me, and the more expansive, the more folly. It's anathema to the complexity of the feature (expressions), IMO.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@librasun As I said, it depends on the complexity of your activation and deactivation. I made them separate because I think that's a more general approach -- not all "not activate" means "deactivate". But for sure, it can be done just in Activate if that is implied.
@librasun said in Random ghosting of lights when Away:
As for the "Builder", it was just my natural response to an inner dialogue I had upon first seeing performAction ()... namely, "How will I ever remember the function 'performAction'?" and "How am I going to keep its syntax straight between uses?" and "What are the myriad valid actions it can perform on a given device?"
Such a powerful tool! But chances are, without a Builder, I just would avoid it entirely because I can't keep all that in my mind. Just like I currently use the "Expression Builder" of Reactor for Luup and its counterpart in MSR every single time.If everybody thought like this, none of us would be here because nobody would use any API and none of these tools or systems would exist. I do not expect users to get through using expressions at all without referring to the documentation from time to time. The R4V "getstate" tool is not an expression builder, it just handles that one function, as does the analogous tool in MSR. But expanding on that seems folly to me, and the more expansive, the more folly. It's anathema to the complexity of the feature (expressions), IMO.
@toggledbits Agreed. I accept my limitations here, too, just as I have for the past 40 years when attempting to write computer programs. (Ironic, since I taught Applesoft BASIC and LOGO to hundreds of kids in the 1980s.)
For me, composing things like Regex matches, Javascript/Google Apps Script macros, PUT requests, and more generally API calls with code -- even rudimentary Linux commands at the prompt -- means hours of Googling, reading docs, and/or hunting up examples.
So long as we teamwork those MSR docs into something brimming with Pro Tips and Working Examples, I (and 99.9% of users) will be fine. But coming up with Expressions from scratch, on-the-fly with weeks/months between visits to the UI will remain challenging, by design, as you rightly point out.
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
@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.
-
I'll answer a question with a question: what would the Cycler rule look like without
performAction()? -
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. -
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 aspower_switch.off. Enjoy! -
@toggledbits I know you made a conscious decision that
performAction()should returnnull, 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
-
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.5.1.142
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HAOS
Core 2026.7.4
w/ HA Connect ZWA-2
FW: v1.1
SDK: v7.23.1*Prod MSR in docker/portainer
MSR: latest-26193-8dd8f854
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".
