Reactor-Editor / Reactor-ui-Status Errors

[gwp1]

@tunnus That would work if I were creating the OWM like I've created the Ambient expressions and ruleset. But @toggledbits has OWM built-in, controlled by reactor.yaml config file. The frequency of calls to the API is configured there in minutes and it creates an entity in the Entities list. As I understand it, the entity is always refreshed data-wise by the frequency of the calls set in reactor.yaml.

[toggledbits]

@gwp1 said in Replacing SiteSensor Plugin (Vera) with MSR:

@toggledbits QQ on the OWM built-in: is there a means by which to render it inactive until I need to call it?

No. Controllers can only be switched on and off via configuration.

[gwp1]

@gwp1I got this all working, Ambient's API and OWM's API all dumping to global expressions.

ambient_api
ambient_temp
ambient_windspeed
ambient_windgust
ambient_solarradiation

openwxmap_api
openwxmap_temp
openwxmap_windspeed
openwxmap_windgust

Everything is glorious. I've planned for when the Ambient API drops (they were having big ol' issues today and into the evening now) it returns a NULL and I flip my HVAC control over to OWM API.

Except... Reactor gets very angry.

Now it's entirely possible this is on me - so let's review:
HVAC has three master rulesets, Cooling, Heating, and Neutral. You'll notice I've broken out the rules into Ambient vs OWM.

The triggers for OWM include a "when Ambient returns NULL" clause, if you will.

These are my two "Site Sensors" in MSR:

This, too, works as intended with OWM sitting idle until Ambient goes "null" and then OWM starts making API calls and populating the global expressions with data.

In real world usage today/this evening the switch happens flawlessly. Where the angry Reactor comes in is after the switch happens. My confusion is around why any ruleset referencing the Ambient data (via global expressions) as a trigger suddenly has all the compile errors, throttling because update rates exceed 60/minute, etc. My expectation is that the "null" will blank the triggers in the ruleset and, since the ruleset is not triggered, it will go dormant until triggered again.

Where have I lost my way?

[tunnus]

@gwp1 I get similar throttling warnings as you do when rules are not able to get values they used to get (via API), but at least you can eliminate those "invalid reference" errors using the following expression structure:

[gwp1]

@tunnus Pardon my ignorance but where do I utilize this structure?

[toggledbits]

I don't recommend using if statements. There are coalescing operators to make the deferencing through the structures easier and tidier when null is a possibility. See the documentation

Also your API Sensor OpenWxMap would be better without the Interval condition and applying pulse output mode (condition options) on the null test.

As for the throttling, I would comb through all of your rules and reactions to see if you have any left-over Set Variable or other actions that would change the value of any of the subject variables. Something seems to be competing with what you've shown here.

[gwp1]

@toggledbits I'm not understanding Pulse vs Interval. That trigger is intended to be how often it queries the API (yes, five minutes is aggressive - I'll pull that back once this is all working.)

There's nothing writing to those variables as they never existed prior to just a day or two ago when I reopened this project of migrating off of Vera's Site Sensors.

Now, there are a slew of rulesets READING from those. That's where my confusion lies, also. In my mind, if it reads the data and it doesn't match the trigger criteria it should just stop until the data changes again, no?

For instance, the Fountain ruleset is complaining. But it's only set to read from Ambient API values - it should be done until there's Ambient data.

[toggledbits]

It's just an alternate way of doing things. I'm not a fan of Interval conditions, and view them as a necessary evil, so I try to remove their use whenever alternate functionality accomplishes the same.

The big problem you have here overall is that, currently, global variables changing does not drive rule evaluations. I think this came up in the other thread. Just because your Ambient fetch rule is updating ambient_api does not mean that ambient_temp is being updated in that same instant (that depends on how you are setting it, which you haven't shown us), and just because ambient_temp changes (no matter how you set it) doesn't mean that "Fountain via Ambient API" suddenly wakes up and checks it. This may simply be a current limitation of global variables as implemented that needs to be reviewed.

Another issue I see here is simply one of structure. If you've got "Fountain via Ambient" and "Fountain via OpenWxMap", then I assert you're making your life harder. It would be better to have a current_temp rule that itself decides if it is going to use Ambient or OpenWxMap, and the "Fountain" rule (singular) has no idea where that data came from and doesn't care.

current_temp = isnull( ambient_api?.whatever?[0] ) ? openwxapi?.whatever?[0].temperature :
    ambient_api.whatever[0].temperature

Also, even if everything operated to your assumptions, you have a race condition. There's an instant while the first OpenWxMap fetch is occurring that the query data from a previous query of hours, days, weeks, or months ago may be used, and that may cause reactions you don't intend until the OpenWxMap fetch succeeds and the data is updated. This is a side-effect of your goal of avoiding continuous OWM calls. There are workarounds, but the issue is moot at this point because the entire thing doesn't work like you think it does.

The implementation decision to not have global variables drive rule evaluation occurred early on. There were issues that prevented it, but since then, the rule evaluation algorithm has changed substantially. I'd need to study and test if this can be changed to work well under the new order. I agree it would be "better" (work more like expected) if rules could respond to global variable changes, but there are many opportunities for logic loops and other issues in doing that, so figuring that out and how to maintain control of the system and give the user meaningful feedback about such errors may not be a small task. (So I'm saying, I won't fix it today. Tomorrow's not looking good either.)

[gwp1]

@toggledbits Firstly, there is no "Fountain via OWM" as it's missing one of the metrics I use to drive that stupid thing.

Secondly - yes, if global variables do not drive rule evaluations then this whole idea is moot. I was hoping to pull Site Sensors out of Vera at long last. It appears, at least taking the path I did, that this is not viable.

Regarding how I have ambient_api set:

That populates the rest of the global expressions:

I need to think thru this some more if Global Expressions will not work as triggers. Has to be a way to present those datapoints as triggers like I've done with the Vera Site Sensors.

[toggledbits]

Give me a couple of days to see what I can noodle out on this. So far, things are looking like they're going the right direction, but sometimes you get >80% of the way before realizing you've painted yourself into a corner and need to take a different approach. Stay tuned!

[gwp1]

Preaching to the choir. As you're well aware from my previous escapades, I do tend to make things much more complicated than they need to be. I don't want you compromising your product, though, just because I am going down the wrong path. Steer me back!

I would very much love to have shared elements like the outdoor temp, wind speed, and solar radiation something I can just point to. I've finally done that with HVAC, having only one master set and then pointing to them with the HVAC Ambient and HVAC OWN rulesets. Consolidation is king!

[tunnus]

@toggledbits Better?

[gwp1]

@tunnus I'm back knocking on this again. lol

I've enabled the OWM controller via reactor.yaml and this will be the dumbest question of the day, @toggledbits, but where do I see the results from it? Are new Entities created or should they appear under OWM Weather?

I know I'm gonna feel like an idiot at the answer but I can take it lol

[toggledbits]

Yeah, it creates new entities. In the Entities list, you can filter by controller. Do that. It should pop right out at you. If you want to get even more specific, filter on the wx capability, which is used by the entities that the controller publishes, and these are the entities you will want to use in rules.

[gwp1]

@toggledbits Hmmm... I'm.... not seeing the new entities at all.

Mental checklist/talking out loud:

• It's the same API/application key from SiteSensor in Vera and verified working.
• I went with the basic config, using default location.
• Restarted MSR via Tools
• Key is not encased in single quotes

Refresh is set to 10: for now - does MSR do an automatic call on restart?

[toggledbits]

Did you enable the controller in its config?

[gwp1]

Hang on lol. So it seems it creates the Entity as the location name, in my case "Charleston" and then the wx entities UNDER it. I should have picked that up from your screenshot with "PCT Current Weather" being the location.

Only oddity.... this entry:

wx.location="Melgrove (historical)"

The rest of the data seems to line up just fine so that appears to be an outlier.

[toggledbits]

@gwp1 said in Replacing SiteSensor Plugin (Vera) with MSR:

wx.location="Melgrove (historical)"
The rest of the data seems to line up just fine so that appears to be an outlier.

It's just what OWM returns for the location search given. Every location has official place names. Here in the US, the United States Postal Service has the official place names (for the most part), and we can end up with some "official" designations that have nothing to do with how the locals see it, sometimes decades-old and long disused (working at the speed of government, there). The installation instructions recommend using the official OpenWeatherMap city IDs for the greatest reliability in determining location, so you may want to look into that.

it creates the Entity as the location name, in my case "Charleston" and then the wx entities UNDER it.

Oh, and terminology here... the entity is given the place name (as set by the name field in your config, or if not set, other defaults), so Charleston here. The wx is a capability assigned to entity, not an entity under (or within) the Charleston entity.

[gwp1]

I will update the MSR config to be more specific vs using the lat/long from the base location. I believe that's how I did it in SiteSensor, actually.

Terminology is completely where I missed the data that was clearly present the entire time. Once again, a fine example of "ALL THE WORDS MATTER."

[gwp1]

The final update here was that I decided against the onboard OWM config and went with creating matching Global Expressions generated via API call that I was using for Ambient's API. Consistency goes a long way for me. Paired up with matching HVAC rulesets that pull from the appropriate expressions and viola.

My biggest concern was around making useless calls to OWM's API (I try to be a responsible Netizen). I'd resolved that with SiteSensor by having the OWM version only arm itself when the Ambient one failed but, alas, that was not to be the path forward here. I bit the proverbial bullet and have the two running simultaneously and use NULL results from Ambient as my trigger for which rulesets actually action the HVAC. It's been working quite smoothly, knock on wood.

I do see instances were Honeywell's API for the stats is just a bit finicky about setting both stats in a single call. To resolve this I've added some "course correction" rulesets that resend the correct setpoints after seven minutes. So far, so good.