[Reactor] Variables not updating correctly in latest-25201-2aa18550

[LibraSun]

The simplest possible suggestion I can come up with involves creating a go/no-go variable within each Rule you'd like to control in that fashion. By creating an empty expression (let's call it "Go") in Rule A, for example, you could add a Constraint in Rule A:

[Expression Value] [ Go ] == 1

You could then, in Rule B, use a [Set Variable] [ Go ] = 1 (yes, MSR rules can now see each other's settable variables!) when you want Rule A active, and = 0 when you want Rule A deactivated.

Did I come close to answering your question?

[gwp1]

I'm... not sure lol I'm not savvy in proper use of expressions so there needs to be more meat added to this bone for me to fully grasp it, I'm afraid.

[LibraSun]

Give it time, as there is a shallow-but-nonzero learning curve moving from Reactor over to MSR. Let's keep this conversation going until you have things working according to plan. Don't hesitate to post screenshots of your work for us to review.

My suggestion is to start with "Test Rules" that you build for no particular purpose (certainly not for daily driving of Vera devices!), just to kick the tires with. This is a good way to get a grasp of how Expressions work in particular. I probably create and destroy 3-4 throwaway Test Rules every day, just workshopping different approaches to problems similar to yours.

[gwp1]

Oh I have made very liberal use of Test rules, believe me lol It's been very helpful. I'll try to pull together some screenshots here shortly. As to Reactor>MSR, yes, there's a slight curve. I've been able to pare down my Reactor device designs considerably using MSR.

[gwp1]

@librasun

This is the high-level architecture. Three arming rules, then the appropriate on/off rules that trigger when the arming criteria are met.

[gwp1]

Continuing, there were two SiteSensors in Vera - I've moved the Ambient API one to MSR as noted above with the high-level.

In Vera, it's easy to turn on and off the SiteSensor for OpenWxMap to reduce API calls based on query results from the Ambient API SiteSensor. There's a ruleset moved into MSR that drives the failover/back.

In MSR, however, I cannot turn off the OWM ruleset when Ambient API is driving. The result becomes two sets of data being sent to the t-stats which annoys them.

Currently, I'm using the SiteSensor for OWM in Vera and the ruleset in MSR for Master failover/back and driving Ambient data to the t-stats.

[LibraSun]

Remember, it's entirely plausible to introduce an expressionless (empty) "Go" variable within any Rule, such that the Rule A "runs" (acts Enabled) with "Go" set to "1", and is barred from running (acting Disabled) with it set to "0".

To make this setup work, simply have your other Rule B's Set Reaction do a [ Set Expression ] [ = ] [ 0 ] on Rule A's variable "Go", with a [ Set Expression ] [ = ] [ 1 ] in its Reset Reaction. Create a corresponding Trigger condition in Rule A that tests [ Expression Value ] [ == ] [ 1 ], and you should be good to go.

Does that make sense? Hope it helps!

NOTE: You can also use true / false values for Go and make your Rule A's Trigger condition check for [isTrue] instead.

[gwp1]

@librasun Wait, what? Slow pitch this - I've never played with the expressions before.

[LibraSun]

Before I do (let's save Expressions for very last...), please explain how MSR could "know" which version of the weather sensor you want enabled?? I'll go re-read your posts from the past 24 hours to see if I can ascertain same.

[LibraSun]

For instance, I heard you say, "I cannot turn off the OWM ruleset (in MSR) when Ambient API is driving". Couldn't its governing Rule just have an extra Constraint condition like:

[ Entity Attribute ] [ SiteSensor_156 ] [ x_vera_device.failed ] [ isTRUE ]

so that it refrains from execution while Ambient is in good health?

[gwp1]

Fair enough on the explanation - I prob made that typical error of not providing the details that I "just know" in my head.

Original Vera setup: two SiteSensors, one for Ambient API, one for OWM API. Ambient is hyper-local (my wx station) and is the daily driver. To save API calls against OWM, the SiteSensor there is set to disabled status normally.

If Ambient API call returns zero results, the Master API ruleset sees the failure, changes OWM API SiteSensor to enabled. As the query results from Ambient are blank, it is left in enabled status - and there's only one set of data points going to the t-stats.

Once Ambient API call returns regular results again, the Master API ruleset sees the actual data and changes OWM API SiteSensor to disabled again and life is, once again, good for all.

Can you define for me "refrains from execution"... are you saying it would not send anything to the t-stats or query the API (or both)?

[LibraSun]

From all I see (I just stopped short of saying it explicitly earlier), you're asking, "How can I temporarily stop MSR from sending API requests to OWM?" I don't see an immediate way to set that mechanism's sys_system.state= to false, although that was my initial thought.

I think we'll have to ask @toggledbits to advise on best practices here.

[gwp1]

@librasun I poked at this a bit with what I thought you were getting at. The configuration now (which is a carry-over from Vera Reactor and could prob use some trimming) has the top three rulesets (shown earlier) use to arm the system, ie set the parameters for what qualifies as "I should heat now" or "I should cool now" - and then the five rulesets below are the actual action rules.

For instance, if the system "qualifies" for (or is armed) for Cooling then only the two rulesets for Cooling are actionable. Same applies for Heating.

Taking what you said earlier, I added a condition to each of the action rulesets as shown in this example:

I was missing the reality of the action rulesets still running even though none of the qualifiers/armers were, well, armed. The action rulesets were using the last known datapoints stored in the armers - and that's where things were going amiss.

By adding the extra condition to each action ruleset it seems to have quieted - this may be the solution (not pretty, but a solution.)

[gwp1]

@librasun The arming rules look like this:

In my mind, all of these conditions were rolling down to the action rulesets - which is not true.

[LibraSun]

I'm liking what I see. We both know there are always 1000 avenues to "the right answer" but what you've just presented seems reasonable and suited to your original goal(s).

[gwp1]

@librasun Thanks, and totally agree.

My goal is always to keep things as uncomplicated as possible as changes or tweaks later get crazy if you have to edit in multiple places. You ALWAYS miss something somewhere and lose countless hours trying to troubleshoot.

[gwp1]

As I'm marking this as [SOLVED] I thought I'd update on how this all ended up playing out:

Creation of two API rulesets, one for Ambient, one for OWM, that dump their data into Global Expressions. At issue was how to disable OWM to prevent needless API calls - I ended up doing the maths and making adjustments that this isn't an issue any longer. As such, one API ruleset for each dumping to clearly labeled Global Expressions. Yes, they both call out to their respective APIs but the volume is low enough not to trigger either for overuse.

The only gotcha here is to make sure that you include in the rulesets for the secondary (OWM) a Trigger that checks for the primary API to be returning null so you don't have both flavors of rulesets competing for Honeywell's API (which is notoriously cranky) as you set the t-stats.