[Reactor] Bug when sending MQTT boolean payloads

[toggledbits]

If you are running the same reaction (which I probably should not allow, eh?), it does not re-evaluate the rule, so the expression value never changes. You're getting the same delay every time. Any variance you are seeing is caused by device communication.

[LibraSun]

@toggledbits said in Low-priority GUI feedback:

...the expression value never changes. You're getting the same delay every time.

So:
(a) if I indeed WANT different values each cycle, I assume I should be placing random() nakedly inside the ${{ }}.
(b) up to you whether [ Run ] should permit self-iteration or not, although aside from the risk of cycling too quickly, I'm loathe to say "Save users from themselves" (unless you envision abuses of the "Use Pulse Instead, Dammit" variety looming ahead).

On a separate note, might you consider placing an "Open Eye" / "Closed Eye" icon next to "Enabled"/"Disabled" rules so that color-blind users can benefit? I'm sure the current %(#cc0000)[red font] means nothing to them.

[toggledbits]

@librasun Yes, (a) would work.

WRT (b), reactions aren't throttled, and it's not something I want to go to right now because I don't need to maintain state for reactions, they just run. There is also an unexposed mode of reactions where you can run them inline, rather than as separate processes, so the step after Run Reaction would not start until the reaction finishes (in the current/default mode, the reaction is started asynchronously). That would cause infinite recursion and eventually take things down. Even if I block direct self-reference, I would not go so far as to block A runs B, B runs A. Caveat user, but possible.

I don't like that icon anyway. But I'm trying to stay in one icon family, because using multiple is painful (different sizes, spacing, alignments, etc.), and the library I'm using is big, but still I haven't found anything in it I'm happier with. But I agree, I need to stay away from color alone as a cue (and in this case, it's not just color, but the icon change is very subtle). Here are the eyes in that library:

If you want to look through others, go here: https://icons.getbootstrap.com/

[LibraSun]

@toggledbits said in Low-priority GUI feedback:

Here are the eyes in that library:

Though I don't "love" the eyes, I'm accustomed to them being used with Switchboard app (I believe), so I know they do the job.

We don't need "fancy".

[LibraSun]

@toggledbits here on the Scope screen, one marvels at MSR's extreme precision! :-0

[LibraSun]

@toggledbits I just happened to catch a glimpse, in Rule Sets with one of my Rules expanded, of the countdown displaying:
false as of 13:23:58 waiting 0-0:00:03 // then 0-0:00:02, then 0-0:00:01 I believe...
instead of just:
false as of 13:23:58 waiting 0:00:01 02, 03, etc.
The extra '0-` bit disappeared after a few seconds, and only happened at the beginning of the count. (My constraint condition is supposed to be true for 60 seconds, and I was specifically watching it to monitor progress.)

[LibraSun]

@toggledbits Nice touch allowing the Expression definition cells to be persistently resized. Really helps with large "Objects".
Also just noticing the A-Z sort button atop Rule Sets, which I haven't used yet, but that's a nice touch! New to 21096 or just me not noticing before?

[toggledbits]

They're not really persistently resized, it's just taking a guess at the size needed based on the number of newlines, but wrapping of very long lines will probably goof it up. But, better than not doing it.

A-Z has been around for a very long time...

[LibraSun]

@toggledbits said in Low-priority GUI feedback:

A-Z has been around for a very long time...

One thing that I do believe changed with the release of 21096 is that Rule Sets now resets to the topmost ruleset on each visit. Not sure that's a positive development...?

With about 20 Rule Sets, while editing a particular group (say "HVAC"), I may jump back and forth to Entities, Expressions, Scope, etc. then back to "HVAC".

Now, Rule Sets always snaps back to "Assistants" (that is, label nearest "A" -- I keep them alphabetically sorted). Do you have any user feedback to support that behavior? (I can live with it; it's just extra mouse clicks, lol) If not, I vote "go back to 'LastSelectedRuleset'".

[LibraSun]

IMPORTANT @toggledbits -- I wanted you to bask in this PR-free day, so am asking in the Forum instead:
If Rule A has nothing in the Set Reaction, I've noticed that it does not "trip" or "trigger" despite the Conditions being met. Consequently, another Rule B failed to execute with its otherwise automatic [Rule State] [Rule A Set] being true.

Any immediate thoughts on this? And would my immediate "fix" be to include at least a "Comment" in Rule A's Set Reaction?

I know this is an edge case, but I have several rules like Rule A all grouped together, half with nothing in Set (almost as "placeholders" for when I think of actual stuff I want them to do).

[toggledbits]

I have tons of rules with no reactions. The setting and saving of the rule state is also quite separate in the code from the point where the reaction is selected and started (or not).

Anything logged?

[LibraSun]

Nope, nothing logged, leaving me to believe it's the underlying trigger mechanism - a Yale Assure deadbolt - is letting me down. Thanks for confirming, though, so I know which rabbit hole to go down tomorrow.

[toggledbits]

If your Rule logging level is 5, there should be sufficient info in the logs for you to see "entity-changed" entries like this:

2021-04-09T01:55:23.325Z <Rule:5:Rule.js:466> Rule#rule-grpwswz9u9 dependency notification entity-changed Entity#house>device_6 from Entity#house>device_6
2021-04-09T01:55:23.325Z <Rule:5:Rule.js:479> Rule#rule-grpwswz9u9 requesting eval; entity-changed Entity#house>device_6

That will be followed by (possibly with stuff between):

2021-04-09T01:55:23.325Z <Rule:5:Rule.js:814> Rule#rule-grpwswz9u9 (Auto Fan On) evaluate() acquiring mutex
2021-04-09T01:55:23.326Z <Rule:5:Rule.js:820> Rule#rule-grpwswz9u9._evaluate() mutex acquired, evaluating

This indicates that the rule is setting up for evaluation (making sure it's not already doing an evaluation). Then:

2021-04-09T01:55:23.326Z <Rule:5:Rule.js:668> Rule#rule-grpwswz9u9 evaluateExpressions() with 0 expressions
2021-04-09T01:55:23.326Z <Rule:5:Rule.js:863> Rule#rule-grpwswz9u9._evaluate() trigger state now false (was false)
2021-04-09T01:55:23.326Z <Rule:5:Rule.js:871> Rule#rule-grpwswz9u9._evaluate() constraints state true
2021-04-09T01:55:23.326Z <Rule:null> Rule#rule-grpwswz9u9 rule state now false, changed no

The first of these lines indicates the number of expressions being evaluated, which is the first phase of rule evaluation. The next line follows the evaluation of the trigger conditions and gives the new trigger state and the prior state. The line that follows is the evaluation result of the constraints. The fourth line states the overall rule state, and if that's different from the prior rule state. It is after this last line that the reaction to run is chosen (it is only run if the rule state changed as shown in the last log entry).

[LibraSun]

Yup, it was the lock's fault. Seems to have significant lag sending over the "unlocked" status, so my Triggers got out of sync. Fixed!

Relieved to know that "empty" Rules are both permitted and normal.

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