Replacing SiteSensor Plugin (Vera) with MSR
-
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.
-
I just this morning discovered this in MSR. I'm currently using two SiteSensors to read my Ambient weather station API and OpenWxMap's API. I use the data to drive HVAC reactors in Vera. Given the nature of APIs, I created the OpenWxMap one to be a backup. As such, there's a Master API Failover reactor in Vera that monitors the Ambient SiteSensor and, if the query fails, shuts it off and switches to the OpenWxMap SiteSensor. There are duplicate HVAC reactors, one for each API provider. When the next successful query from the Ambient SiteSensor is successful, the Master API Failover fails everything back again.
Given in MSR there are no reactor devices I'm stumped on how to turn on and off rulesets to duplicate the above.
Thoughts?
I've only had my MSR online for a week now so I'm still uncovering things within it.
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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 I dug about a bit and found this in the manual. How would I invoke this, I don't see anything in Entities (post-config)?
-
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.
