Reactor-Editor / Reactor-ui-Status Errors

[toggledbits]

It has to be, otherwise you would not be able to easily use them as building blocks for other rules. I do this extensively.

[LibraSun]

@toggledbits okay, I am ready to formalize this feature request:

Would you consider allowing the run reaction action to allow free form text entry, in such a way that you could still use the drop-down list of reactions, but you could also enter the canonical Rule ID either directly as a text string or via substitution?
I can see why you may not want to do this since it introduces the possibility of typographical errors.
The reason I'm asking is that I may want to set up a rule that acts as sort of a "director" that runs other rules based on a lookup. Of course I can currently do it in the reverse direction where those rules simply run based on the output value and that's that.

Thoughts?

[LibraSun]

FEEDBACK @toggledbits Note how objects with "text" keys get sorted in "Last Value:" according to "numbers first then letters" (i.e. dictionary style) rather than the order in which keys appear in the Object declaration.

Probably not bothering most users, but could mildly disrupt workflow of someone who routinely copies "Last Value:" for Pretty Print purposes. I know I'd prefer original order.

[toggledbits]

Object properties (dictionary keys) do not have a deterministic or guaranteed order in JavaScript.

[LibraSun]

UPDATE: Seemingly resolved. Trivial. I added a "hold true for 2 seconds" on Trigger condition, the wait apparently needed in order for "turn ON" event (in Constraints) to be recognized on Vera. Funny, too, because that's the 1st action Alexa's routine issues. Lessons learned: (1) MSR's idea of synchrony is not always the same as my own; and, (2) Alexa may stutter when executing successive steps in Routines (WOW! Noticing gaps of up to 7 seconds here, sometimes Step 1 precedes Step 2, sometimes other way around!).

@toggledbits , pursuant to PR#164 (Closed), I'm unfortunately still grappling with a Rule that (SOMETIMES!) refuses to fire, even when all Conditions go TRUE virtually simultaneously. I may be the world's worst Log reader, but I think the following snippet of said Rule's evaluation process supports what I'm saying:

2021-04-13T14:43:07.810Z <Rule:5:Rule.js:749> Rule#rule-knay6sc6 dependency notification entity-changed Entity#vera>device_211 from Entity#vera>device_211
2021-04-13T14:43:07.811Z <Rule:5:Rule.js:755> Rule#rule-knay6sc6 requesting eval; entity-changed Entity#vera>device_211
2021-04-13T14:43:07.812Z <Rule:5:Rule.js:950> Rule#rule-knay6sc6 (Alexa Director (alexa)) evaluate() acquiring mutex
2021-04-13T14:43:07.813Z <Rule:5:Rule.js:954> Rule#rule-knay6sc6._evaluate() mutex acquired, evaluating
2021-04-13T14:43:07.813Z <Rule:5:Rule.js:958> Rule#rule-knay6sc6 update rate is 0/min limit 60/min
2021-04-13T14:43:07.814Z <Rule:5:Rule.js:880> Rule#rule-knay6sc6 evaluateExpressions() with 3 expressions
2021-04-13T14:43:07.815Z <Rule:5:Rule.js:970> Rule#rule-knay6sc6._evaluate() trigger state now false (was false)
2021-04-13T14:43:07.816Z <Rule:5:Rule.js:972> Rule#rule-knay6sc6._evaluate() constraints state false
2021-04-13T14:43:07.817Z <Rule:null> Rule#rule-knay6sc6 rule state now false, changed no
2021-04-13T14:43:07.936Z <Rule:5:Rule.js:749> Rule#rule-knay6sc6 dependency notification entity-changed Entity#vera>device_211 from Entity#vera>device_211
2021-04-13T14:43:07.938Z <Rule:5:Rule.js:755> Rule#rule-knay6sc6 requesting eval; entity-changed Entity#vera>device_211
2021-04-13T14:43:07.939Z <Rule:5:Rule.js:950> Rule#rule-knay6sc6 (Alexa Director (alexa)) evaluate() acquiring mutex
2021-04-13T14:43:07.940Z <Rule:5:Rule.js:954> Rule#rule-knay6sc6._evaluate() mutex acquired, evaluating
2021-04-13T14:43:07.941Z <Rule:5:Rule.js:958> Rule#rule-knay6sc6 update rate is 1/min limit 60/min
2021-04-13T14:43:07.942Z <Rule:5:Rule.js:880> Rule#rule-knay6sc6 evaluateExpressions() with 3 expressions
2021-04-13T14:43:07.943Z <Rule:5:Rule.js:970> Rule#rule-knay6sc6._evaluate() trigger state now false (was false)
2021-04-13T14:43:07.945Z <Rule:5:Rule.js:1578> cond cond6zfyayg evaluation state false->true
2021-04-13T14:43:07.946Z <Rule:5:Rule.js:1578> cond const evaluation state false->true
2021-04-13T14:43:07.947Z <Rule:5:Rule.js:972> Rule#rule-knay6sc6._evaluate() constraints state true
2021-04-13T14:43:07.948Z <Rule:null> Rule#rule-knay6sc6 rule state now false, changed no

i.e. both the Triggers and Constraints condition (one each) jump to TRUE, yet the Rule itself remains FALSE, leaving another Rule (which watches this one's state) flapping in the breeze.

Didn't wanna clutter Mantis with this, but happy to. First wanted to pass this by you here, so you could request files/evidence.

As additional background, what's supposed to happen is Alexa hears me utter a preset phrase, causing an Alexa Routine to run. It runs fine (I know because she speaks and turns on music) and performs the two steps (turning on a VS on Vera and dimming another one to a specific value), which I see go "green" in MSR. And yet, as described herein, the Rule itself just sits idle.

Thanks for any guidance here!

• LS

[toggledbits]

2021-04-13T14:43:07.943Z <Rule:5:Rule.js:970> Rule#rule-knay6sc6._evaluate() trigger state now false (was false).

This is saying the trigger state is false. It says that in both cases. It follows by saying the rule state is false (which is correct if the triggers are false). The constraints are indeed true, but if the triggers are false, the rule state will still be false.

[LibraSun]

@toggledbits said in Low-priority GUI feedback:

This is saying the trigger state is false.

Much appreciated, and sorry for the n00b question. I've spent the morning chasing down gremlins left and right surrounding this "Alexa Director" endeavor, and I give up. I inadvertently created a thicket of Franken-Rules which deserve to go back into the grave.

Think I'll stick with Virtual Switches after all, as they are far more deterministic, predictable, and UI friendly than any attempt I've made thus far to reinvent them with pure logic.

Ha ha, I was having Triggers accidentally trigger multiple Rules and then, once tightened down even further, NONE of the Rules.

I will henceforth regard the VS as a necessary resource on Vera, especially when used as an adjunct to Alexa Routines.

[toggledbits]

Not a n00b question at all. I'd really like to see for myself what's happening. If you still experiment with it more, crank the rule's log level to 6, and send me the results.

[LibraSun]

@toggledbits said in Low-priority GUI feedback:

I'd really like to see for myself what's happening. If you still experiment with it more, crank the rule's log level to 6, and send me the results.

I'm sure to fiddle around further, but intend that to happen with inconsequential test Rules rather than some of my most prized "Leaving Home", "Coming Home" level workflows.

Will advise... thx.

P.S. You may legitimately ask, "Why are you trying to avoid Virtual Switches in the first place?" Answer: Because I hate having to create them, configure them, propagate them through the Vera UI (rename, relocate, hard refresh) and again through the Alexa ecosystem (name, discover, configure in Routines, etc.). I've been searching for a quick-to-expand alternative method, one that presents itself in all four UIs (Vera, MSR, Alexa, VeraMobile) with rapid adaptability to new workflows (e.g. "Time for Doing a Puzzle") which I might in turn choose to knock down after a few days.

[LibraSun]

This post is deleted!

[LibraSun]

@toggledbits please excuse this umpteenth FEATURE REQUEST, but would it be possible to include "Expressions" among the items listed by the "Insert Entity Attribute Value" button? While I'm not 100% certain you intend for other Rules' variables to be "visible" in the Expressions section, if they are accessible here, then having the ability to "build" such a reference instead of by rote would be helpful.

Example:
varRuleA := 1 + varRuleB[3]
// Insert tool saves having to memorize varRuleB name and structure

[toggledbits]

Just go ahead and open PRs for feature requests. For the benefit of all reading, clear description and use case are a must. I'll add them to the wish list.

[LibraSun]

Thanks for the green light on that. I'll comb through the non-PR list of FR's and transcribe the good ones.

[toggledbits]

Not many PRs being opened these days. That's why there aren't many builds. FYI, each morning I plan my work around (a) long-term tasks that are in progress (some of which are PRs that can't be fixed in a day), and (b) new PRs. I do not include discussions here in those plans.

[LibraSun]

This post is deleted!

[toggledbits]

I'm not sure I understand your question...

also... this is that thing... topic title is "Low priority GUI feedback", and your question is about lexpjs/expressions?