[SOLVED] Rethinking HVAC moving from Reactor (Vera) to MSR
-
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.
-
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.
-
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.
-
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/falsevalues forGoand make your Rule A's Trigger condition check for [isTrue] instead. -
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/falsevalues forGoand make your Rule A's Trigger condition check for [isTrue] instead. -
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?
-
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
disabledstatus 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 inenabledstatus - 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
disabledagain 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)?
-
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=tofalse, although that was my initial thought.I think we'll have to ask @toggledbits to advise on best practices here.
-
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=tofalse, although that was my initial thought.I think we'll have to ask @toggledbits to advise on best practices here.
@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.)
-
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=tofalse, although that was my initial thought.I think we'll have to ask @toggledbits to advise on best practices here.
-
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).
@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.
-
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).
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 APIrulesetfor each dumping to clearly labeledGlobal 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
Triggerthat checks for the primary API to be returningnullso you don't have both flavors of rulesets competing for Honeywell's API (which is notoriously cranky) as you set the t-stats. -
T toggledbits locked this topic on
