Replacing SiteSensor Plugin (Vera) with MSR
-
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.
-
-
OK so lets say I now have a variable in MSR that contains some data pulled down from a HTTP Request to some online API somewhere.
How can I send that value / information to a Generic IO Sensor in Vera ?
I know how to create a GenericIO device in Vera and I know how to send data to it from a simple HTTP command, for example this command will send the text "Hello World"
http://Vera-IP/port_3480/data_request?id=lu_variableset&DeviceNum=128&serviceId=urn:micasaverde-com:serviceId:GenericSensor1&Variable=CurrentLevel&Value=Hello WorldAnd here is the device in Vera:
But how to create a rule to send the contents of an MSR variable (expression) ?
-
I'm going to assume the data was returned in JSON format? In which case MSR treats that like an object {}, whose keys can be referenced with dot notation.
For example, if your variablerespDatastored the response {animal:"cat", clothing:"suit", food:"chow"} and you want to send the current value of the "chow" key therein, simply reference that value withrespData.chow.One hurdle you may have to overcome, since the data is being fetched and stored in Rule A, but you want to reference the results in Rule B, is that you'd then have to either (a) store respData as a Global Expression, or (b) create a blank Expression in Rule B, and tell Rule A to [Set Variable] on it.
-
OK so lets say I now have a variable in MSR that contains some data pulled down from a HTTP Request to some online API somewhere.
How can I send that value / information to a Generic IO Sensor in Vera ?
I know how to create a GenericIO device in Vera and I know how to send data to it from a simple HTTP command, for example this command will send the text "Hello World"
http://Vera-IP/port_3480/data_request?id=lu_variableset&DeviceNum=128&serviceId=urn:micasaverde-com:serviceId:GenericSensor1&Variable=CurrentLevel&Value=Hello WorldAnd here is the device in Vera:
But how to create a rule to send the contents of an MSR variable (expression) ?
@cw-kid said in Replacing SiteSensor Plugin (Vera) with MSR:
But how to create a rule to send the contents of an MSR variable (expression) ?
In case you revised your question, or I misinterpreted it earlier, here goes:
It sounds like you want to send data from MSR to a plug-in / virtual device / sensor over on Vera. Before you begin, go to that "device" > Advanced > Variables and determine which of its variables is intended to receive the data.
Click "EDIT" next to that variable, and look for its complete "service" name in the window; copy that string for use back in MSR.
Close that window on Vera, then head back over to MSR.
In MSR, you will want an [ENTITY ACTION] in the Set Reaction. Choose the target device as the 'Entity' and choose "x_vera_device.set_variable" as the action.
Fill out the three fields, where "service:" and "variable:" come from the string you copied earlier. For "value:" either type a constant (numeric or "text"), or a variable name properly clad in curly brackets ( e.g. ${{respData}} ) so the value gets substituted next time the Rule triggers.
Hope this helps!!
-
Try lowercase "uk" the way they show in the API docs, perhaps?
accept: application/json
Response should be in the form:
[ { "country": "UK", "code": "GB", "confirmed": 4319128, "recovered": 3748042, "critical": 683, "deaths": 126445, "latitude": 55.378051, "longitude": -3.435973, "lastChange": "2021-03-25T18:23:06+01:00", "lastUpdate": "2021-03-26T14:15:03+01:00" } ] -
Try lowercase "uk" the way they show in the API docs, perhaps?
accept: application/json
Response should be in the form:
[ { "country": "UK", "code": "GB", "confirmed": 4319128, "recovered": 3748042, "critical": 683, "deaths": 126445, "latitude": 55.378051, "longitude": -3.435973, "lastChange": "2021-03-25T18:23:06+01:00", "lastUpdate": "2021-03-26T14:15:03+01:00" } ] -
Not a coder, but have been messing about with Vera's Generic IO Sensor device and managed to create a new instance that can accept multiple variables.
So if these HTTP request headers start working, I should be able to push some Covid stats to this "Generic Sensor" in Vera as a test.
Does something like this kind of device for displaying data already exist somewhere?
-
Not a coder, but have been messing about with Vera's Generic IO Sensor device and managed to create a new instance that can accept multiple variables.
So if these HTTP request headers start working, I should be able to push some Covid stats to this "Generic Sensor" in Vera as a test.
Does something like this kind of device for displaying data already exist somewhere?
@cw-kid said in Replacing SiteSensor Plugin (Vera) with MSR:
Does something like this kind of device for displaying data already exist somewhere?
Yes, the SiteSensor plug-in ( also by @toggledbits ) for Vera.
-
Doesn't make any difference with lowercase "uk"
My expression in the rule says "null" and no data is being brought down.
@cw-kid said in Replacing SiteSensor Plugin (Vera) with MSR:
My expression in the rule says "null" and no data is being brought down.
If it's any consolation, their site seems to be throwing a 500 error when I try to visit https://covid19-api.com/country?name=uk&format=json in my browser. How about yours?
-
@cw-kid said in Replacing SiteSensor Plugin (Vera) with MSR:
My expression in the rule says "null" and no data is being brought down.
If it's any consolation, their site seems to be throwing a 500 error when I try to visit https://covid19-api.com/country?name=uk&format=json in my browser. How about yours?
@librasun said in Replacing SiteSensor Plugin (Vera) with MSR:
If it's any consolation, their site seems to be throwing a 500 error when I try to visit https://covid19-api.com/country?name=uk&format=json in my browser. How about yours?
Same for me also.
However try their CURL command in a terminal window, that works and brings back data OK
