Reactor-Editor / Reactor-ui-Status Errors

[toggledbits]

The exit button does cause a pop-up if unsaved changes are pending, but I agree the three-button arrangement takes getting used to. So, you're suggesting just two buttons, "Save" and "Exit"?

[PerH]

I think so, yes. As simple as possible, unless we loose functionality, which i don't think is the case here?

[Matohl]

Yes, I agree with PerH here. Seems logical

[HSD99]

Piling on here---I also found this confusing. My assumptions: "Save" does just what it says. Hitting "Exit" will then exit with no prompt. Hitting "Exit" alone will prompt for "Save and Exit?" or "Don't save and exit" or something similar.

[toggledbits]

OK. We'll just have Save and Exit in 21059, with tooltips to tell you more detail (hover over the buttons).

[HSD99]

Great! Thanks!

[LibraSun]

Occurred to me this evening that you might even consider moving some of the Top Level headings in the left column under the Tools menu once it starts gathering stream.
Less used utilities like Scope and even Entities. Then add Backup & Restore, etc. Possibly Dashboard?
Tools could then act like a collapsible pane the way Rule Sets does, enabling users so sort it according to need.

[SweetGenius]

Is there a way to sort Rule Sets in the left hand column? Alphabetical order vs last created on top?

[LibraSun]

@sweetgenius No clickable sort mechanism (yet) just drag and drop for now.

[SweetGenius]

You are correct. That is what I wanted, Just not smart enough to try drag and drop. That works perfectly.
Thanks

[PerH]

Haven't touched my system for a while (or read updates here), busy with other projects..
Just have to mention that I updated to the latest today and found the new entity selector tool... LOVE it! That has been my only nagging thing about reactor since vera reactor, all that scrolling..
Thanks, @toggledbits, this is really turning into something VERY good!

[LibraSun]

@toggledbits I'm finally checking out the [RULE RESULT] condition type, and with only a cursory look (I don't recall it from the Docs -- just found its stub at /docs/Rule-Conditions/), come away with more questions than solid understanding... (the rest of my day will be spent gaining the latter):

• I see the options [is TRUE], [is FALSE], [is NULL], [is not NULL], and [changes state] (which make sense to me)
• I believe the [is NULL] state applies to the target Rule's status reading "undefined -- false as of 10:18:46" (i.e. "undefined" and NULL being treated as equivalent) -- but wonder if users should therefore see its status as "NULL -- false as of 10:18:46" for clarity?
• I believe that only Rules that have never (ever) been Run* will match with [is NULL]?
*Probably more apt to say "has never been RESET" (since I noticed never-run Rules on which I manually click RESET go from "undefined" to "null")
• Disabled rules, since they continue to display their last state (true or false), are not distinguished by this mechanism

In light of the last fact, I propose that two more states be included for testing: [is Enabled] and [is Disabled]

This would allow a couple of important decisions in the logic flow, such as "Don't do this if the other Rule isn't firing", as well as allow a kind of "Master Switch" setup whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

[toggledbits]

@librasun said in Low-priority GUI feedback:

In light of the last fact, I propose that two more states be included for testing: [is Enabled] and [is Disabled]
This would allow a couple of important decisions in the logic flow, such as "Don't do this if the other Rule isn't firing", as well as allow a kind of "Master Switch" setup whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

Slippery slope defined.

I've already been asked to make an action to enable and disable rules at will. This strikes me as a highway to nightmarish scenarios in which not only does a user's (and by extension likely my) troubleshooting necessarily include the already ample detective work of figuring out the states of conditions in enabled rules (and how the logic came to be, and what the problem is that that logic is intended to solve), but now also we have added carnival funhouse horror that any reaction anywhere in the system can enable or disable any rule at will. In other words, you're moving a part of the logic of a rule out to some other part of the system where there is no visibility from the rule in question that the rule may, in fact, be run or not. I have not yet seen an argument in favor of an enable/disable action that overwhelmes my concerns over how they will be applied.

So, if there's a test for is Enabled and is Disabled, I can see right on the heels of that the question coming (again) for an action to cause those states. And your further "Master Switch" comment pretty much confirms this direction.

whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

I'd rather provide a built-in set of virtual entities that live entirely in the MSR side. It's also more consistent with the model.

So, sorry, I understand how much power enable/disable might be, and how it could be used for good, but in this case the potential for abuse is rife.

[LibraSun]

All valid reasoning, as per usual. There's plenty logic in place as-is for users to construct what they need in the way of gates.

My next question has to do with HTTP Request: Do you plan to add "PUT" and other methods (e.g. "PATCH", "DELETE"), alongside "GET" and "POST"?

[toggledbits]

Yes, can do.

[LibraSun]

I vote that the expanded list of Rule Sets be (a) indented slightly, so as to distinguish them from the primary UI elements (e.g. "Entities" et seq), and (b) perhaps display a vertical rule | alongside to further differentiate them as a "submenu".

Something like:

Right now, the bold-vs-not-bold sometimes throws me, because my list of Rule Sets (greatly truncated here, for clarity) can be longer than the scroll window itself.

P.S. THANKS for the "PUT" and other verbs now available with HTTP Request!

[LibraSun]

@toggledbits would it be possible to augment vera>housemode with its own timestamp, so that repeated setting to the same mode can be detected? Currently, I have no obvious way to trigger on "HOME" if Vera is already set to "HOME", etc.

I wasn't even certain that Vera herself reacts internally in any way when I click "HOME" on the Dashboard while she's already in "HOME" mode, so I peeked in her LuaUPnP log and saw:

08	04/06/21 8:56:08.257	JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: SetHouseMode <0x70a0e520>
08	04/06/21 8:56:08.257	JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x70a0e520>
08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument action=SetHouseMode <0x70a0e520>
08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument Mode=1 <0x70a0e520>
08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument rand=0.7538517467636494 <0x70a0e520>
06	04/06/21 8:56:08.261	Device_Variable::m_szValue_set device: 224 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x1057770/NONE duplicate:1 <0x70a0e520>
06	04/06/21 8:56:08.282	Device_Variable::m_szValue_set device: 264 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x1057770/NONE duplicate:1 <0x

Short of creating a virtual switch or sensor that Vera "arms" on every mode change, I'm unsure how to detect the logged reactions back on MSR. Any thoughts?

P.S. Funny, I'm also just discovering that Vera cannot trigger her own Scenes based on House Mode changing. Who knew?

EDIT: So, I went with creating a (binary on/off) Virtual Switch using Switchboard plug-in. By having Vera turn this switch "On" for every House Mode, MSR can now detect "updates" to House Mode, not merely "changes". This is useful to my workflow. I'll simply create an additional action in SET REACTION which turns the new VS back "Off" automatically.

[toggledbits]

I would not be able to make this work on RFV or MSR. There is no timestamp for house mode on Vera because it isn't a state variable, it's an attribute of (virtual) device 0, the HomeAutomationGateway1 engine (which is why it appears as an attribute of the root in user_data). There's nothing to put a watch callback on, because you can only watch state variables. This is why the HouseModes plugin has to poll for changes. Reactor (for Vera) takes a different approach (to eliminate polling and the response delay it causes--RFV reacts immediately), but nonetheless can't see when house mode is set to what it already is because Vera itself won't take any action when that happens. And therefore MSR cannot see it either (although MSR uses yet another approach and can respond immediately on changes like RFV).

[toggledbits]

By the way, this could also segue into a treatise about why there's no updates operator in MSR, because it's related, so let's do that:

On Vera, every state variable also has a timestamp. The general behavior on Vera is that when a state variable value changes, its timestamp is updated as well. If a state variable is set to the same value it already has (write without change), the timestamp does not change. There are, however, exceptions to this rule: state variables whose name starts with sl_ will get a timestamp update when their value is set, even if it is set to the same value it already has. This specifically allows scene controllers, locks, and keypads to work. These device types all use sl_-named variables for those states/data that can be "active" when set to the same value (e.g. the same lock code is used twice on a keypad or lock, or the same button is pressed back-to-back on a scene controller).

This also manifests in Vera as a call to the watch callback for the variable, if any. The watch callback is typically only called when the value of the state variable changes, unless it's an sl_-named variable, in which case the watch callback is called unconditionally. This is how Reactor for Vera (RFV) detects and implements the updates operator.

Given that information, one might think that you can, from outside Luup (i.e. in MSR using HTTP requests for interface), detect same-value updates by tracking the timestamp, but there are two problems:

1. The timestamp is not exported in the user_data or status requests (or any that I'm aware of), so you can't access it from outside the system. The only place it is visible/available is within Luup itself by calling luup.variable_get();
2. Even if we got the timestamps, the timestamps are not stable, they are volatile: Luup does not store the timestamps in user_data.json, it only keeps them in RAM (which is probably also why they are not exported). Every time Vera reloads, every state variable's timestamp is updated/rewritten to the current time during startup. So it's actually not usable as a persistent value to compare to prior values across reloads, it's only usable within the context of the current Luup reload. That raises the complexity of determining if a timestamp change is the result of an actual change, or a reload with no change in value, or a reload with a change in value during downtime.
3. If we stored timestamps with values, it would double the memory consumption of attributes (because then it has to store two values for every attribute rather than one, and there are a lot of attributes in memory), and do so only for the benefit of one operator applicable in a very small number of cases.

Aside from this, MSR isn't a Vera plugin, or a logic engine just for Vera. Neither Hubitat nor Hass, nor any other system I've yet seen, has timestamps with which an equivalent comparison could be made, or a replacement mechanism by which updates could be reliably implemented for entities originating in any HAC. So in all, updates hasn't (yet) shown a use case/demand that overwhelms the costs in the face of the available workarounds.

[LibraSun]

But I'd argue this also gives a solid rationale for instantiating a "Reactor Helper Service" back on the host controller, expressly for detecting and propagating these otherwise unavailable "Updates". I know you've considered it, and while not a top priority by any stretch, something to debate with MSR's most ardent users.