Organizing/ structuring rule sets and rules

[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

[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".