Replacing SiteSensor Plugin (Vera) with MSR
-
In your
reactor.yaml, did you switch the "enabled" setting for the weather to enabled? Maybe show/post your config section for that controller? -
Great. If you filter the "Entities" list (left nav) for the "wx" capability, you should find the entity that contains your local weather data.
-
There's a OWMWeatherController built-in to MSR. If you're going to use OpenWeatherMap, that's a more efficient way to go about it. For other API integrations, the method described above is useful.
@toggledbits said in Replacing SiteSensor Plugin (Vera) with MSR:
There's a OWMWeatherController built-in to MSR.
Could you possibly shoe-horn lat, lon, location (city) name, time zone, etc. with that object? Or do those values already surface elsewhere in MSR?
I'd be interested in using them as part of my "Weekly Report" quasi-mailmerge notifications.
-
OPENWEATHER PRO TIP
Users of MSR's built-in weather object ('weather>default') may wish to know how to convert the value in
wx.iconto an actual thumbnail image.Here's how:
Suppose the value stored in that variable is '01d'
Simply prepend 'http://openweathermap.org/img/wn/' to the beginning, and append '.png' to the end. (You can enlarge the image by including '@2x', '@4x', etc. before the '.png'!)Better still, gather all of the icons files from https://openweathermap.org/weather-conditions and host them on your own local server/repo, to spare OWx from excess bandwidth. You can also grab their table of "Weather Condition Codes" containing a description of each possible value in
wx.condition_code.These tirbits would be helpful in designing a dynamic "Weather" tile for the MSR Dashboard feature!!
EXAMPLES:
Condition: 01d = "Clear Sky (day)"
Condition: 04n = "Clouds (night)" -
FEATURE REQUEST
Add "Solar Noon" to Sunrise/Sunset trigger in MSR, even if it's just derived as "halfway point between Sunrise and Sunset"
(No need for "Civil Noon" since that's automatically 12:00pm)Could be useful for farms, solar installations, etc.
-
That's easy, it has it, so all I need to do is add the menu item to the UI.
-
Great. If you filter the "Entities" list (left nav) for the "wx" capability, you should find the entity that contains your local weather data.
@toggledbits I found this:
Oddly, the historical is returning Melgrove lol I left the config so that it would pull from the default location which is using lat/long.
-
I'm not sure where you're going with this post? Are you reporting a problem?
-
I'm not sure where you're going with this post? Are you reporting a problem?
@toggledbits I guess I am - unless I'm misreading the docs. I believe to have OWM set to use the default location of MSR which is Hanahan SC, not Melgrove Someplace.
I don't want to file a bug until I'm sure it's MSR and not me.
-
OK. In order to sort that out, I need to see your configuration for both the default system location and OWM. Post here or PM is fine.
-
OK. In order to sort that out, I need to see your configuration for both the default system location and OWM. Post here or PM is fine.
@toggledbits Posted via PM.
-
OK. Looks like all is good, OWM is just returning an odd place name (who knows what data they sourced that from), and since you are using "default" configuration (home location from Reactor main config), it's using OWM's returned name for the entity name. If you do a custom location in the OWM config, you can set the name by adding the "name" to the custom config. I'm going to extend that behavior to the default location config as well, and that will be in today's build. If you want to get it fixed before that, just add a location to your OWMController config section:
- id: weather enabled: true implementation: OWMWeatherController name: OWM Weather config: appid: "yourappidhere" locations: - id: home name: "My Custom Place Name" latitude: nn.nnnnnn longitude: nn.nnnnnn -
OK. Looks like all is good, OWM is just returning an odd place name (who knows what data they sourced that from), and since you are using "default" configuration (home location from Reactor main config), it's using OWM's returned name for the entity name. If you do a custom location in the OWM config, you can set the name by adding the "name" to the custom config. I'm going to extend that behavior to the default location config as well, and that will be in today's build. If you want to get it fixed before that, just add a location to your OWMController config section:
- id: weather enabled: true implementation: OWMWeatherController name: OWM Weather config: appid: "yourappidhere" locations: - id: home name: "My Custom Place Name" latitude: nn.nnnnnn longitude: nn.nnnnnn@toggledbits I'm a few nightly builds behind so I'll wait until you have tonight's out. Thanks!
-
For MSR users with SiteSensor still installed back on Vera, you might want to consider letting MSR take over those duties. Here's a quick run-down of how I imported one of my SiteSensor recipes into a Rule on MSR, using OpenWeather API* as an example.
STEP 1:Copy the Basics from Vera
(a) Go to your Vera > Devices, locate SiteSensor (the main instance, not one of its children devices) and click ► for details then click SETTINGS.
(b) Copy and paste (into Notepad or other text editor) the Request URL along with each of the defined expressions.STEP 2:Create a Rule on MSR
(c) Jump into Rule Sets and click "Create Rule". Click its title to rename the rule 'OpenWeather (API)" and click 'Rename'.
(d) Decide on appropriate Triggers (in my case, it's an OR group that includes an [INTERVAL] set to "Every 3 hours" plus a few [ENTITY ATTRIBUTE] entries reacting to things like entering/leaving home, waking up, etc.).
(e) In Set Reacion, create an [HTTP REQUEST] > [GET] action.
(f) Paste your old "Request URL" into the "Request URL" box.FYIGET calls to OpenWeather API* take the form:http://api.openweathermap.org/data/2.5/weather?zip=<your_ZIP_code>&id=<your_Wx_ID>&appid=<app-id>&units=imperial(g) Create four new blank Expressions (name them
openWx,Tx,HxandRx).
(h) ClickSAVE&EXITSTEP 3:Process the Response
(i) Re-open rule "OpenWeather (API)" by clicking the 'Edit' icon.
(j) Within the [HTTP REQUEST] action, assign "Capture response to:" ►openWx
(k) Down in Expressions, click "[+]Add Expresssion" then enter the following:
Tx:=round(openWx.main.temp,1)
// yields current outdoor temperature
Hx:=round(openWx.main.humidity)
// yields current humidity conditions
Rx:=openWx.rain ? ( openWx.rain['3h'] ? openWx.rain['3h'] : 0) : 0
// yields predicted rainfall, if present; otherwise 0
(l) ClickSAVE&EXIT. Enjoy!Naturally, your specific needs and workflow will differ from the one I've outlined here. For instance, you may wish to explore the contents of the JSON object in
openWxfor additional data of interest to you, and define variables to match.My goal here has been to illustrate some key concepts needed for moving from SiteSensor over to MSR:
- Some syntax is the same, such as dot notation for object.item.access;
- Other syntax has changed, such as the use of ternary A ? B : C in place of IF (A, B, C);
- Manually setting an [INTERVAL] in lieu of SiteSensor's timed schedule;
Pro tip: If your workflow demands that other Rules react to the output of the "OpenWeather (API)" rule, then be sure to create all of the aforementioned Expressions under "Global Expressions" instead, so they become accessible across all Rule Sets.
Once the transition is complete, you can either DISARM SiteSensor on Vera or remove it entirely with "Remove Device" (which will automatically remove all of its child devices).
*Additional reading:
OpenWeather API : https://openweathermap.org/api
FREE SUBSCRIPTION REQUIRED TO USE THIS SERVICEPRO TIP: See below for optimal way to incorporate OpenWeatherMap into your MSR workflow(s), by enabling the service directly in the reactor.yaml config file.
@librasun said in Replacing SiteSensor Plugin (Vera) with MSR:
My goal here has been to illustrate some key concepts needed for moving from SiteSensor over to MSR
I never used SiteSensor plugin for Vera before.
Thanks for the MSR example you wrote.
I wanted to try this out and found this Covid-19 API here.
However the http command they give doesn't seem to return any results data, either just in the web browser or in my MSR rule.
https://covid19-api.com/country?name=UK&format=json
The curl command does work OK however
curl -X GET "https://covid19-api.com/country?name=UK&format=json" -H "accept: application/json"How do I specify the application/json in the MSR rule? Assuming the problem is related to that.
-
Same way. One header per line in that field.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Same way. One header per line in that field.
In the "Request Headers" field in the "Set Reaction" I have tried the following:
Accept: application/json
and tried:
Content-Type: application/json
It allows me to save the rule but when I go back in to the rule that field is empty again and its not collecting the response data in to my empty expression / variable.
-
So there are two separate issues here:
-
First, we need to figure out if the UI is correctly storing the headers or not, and if the problem is merely that it is not restoring/displaying them correctly when you go back into the editor. The check for that is to go into the reaction, add the headers, and save. Then, open the rule status view and it will show you the rule ID underneath the rule condition status and expressions. Go to your
reactor/storage/rulesdirectory, and grab the same-named file (with.jsonsuffix) and post it here. Let's see what's being stored. -
Look at the logs to see where the reaction is running and what the request is doing. There may be errors logged.
It's entirely possible that the problem is 1, 2, or even both.
-
-
OK. There's definitely two broken things in the handling of headers, so go ahead and open a PR for this. No need to post the rule there (again); I've got it and have the issue in hand, but unfortunately, it's not just a UI issue.
