New Plugin: SiteSensor

Plugins & Plugin Development General Plugin Discussion
#222

I’m doing the same … trying to leave behind Dark Sky and headed toward OpenWeatherMap.org, whose API is incredibly straightforward.

Thinking of writing up using that API with both Reactor and SiteSensor so others can compare those two different workflows. But I need to figure it all out for myself first, lol!

2 Likes
#223

That would be a service to the community indeed!

1 Like
#224

Another option I am using with sitesensor for my rainsensor:

I am using the free tier which has daily weather and forward 16 days.

#225

There’s a recipe for OpenWeatherMap.org in the SiteSensor documentation.

The new development (Github stable branch) version of SiteSensor has also introduced “recipes” as a feature: a portable snapshot of a SiteSensor configuration that you can pass along to others. Here’s the recipe for OpenWeatherMap:

=== Ident: OpenWeatherMap version 1579046094 by rigpapa; OpenWeatherMap Current Conditions; requires API key from openweathermap.org
=== BEGIN SITESENSOR RECIPE ===
ewogICAgIm5hbWUiOiAiT3BlbldlYXRoZXJNYXAiLAogICAgImF1dGhvciI6ICJyaWdwYXBhIiwK
ICAgICJ2ZXJzaW9uIjogMTU3OTA0NjA5NCwKICAgICJkZXNjcmlwdGlvbiI6ICJPcGVuV2VhdGhl
ck1hcCBDdXJyZW50IENvbmRpdGlvbnM7IHJlcXVpcmVzIEFQSSBrZXkgZnJvbSBvcGVud2VhdGhl
cm1hcC5vcmciLAogICAgImNvbmZpZyI6IHsKICAgICAgICAiUmVxdWVzdFVSTCI6ICJodHRwOi8v
YXBpLm9wZW53ZWF0aGVybWFwLm9yZy9kYXRhLzIuNS93ZWF0aGVyP3ppcD15b3VyLVpJUC1jb2Rl
JkFQUElEPXlvdXItYXBwLWlkIiwKICAgICAgICAiSGVhZGVycyI6ICIiLAogICAgICAgICJJbnRl
cnZhbCI6ICI3MjAwIiwKICAgICAgICAiVGltZW91dCI6ICIzMCIsCiAgICAgICAgIlF1ZXJ5QXJt
ZWQiOiAiMSIsCiAgICAgICAgIlJlc3BvbnNlVHlwZSI6ICJqc29uIiwKICAgICAgICAiVHJpZ2dl
ciI6ICJleHByIiwKICAgICAgICAiTnVtRXhwIjogIiIsCiAgICAgICAgIlRyaXBFeHByZXNzaW9u
IjogInJlc3BvbnNlLmNvZCA9PSAyMDAiLAogICAgICAgICJFeHByMSI6ICJsYXN0KHJlc3BvbnNl
LndlYXRoZXIpLm1haW4iLAogICAgICAgICJFeHByMiI6ICJyZXNwb25zZS5uYW1lIiwKICAgICAg
ICAiRXhwcjMiOiAicm91bmQocmVzcG9uc2UubWFpbi50ZW1wICogOSAvIDUgLSA0NTkuOTcsMSki
LAogICAgICAgICJFeHByNCI6ICJyZXNwb25zZS5tYWluLmh1bWlkaXR5IiwKICAgICAgICAiRXhw
cjUiOiAicm91bmQocmVzcG9uc2UubWFpbi5wcmVzc3VyZSAqIDAuMDI5NTI5OTg4LDIpIiwKICAg
ICAgICAiRXhwcjYiOiAiIiwKICAgICAgICAiRXhwcjciOiAiIiwKICAgICAgICAiRXhwcjgiOiAi
IgogICAgfSwKICAgICJzb3VyY2UiOiAiMTkyODgiCn0=
=== END SITESENSOR RECIPE ===
1 Like
#226

@rigpapa, if someone were weighing one plug-in against the other strictly on the basis of their ability to pull in and parse API results, would you have key criteria to add (or suggested edits) to this list? (Example: “Variable timeout?”)

Pulling API Data_ SiteSensor vs Reactor
Pulling API Data_ SiteSensor vs Reactor878×1084 83.8 KB

2 Likes
#227

The key difference in the HTTP Request action of Reactor (3.6) vs using SiteSensor is that Reactor’s use of the HTTP request is really intended to cause action or notify another distant subsystem of some event. Although it can collect data from the HTTP response, it’s not it’s first best use, and as evidence of that, Reactor’s default response length limit is 2K. SiteSensor is built to collect data. Its default response length limit is 64K, and increasing that limit to 256K or higher is possible. SiteSensor’s memory management is built for that, and 1.15 now in development will even improve on that.

SiteSensor does support URL variables, it’s just a limited set (e.g. current date and time, configured lat/lon of the Vera system, etc.).

1 Like
#228

THANKS for the explanation; I’ve updated the above graphic accordingly.
Can SiteSensor also handle URL redirects? (i.e. if a service returns results from a different domain from the one to which the API call was initially made?)

#229

Your expression response.properties.temperature refers to the table. If you want the value from the table, the value is stored in a field called “value”, so you would use response.properties.temperature.value

EDIT: and I’m rushing again… I see you’re using that for the second one… interesting… OK, do this little dance with me:

  1. Go into your SiteSensor configuration, Settings tab, and down at the bottom is “Re-evaluate the expression”… change that to “Every minute”
  2. Go out to the control tab, and toggled the “Armed” switch back and forth to force it to make a query.
  3. Go into the Advanced tab, Variables sub-tab
  4. Find the “LastResponse” variable
  5. Click “Edit” to go into edit mode with its current value.
  6. Copy-paste that response into a reply here.

Also, did you notice that “value” isn’t in the table of the first expression? Maybe NWS didn’t return a value on that query?

EDIT 2 I did a little more digging, and NWS will return “null” values for data it does not have at the time. So be aware that null can be returned for any field. Also, SiteSensor 1.14 (and earlier) has a display issue, so “null” is displayed as ("table"){ ["__type"]="null" } in the diagnostic log.

1 Like
#230

After creating a new SiteSensor device where it worked ok, I now see it is also working in the old one. There were a couple of Luup reloads while creating the new sensor and updating a Panel to reference the new sensor. I assume those reloads fixed whatever had the old sensor acting up. I should have followed the mantra of The IT Crowd… “Have you tried turning it off and on again” :slight_smile:

1 Like
#231

I’m 99.999% certain it’s NWS occasionally not returning data for some fields. So you’re going to see it again. On my current queries, min and max temperatures for the last 24 hours are null in the responses, which is a pretty odd piece of data to claim not to have.

        "maxTemperatureLast24Hours": {
            "value": null,
            "unitCode": "unit:degC",
            "qualityControl": null
        },
        "minTemperatureLast24Hours": {
            "value": null,
            "unitCode": "unit:degC",
            "qualityControl": null
        },
#232

My understanding, from reading the NWS API docs, is that they assign a TTL to each datum; so that even if they once had the highs and lows from some remote source, their system may refuse to dole those out once they go stale.

Just my (limited) understanding, which – as we all know – is subject to flaws!

1 Like
#233

I am experimenting with this… replaced the ZIP code appropriately and AppID I presumed was API. It’s giving me 401s as my outcome.

Update: Totally ignore me - as soon as I turned my back it updated with data, little sneaky thing.

1 Like
#234

So some hours have passed and this turned from “workaround” to “thing.”

Seeing the other posts in this thread as the day wore on sparked what ended up being moving to the dev-stable version of SiteSensor. That allowed me to use the recipe provided in this thread, tweaked to my needs, which replaces well ahead of time use of the Dark Sky API.

The Ambient API from my weather station is having issues (vendor they’re using to support it is IBM) and, since it controls my HVAC, I can’t really have that down.

So… merged my individual UP/DOWN t-stat Reactor devices into two duplicate master devices that control both at the same time. One uses the Ambient API, the other uses the OpenWeatherMap API.

Lastly, created a failover “monitor” Reactor device that watches for the Ambient SiteSensor to fail… and immediately shuts off the Reactor master using Ambient data and flips on the Reactor master using OpenWeatherMap. Of course, once Ambient comes back online, it switches them back.

Thanks @rigpapa for all these wonderful toys lol

1 Like
#235

Do you have a recipe for NWS API, by chance?

#236

Here’s the one I’m using for testing. You’ll need to change the “User-Agent” header so that it contains your email address. You’ll also need to change the station in the URL. The station KFFC is closest to me (Falcon Field, Peachtree City, Georgia), so I left it in so you can see how it works.

=== Ident: Site Sensor version 1586013732 by rigpapa; Change KFFC in the request URL to the station closest to you. Add your email address to the User-Agent header
=== BEGIN SITESENSOR RECIPE ===
ewogICAgIm5hbWUiOiAiU2l0ZSBTZW5zb3IiLAogICAgImF1dGhvciI6ICJyaWdwYXBhIiwKICAg
ICJ2ZXJzaW9uIjogMTU4NjAxMzczMiwKICAgICJkZXNjcmlwdGlvbiI6ICJDaGFuZ2UgS0ZGQyBp
biB0aGUgcmVxdWVzdCBVUkwgdG8gdGhlIHN0YXRpb24gY2xvc2VzdCB0byB5b3UuIEFkZCB5b3Vy
IGVtYWlsIGFkZHJlc3MgdG8gdGhlIFVzZXItQWdlbnQgaGVhZGVyIiwKICAgICJjb25maWciOiB7
CiAgICAgICAgIlJlcXVlc3RVUkwiOiAiaHR0cHM6Ly9hcGkud2VhdGhlci5nb3Yvc3RhdGlvbnMv
S0ZGQy9vYnNlcnZhdGlvbnMvbGF0ZXN0IiwKICAgICAgICAiSGVhZGVycyI6ICJVc2VyLUFnZW50
OiAoVG9nZ2xlZGJpdHMtU2l0ZVNlbnNvciwgcGF0cmlja0B0b2dnbGVkYml0cy5jb20pIiwKICAg
ICAgICAiSW50ZXJ2YWwiOiAiNzIwMCIsCiAgICAgICAgIlRpbWVvdXQiOiAiMzAiLAogICAgICAg
ICJRdWVyeUFybWVkIjogIjEiLAogICAgICAgICJSZXNwb25zZVR5cGUiOiAianNvbiIsCiAgICAg
ICAgIlRyaWdnZXIiOiAiZXhwciIsCiAgICAgICAgIlRyaXBFeHByZXNzaW9uIjogInJlc3BvbnNl
LnByb3BlcnRpZXMgPT0gbnVsbCIsCiAgICAgICAgIkZhaWxNYXN0ZXJPbkV4cHJlc3Npb25FcnJv
ciI6ICIwIiwKICAgICAgICAiRmFpbENoaWxkT25FeHByZXNzaW9uRXJyb3IiOiAiMSIsCiAgICAg
ICAgIkJsYW5rQ2hpbGRPbkV4cHJlc3Npb25FcnJvciI6ICIwIiwKICAgICAgICAiRXhwcjEiOiAi
cmVzcG9uc2UucHJvcGVydGllcy50ZW1wZXJhdHVyZS52YWx1ZSAqIDEuOCArIDMyIiwKICAgICAg
ICAiQ2hpbGQxIjogInVybjpzY2hlbWFzLW1pY2FzYXZlcmRlLWNvbTpkZXZpY2U6VGVtcGVyYXR1
cmVTZW5zb3I6MSIsCiAgICAgICAgIkV4cHIyIjogInJvdW5kKHJlc3BvbnNlLnByb3BlcnRpZXMu
d2luZFNwZWVkLnZhbHVlICogMi4yMzcsMSkiLAogICAgICAgICJDaGlsZDIiOiAidXJuOnNjaGVt
YXMtbWljYXNhdmVyZGUtY29tOmRldmljZTpHZW5lcmljU2Vuc29yOjEiLAogICAgICAgICJFeHBy
MyI6ICJyb3VuZChyZXNwb25zZS5wcm9wZXJ0aWVzLndpbmRHdXN0LnZhbHVlICogMi4yMzcsMSki
LAogICAgICAgICJDaGlsZDMiOiAidXJuOnNjaGVtYXMtbWljYXNhdmVyZGUtY29tOmRldmljZTpH
ZW5lcmljU2Vuc29yOjEiLAogICAgICAgICJFeHByNCI6ICJyZXNwb25zZS5wcm9wZXJ0aWVzLmJh
cm9tZXRyaWNQcmVzc3VyZS52YWx1ZSAvIDEwMCIsCiAgICAgICAgIkNoaWxkNCI6ICJ1cm46c2No
ZW1hcy1taWNhc2F2ZXJkZS1jb206ZGV2aWNlOkdlbmVyaWNTZW5zb3I6MSIsCiAgICAgICAgIkV4
cHI1IjogInJlc3BvbnNlLnByb3BlcnRpZXMubWF4VGVtcGVyYXR1cmVMYXN0MjRIb3Vycy52YWx1
ZSAqIDEuOCArIDMyIiwKICAgICAgICAiQ2hpbGQ1IjogInVybjpzY2hlbWFzLW1pY2FzYXZlcmRl
LWNvbTpkZXZpY2U6VGVtcGVyYXR1cmVTZW5zb3I6MSIsCiAgICAgICAgIkV4cHI2IjogInJlc3Bv
bnNlLnByb3BlcnRpZXMubWluVGVtcGVyYXR1cmVMYXN0MjRIb3Vycy52YWx1ZSAqIDEuOCArIDMy
IiwKICAgICAgICAiQ2hpbGQ2IjogInVybjpzY2hlbWFzLW1pY2FzYXZlcmRlLWNvbTpkZXZpY2U6
VGVtcGVyYXR1cmVTZW5zb3I6MSIsCiAgICAgICAgIkV4cHI3IjogInJlc3BvbnNlLnByb3BlcnRp
ZXMucHJlY2lwaXRhdGlvbkxhc3RIb3VyLnZhbHVlIiwKICAgICAgICAiQ2hpbGQ3IjogInVybjpz
Y2hlbWFzLW1pY2FzYXZlcmRlLWNvbTpkZXZpY2U6R2VuZXJpY1NlbnNvcjoxIgogICAgfSwKICAg
ICJzb3VyY2UiOiAiMjAwOTUiCn0=
=== END SITESENSOR RECIPE ===
1 Like
#237

round(response.properties.windSpeed.value * 2.237,1)

Is this calculation converting knots to mph and then rounding that result?

#238

Yes, that’s correct.

Edit: actually the source units are m/s

1 Like
#239

@gwp1 @LibraSun . Set UseCurl=1 in the Variables section of the sensor. This seems to have fixed the AmbientWeather issue for me.

2 Likes
#240

#WIN!! That did it for mine, too. Nicely done @niharmehta !!

#241

@rigpapa, how might one account for JSON parameters that are not always provided, such as the “Rain” parameter (missing if no rain reported) from OpenWeatherMap?

I’ve tried:

SETTINGS > Expr3 := (response.rain.3h || 0) / 25.4

to no avail. SiteSensor throws a “Query OK, but 1 expressions failed” error instead of defaulting the value to 0 as hoped. Have I mucked up the syntax here?