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

[gwp1]

When using Vera I made use of Deus Ex Machina II after Patrick took it over. Worked brilliantly for ghosting lights on and off when I was away.

Now that my devices are migrated to Hubitat I can't make use of DEMII.

Any thoughts on how to replicate this randomness with two or three lights in MSR?

Solved here: https://smarthome.community/post/8204

[therealdb]

Install it on openLuup and bridge the lights via mqtt or similar?

[toggledbits]

Pretty easy to do with lights to be controlled in an array and a couple of rules to figure out (a) when to be enabled, (b) toggle a randomly-selected light from the array and delay a random time; (c) figure out when transitioning from enabled to disabled and turn off all the lights in the array. That's basically the guts of DEMII.

[LibraSun]

Also, I believe random lights on/off is a built-in feature of Alexa Guard. You set it up in the Alexa app, choose which lights to operate, and when leaving the house, simply say, "We're leaving" or "Turn on Guard".

[therealdb]

@librasun great to know, since guard is us only at the moment.

[toggledbits]

@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_stim changes (and is non-zero, which is the resting/deactivated state value).

When the cycler is "stimulated", it picks a random device from REM_lights and toggles it. Then it goes into a random delay between 10 and 30 minutes, after which it increments cycler_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_stim to 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_stim to 0 and turns off all the controlled lights.

[gwp1]

@librasun This is good to know - I tend to try and keep as much as possible within MSR. Yes, it makes it a SPOF, but it's also better than chasing down troubleshooting in multiple places.

That being said... I do have some things like TV on/off, Night mode on, that are convenience things that ultimately drive back to the root HA system running from within Alexa devices.

[gwp1]

@toggledbits Going to ask a really dumb question: how do I create a variable to use in Set Variable ?

[LibraSun]

@gwp1 said in Random ghosting of lights when Away:

@toggledbits Going to ask a really dumb question: how do I create a variable to use in Set Variable ?

In MSR, you have two choices. #1 - Create a new Global Expression under (you guessed it) "Global Expressions" on the left-hand menu. #2 - Within any Rule, scroll down to the bottom and click to expand the Expressions pane; there, you can click [+Add Expression]. Just type its name (variable names are case-sensitive!), then tab or click into its definition window to begin creating an expression.

[LibraSun]

@toggledbits some quick questions about the new performAction ( ) construct you've just presented:

1. Will there be a "Builder" button to help create these expressions in the same way getEntity currently does?
2. Is the semicolon ; a one-for-one alternative to comma , as a separator in multi-part expressions? or only when used as a terminator for each blocks?
3. 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".
4. 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/do territory without explicitly introducing a label/loop or repeat element.

(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 __ times

Thoughts?

[toggledbits]

@librasun

1. 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.
2. Semicolon and comma are treated the same in lexpjs.
3. Which one?
4. Yes. Start at the "Manual" link in the left nav, go to Creating Automations, then Expressions.

[LibraSun]

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

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

[LibraSun]

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

[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