Preview of Multi-System Reactor
-
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.
@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.
-
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.
-
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 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.
-
LEARNED SOMETHING TODAY
- You can click-and-drag Rules to reorganize them in Rulesets. Who knew?
- You cannot, however, click-to-highlight the Rule ID of an expanded rule, in order to copy that text.
- 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.
-
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.
-
LEARNED SOMETHING TODAY
- You can click-and-drag Rules to reorganize them in Rulesets. Who knew?
- You cannot, however, click-to-highlight the Rule ID of an expanded rule, in order to copy that text.
- 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.
@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.
-
re: #2 it might then be helpful to replicate the Rule ID within the Edit view of each Rule?
@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?
-
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.
-
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.
-
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 overgetstate( 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. -
@toggledbits
Could you share a rule for one Room so we can see how it could look like with multipel reactions that has different conditions.
I Don’t really understand how multipel reactions on diffrent conditions should look like. In Reactor it was easy to understand but in msr i Don’t get it..I really Wanja make more complicated automations but Iam stuck with one reaction...
/ Mattias -
@toggledbits
Could you share a rule for one Room so we can see how it could look like with multipel reactions that has different conditions.
I Don’t really understand how multipel reactions on diffrent conditions should look like. In Reactor it was easy to understand but in msr i Don’t get it..I really Wanja make more complicated automations but Iam stuck with one reaction...
/ Mattias@matteburk Did you do an import of your Vera reactor sensors? It is different in MSR but I compared the MSR imported rules vs Vera reactors and it helped me figure out what was going on.
-
There are no reactions on groups in MSR. Reactor for Vera allowed you to create activities (its equivalent to reactions) on any group in your ReactorSensor.
So, if you are creating a rule with subgroups in MSR, and you decide that the subgroup needs to perform some actions, you have export that subgroup to a Rule of its own. There is a button for that. If you click that button on a group (to the right of the group name), it will export the group to a Rule, and replace the group with a "Rule" condition for the new rule so the logic remains intact in the current rule.
-
There are no reactions on groups in MSR. Reactor for Vera allowed you to create activities (its equivalent to reactions) on any group in your ReactorSensor.
So, if you are creating a rule with subgroups in MSR, and you decide that the subgroup needs to perform some actions, you have export that subgroup to a Rule of its own. There is a button for that. If you click that button on a group (to the right of the group name), it will export the group to a Rule, and replace the group with a "Rule" condition for the new rule so the logic remains intact in the current rule.
@toggledbits@toggledbits Ok Then I understand but I cant find the button... I have Button,rename and collapse and then som shaded row...
Skärmavbild 2021-03-17 kl. 18.58.28.png -
Are you on 21075? Version number in the upper-right corner.
-
@matteburk Did you do an import of your Vera reactor sensors? It is different in MSR but I compared the MSR imported rules vs Vera reactors and it helped me figure out what was going on.
