OpenAI Controller for Reactor

[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.