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

[PerH]

If the idea is to create a top automation layer - what about including some of your other automation luup plugins? I think i.e. Delaylight, SiteSensor and AutoVirtualThermostat would fit nicely as Automation templates that can be quickly configured?

Automation templates is something i've been missing in Reactor, what i mean by that is simply a good way to copy the structure of a good automation i have running in one room to another room (Today I have a Reactor sensor in each room, and one for "House" automation).
Example: I have two guest rooms set up with identical sensor and actuator layouts, so the automation i want would be identical for those rooms.

Another side note, i think some sort of room organization would be nice in the entities list?

I'm not entirely sure about how to implement either of these, or the scope of the work it entails, just throwing out some ideas.

[LibraSun]

[Possibly split the following feedback into its own thread if seeking input on MSR Dashboard UI]

As a Dashboard n00b, I'd benefit from knowing exactly where on a particular Dashboard tile to tap for "Dim+", "Dim-", "On/100%" and "Off/0%". So I created two examples, linked below, despite knowing full well that others have created much better examples than this on other platforms. I also fully acknowledge that this kind of feedback is premature, as the official roll-out of MSR's Dashboard feature has not yet happened.

ON: https://drive.google.com/file/d/1kWPtPa2HQ5GExBIi45QNJGyEvsz5QVZu/view?usp=sharing
OFF: https://drive.google.com/file/d/1EIZK1BggsDtNWm8mfBT605N7-cnkeSQ_/view?usp=sharing

[LibraSun]

SUGGESTION

In the text fields used under "Rulesets", instead of having "Add your rule's triggers here" guidance text pre-populate the object (which requires users to click-drag-delete before typing), could you instead use the object's .placeholder attribute?

I know this is a controversial stylistic choice among CSS designers, but the Placeholder approach carries with it some immediate benefits:

• Help text disappears upon clicking into field;
• Help text reappears if user empties the field;
• Can appear in different font style (e.g. greyed, italic) from input text;
• Not apt to be misinterpreted as filled text, nor read by a screen reader app;

Minutiae, yes, but still worth my mentioning IMHO.
COUNTERARGUMENT: https://www.smashingmagazine.com/2018/06/placeholder-attribute/

[LibraSun]

SUGGEST (I'll happily move these suggestions elsewhere, such as the Mantis, if instructed to do so)

Assuming that "==0" and "is FALSE" will both match the condition of a device being turned OFF (the MSR UI seems to prefer "false" to "0" when referring to POWER_SWITCH.STATE, for instance), could you also add "is ON" and "is OFF" to the drop-down list of comparators?

However redundant, this seems a natural language-y thing to have in place for novice users, who may not think in binary 0/1.

[toggledbits]

There are a bunch of hints in the capabilities data that I'm not making use of yet. This is exactly that kind of thing.

    "power_switch": {
        "attributes": {
            "state": {
                "type": "bool",
                "values": {
                    "true": "on",
                    "false": "off"
                }
            }
        },

[LibraSun]

By now, you understand I'm reluctant to add an "Issue" to the Mantis when I'm merely thinking aloud, so here goes with another set of MSR thoughts:

(1) Should each Ruleset have its own top-level DISABLE flag/button/status? (i.e. above even 'Triggers' and 'Constraints')
(2) Would it be useful to be able to "enable/disable" a Ruleset from another Ruleset? (this may already be possible, I haven't checked deeply)
(3) Does MSR possess the same "Throttling" feature as Luup Reactor, to stem circular references and flapping? I'll be interested to learn whether the reset mechanism is also similarly employed.
(4) Since lexpjs is normally evaluated at compile-time, would it be possible to (i) perform syntax checking during Expression entry, (ii) provide a drop-down 'helper' (APK-esque pick-list) from which users can select from a menu of possible functions, and/or (iii) generate daily alert summaries advising user of non-working Expressions (or other error conditions within MSR)?

I included (4)(iii) because I'm always uncovering old Reactor recipes that have "issues" resulting from obsolete references. And I love the way, for instance, Synology NAS units email their owners to notify them of system status, security concerns, updates needed, etc.

[toggledbits]

@librasun said in Preview of Multi-System Reactor:

(1) Should each Ruleset have its own top-level DISABLE flag/button/status? (i.e. above even 'Triggers' and 'Constraints')

I could probably add this is a macro-instruction in the UI, but Rule Sets are only an organizational structure for the benefit of the user and have no inherent relationship to the Rule for purposes of logic. Such a feature would simply loop over the list of rules in the set and enable or disable them. The Rule Set itself would not have an enabled or disabled state.

(2) Would it be useful to be able to "enable/disable" a Ruleset from another Ruleset? (this may already be possible, I haven't checked deeply)

This will definitely not be happening, for the same reason I don't allow enabling/disabling a Rule from another rule: this could quickly create a situation in which a user's logic is completely unsupportable, because at any given time you don't know what is enabled or disabled, or who enabled or disabled, or when or why. IMO, the less users understand about how to structure their logic (e.g. elusive boolean algebra), the more likely a kludge like this would be used, as well; it would become the crutch from he**. I'm all for choices and giving users a little rope that they might hang themselves with, but this seems like a guaranteed highway to pain.

My evidence of this, by the way, is how quickly people went to various modes of the "Reset Latched" action, rather than structuring their logic so that latched conditions would reset naturally. MSR has only natural unlatching.

(3) Does MSR possess the same "Throttling" feature as Luup Reactor, to stem circular references and flapping? I'll be interested to learn whether the reset mechanism is also similarly employed.

It does indeed, although MSRs version is a little software. In MSR, when the threshold is breached, it simply delays further performance on that rule. It literally throttles it back, rather than cutting the gas off entirely.

(4) Since lexpjs is normally evaluated at compile-time, would it be possible to (i) perform syntax checking during Expression entry, (ii) provide a drop-down 'helper' (APK-esque pick-list) from which users can select from a menu of possible functions, and/or (iii) generate daily alert summaries advising user of non-working Expressions (or other error conditions within MSR)?

lexpjs is fully portable between the different versions of JavaScript that run within a browser and that which runs in nodejs. So it's very possible to have "test compiles", and it's a pretty light-weight thing to do. Of course, this won't catch runtime errors, like referring to an entity that doesn't exist, or an attribute on an entity that doesn't exist, but I agree it would make editing smoother. Little UI tweaks like this are fine for bug reports. I like them as reminders. I think this (as in, what is happening right here, right now) is a good workflow: discuss, and when we find the consensus on what needs to be done, open a PR to memorialize it.

Now, getting really fancy and having a bunch of drop-down pickers/assistants, should probably be a separate second PR. I think the first level problem is to get more dynamic syntax checking, and then we start thinking about assistants.

[LibraSun]

Dang, I just jetted back here to declare my idea #1 as "dumb" but thankfully you beat me to it. Individual Rules already have their own (manual) enable/disable anyway. Dunno what I was talking about.

[LibraSun]

USER NOTE: Whereas in MFL I followed your prescribed paradigm of naming Reactors after individual Rooms (e.g. "DINING ROOM", "PORCH", etc.), with MSR I'm leaning toward naming Rulesets after their meta-function (e.g. "LIGHTING", "SECURITY", "ENVIRONMENT", etc.) instead.

Dunno if you've made a conscious decision to promote one naming schema over another, but wanted to toss this idea in the ring.

[toggledbits]

@librasun said in Preview of Multi-System Reactor:

Dang, I just jetted back here to declare my idea #1 as "dumb" but thankfully you beat me to it.

I don't think that's at all dumb, and it makes a lot of sense, depending upon, as you said in your follow-on post, what schema you choose for your rules. So far, I've gone with one rule set per room, just leaving the mapping established by the importer. Particularly when getting the rules moved from RFL to MSR, I often had to disable an entire room's (rule set's) rules until I got something fixed.

It's not a bad idea at all.

[LibraSun]

May I also just add that I appreciate how a Reaction can "Stop" itself? Could be a powerful debugging tool when needed.

[LibraSun]

LEARNED SOMETHING TODAY

1. You can click-and-drag Rules to reorganize them in Rulesets. Who knew?
2. You cannot, however, click-to-highlight the Rule ID of an expanded rule, in order to copy that text.
3. Setting an Expression := away is entirely different from := "away". The first evaluates to (null) if no such named Global exists; the second evaluates to the string "away".

#2 would be hugely helpful for times when you need to troubleshoot the Reactor.log. (I understand CSS and HTML, but don't know the correct term for "object not swipable" -- is this a side-effect of, say, a very high z-index on that block element?).

As for #3, I foolishly thought MSR's expression parser, lexpjs, was meant to typecast unknown objects (away ► "away") but that was a n00b miscalculation.

[toggledbits]

Looks like #2 is a limitation of "sortable" objects in jQuery UI. The sortable takes over all clicks and drags. I'll keep poking for workarounds, but don't get your hopes up.

[LibraSun]

re: #2 it might then be helpful to replicate the Rule ID within the Edit view of each Rule?

[toggledbits]

@librasun said in Preview of Multi-System Reactor:

You can click-and-drag Rules to reorganize them in Rulesets. Who knew?

You can do the same with Rule Sets... organize them in any order you wish.

[toggledbits]

@librasun said in Preview of Multi-System Reactor:

re: #2 it might then be helpful to replicate the Rule ID within the Edit view of each Rule?

Why do you need the rule ID?

[LibraSun]

Armed with the unique Rule ID, one can (somewhat more) quickly do a "FIND" in Notepad while looking at REACTOR.LOG

[toggledbits]

Got it. Name is also logged, although not as frequently in the debug levels.

It looks like the only way I can avoid the complete takeover of mousedown by the draggable/sortable is to use a drag handle, e.g. an icon on which you click and drag to move the row. That's done elsewhere, so it would be consistent. I can see other reasons in future to want to interact with the detail card, so I'm leaning towards it right now.

[LibraSun]

FEATURE REQUEST(?)

Place a warning in Global Expressions area that "These are not to be used as stand-alone Triggers. Will not be evaluated unless called from another resource (e.g. Rule-based expressions)."

And if this assumption is accurate (I could be misinterpreting? Rules just didn't seem to fire unless they have another in-house Trigger or local copy of said Variable), then also warn in Rules for which there is only a Global Expression and nothing else Trigger'ing it.

[LibraSun]

MSR USAGE QUESTION

Is there a (straightforward) way to do Dev# substitution into the new way (e.g. getEntity( "vera>device_216" ).attributes.battery_power.level) that attribute values get referenced in MSR?
Back on Reactor for Vera, I used to iterate over getstate( DeviceNum, "urn:micasaverde-com:serviceId:HaDevice1", "BatteryLevel" ) to derive the current battery levels on various devices. And I'd somewhat hate to have to hard-code or write out all of them by hand if I don't have to in MSR.