Replacing SiteSensor Plugin (Vera) with MSR
-
I've tried the Vera Multi-String plugin, it looks just like the type of plugin I was needing and looking for.
You can have up to five variables on a device.
You can then have your rule in MSR send the data to each variable etc.
The Multi-String plugin devices data is also outputted in the Vera SDATA stream so these device will also work with the Home Remote dashboard app.
{ "name": "Covid-19 Stats", "altid": "", "id": 133, "category": 0, "subcategory": -1, "room": 0, "parent": 0, "variablename1": "Confirmed", "variable1": "4329180", "variablename2": "Recovered", "variable2": "3787312", "variablename3": "Critical", "variable3": "615", "variablename4": "Deaths", "variable4": "126573", "variablename5": "", "variable5": "", "options": "", "configured": "0" },So I recommend using the Multi-String plugin rather than trying to create your own modified Generic IO devices as I was doing.
-
@cw-kid if one wanted to set all 5 parameter values at the same time, using an HTTP call to Vera, could that be done? (If so, I'd need to see a working example of a GET Request that does this.) Or would I have to issue 5 distinct calls to set those variables?
P.S. I see from this old post that I'm not the first one to wonder.
-
@cw-kid if one wanted to set all 5 parameter values at the same time, using an HTTP call to Vera, could that be done? (If so, I'd need to see a working example of a GET Request that does this.) Or would I have to issue 5 distinct calls to set those variables?
P.S. I see from this old post that I'm not the first one to wonder.
-
I am doing a different http request to Vera to set each variable not one request that set them all.
@cw-kid said in Replacing SiteSensor Plugin (Vera) with MSR:
I am doing a different http request to Vera to set each variable not one request that set them all.
Yeah, something tells me setting more than one at a time isn't possible, anyway. Just thought I'd ask the pros.
Thanks! -
You can take not-terribly-human-readable blobs like that over to a JSON Pretty Print website (such as https://jsonformatter.org/json-pretty-print), paste it in and hit the "Outline" button, to see how the data looks in its underlying structure.
This allows you to quickly pinpoint the blob.key.subkey.data item you need to pull from in MSR.Traversing the tree from upper-left to lower-right, I see the first instance of "forcecast" lives inside an overall object
{}(I'm namingresponse), then the first item (i.e. element0) of an array[]withindata, then inside another array within another key calleddata, then a key calledintensity, and finally the key you want,forecast, yielding:
response.data[0].data[0].intensity.forecast@librasun Reviving this a bit because this right here is where I think I'm failing spectacularly.
I'm working with the Ambient API for my weather station via Site Sensor in Vera. This thread has been fantastic at guiding me toward migrating the Site Sensor into MSR. Here's where I'm falling down:
The GET returns expected results. However, I believe I've messed up in creating the expressions for temp, wind speed, wind gust, and solar radiation.
I've entered
response[1].lastData.tempfinto the ambient_temp field and it returnsLast value:(error) Invalid reference to member 1 of null. This is taken right from the Site Sensor recipe where it's working wonderfully so I know I'm probably close. I know the expression logic in MSR is slightly different than that of the Vera Reactor plugin - combined with my almost total befuddlement of proper expressions go isn't helpingAppreciate any guidance!
-
@elcid Whadya know, that did the trick. Interesting to a noob like me how the original Site Sensor in Vera uses response[1].lastData.tempif and that works just fine.
-
@toggledbits QQ on the OWM built-in: is there a means by which to render it inactive until I need to call it? The way I work my Site Sensors is the one for OWM stays deactivated until the one for Ambient throws
nullat which point the OWM turns on, carrying the load until Ambient throws real data back out there again (at which time OWM shuts back off.)This saves wasted calls to the API for OWM.
*Hubitat C-7 2.4.1.177
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.6.0
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25139-fbd67abc
MQTTController: 25139
ZWave Controller: 25139 -
@toggledbits QQ on the OWM built-in: is there a means by which to render it inactive until I need to call it? The way I work my Site Sensors is the one for OWM stays deactivated until the one for Ambient throws
nullat which point the OWM turns on, carrying the load until Ambient throws real data back out there again (at which time OWM shuts back off.)This saves wasted calls to the API for OWM.
-
@elcid Whadya know, that did the trick. Interesting to a noob like me how the original Site Sensor in Vera uses response[1].lastData.tempif and that works just fine.
-
@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 QQ on the OWM built-in: is there a means by which to render it inactive until I need to call it? The way I work my Site Sensors is the one for OWM stays deactivated until the one for Ambient throws
nullat which point the OWM turns on, carrying the load until Ambient throws real data back out there again (at which time OWM shuts back off.)This saves wasted calls to the API for OWM.
@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.
-
@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.
@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_solarradiationopenwxmap_api
openwxmap_temp
openwxmap_windspeed
openwxmap_windgustEverything 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?
*Hubitat C-7 2.4.1.177
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.6.0
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25139-fbd67abc
MQTTController: 25139
ZWave Controller: 25139 -
@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_solarradiationopenwxmap_api
openwxmap_temp
openwxmap_windspeed
openwxmap_windgustEverything 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?
