New Plugin: SiteSensor

I guess I’m asking how you would handle this situation?? Obviously, what I’ve tried is not succeeding. I even tried:

if(response.rain,response.rain.3h,0) / 25.4

with no better luck. (On a dry day like today, it’s expected that OWM will not pass a .rain or .rain.1h or .rain.3h parameter, so I’m trying to account for those days without breaking my entire SiteSensor setup.)

Try if( response.rain, if( response.rain.3h, response.rain.3h, 0 ), 0 )

1 Like

I get the same compile-time error:

11:16:28: SiteSensor: Failed to parse expression `"if( response.rain, if( response.rain.3h, response.rain.3h, 0 ), 0 )"', { location=16, ["__source"]="luaxp", message="Invalid operator", type="compile" }
11:16:28: SiteSensor: Eval #3: "if( response.rain, if( response.rain.3h, response.rain.3h, 0 ), 0 )"=("nil")nil

FYI, this is all based on what the OpenWeatherMap API call:

http://api.openweathermap.org/data/2.5/weather?zip=70125&id=4335045&appid=b01935ffc5d37952bxxx

normally returns, and my other two ExprN assignments work flawlessly from it. That’s what’s got me thinking it’s a “me” (Vera? SS? LuaXP?) problem and not an “OWM” problem.

Oh good lawd… I didn’t even notice before… 3h… that’s not a valid identifier. You have to use the “quoted-identifier” style to access this value: response.rain['3h'].

Hmmm… and the position of the error reported by luaxp for the subexpression is wrong. That’s doesn’t help at all, does it?

2 Likes

Ooh, glad I asked, then. This would have had me scratching my head forever (or re-reading the docs a 10th time, lol).

THANKS for the insight!

  • Libra ‘Bleeding Edge Case’ Sun

Should not be the case, because I use the same bl***y weather service myself. Amazing what details you forget when you don’t look at things for a… while…

1 Like

PRO TIP: I just appended &units=imperial to my OWM call, so that I have much less unit conversion on my end. (I prefer degrees F and inches.)

All working like a champ now, thanks to you.

1 Like

Hi, one of my sitesensor devices has suddenly started failing with the error: “Last query failed, JSON error unterminated string at line 2768”.

I’ve checked the returned json with an online viewer and it appears valid, is there a length restriction that might have changed with recent versions or might now be getting hit by changes to the returned data from the site?

Thanks for any help.

If you turn on request logging in the control panel, it will tell you the actual size of the response. As long as it’s not outlandishly huge, you can set MaxResponseSize to accommodate.

Thanks @rigpapa, logging showed the returned data was 131682 bytes so I’ve set the max to 150000 and it now works. Not sure what changed as the site data appears the same as always and truncating at 65553 as it was would always have been a problem I would have thought, but main thing is it’s working now!

All previous versions had no limit on response size, so it was a trivial matter for a site to return a response that could consume enough system memory to bring it down. That’s now more aggressively filtered.

Cool, makes sense. Thanks again.

@rigpapa,

After setting up a Site Sensor to pull from the NWS API I quickly found that they seemed to have some issues with the data not updating, or rather, with some of the data elements disappearing for a while. I suppose it is due to the station temporarily not reporting that data, but in any case it quickly became apparent that I wouldn’t get reliable data from that API from the station nearest my home.

So I downloaded the OpenWeatherMap recipe which was a great time saver in getting a new Site Sensor set up using OpenWeather. I changed out a few of the data elements but started to get errors from the Site Sensor device when trying to ‘round’ data elements that went to a nil value.

I am using the round function with temperature (converted to Fahrenheit) and wind/gust speed (converted to mph). When the response is nil, which it is for wind gusts right now, the sensor throws an error on trying to round a nil value. I checked the API and there is no “gust” element in the API response at the moment as winds are calm, but I’ve also seen an element present but with no value resulting in a nil.

I found I could avoid the error by having the expression go to zero when there is a nil value.

This is the syntax you have in the recipe (copied from your web site):

  • Expression 3: round(response.main.temp * 9 / 5 - 459.97,1)

I found that this syntax deals with the nil responses, returning zero rather than an error:

round((response.main.temp or 0) * 9 / 5 - 459.97,1)

I’d suggest using the ‘response or 0’ anywhere the round function is used to avoid the error on nil values.

That’s a relatively new feature of the expression parser that SiteSensor uses, but yes, I agree it should be incorporated into the recipes. I’m thinking of starting a Github repo to keep all the recipes, so it’s clear which version is the most recent, and others can participate/contribute/update.

Edit: for the record, I am not going to allow myself to become the de-facto keeper and maintainer of all recipes from all places (I don’t mind hosting the repo, but others need to be involved in maintaining it). Unless there’s community participation on this, I’ll let it die, and by “it”, I mean to include the existence of the feature in SiteSensor in its entirety.

2 Likes

TIP: Appending &units=imperial to your OWM call may eliminate the need to convert temperatures from Kelvin to Fahrenheit, or millimeters to inches.

Thanks @LibraSun - that’s much easier!

1 Like

Hello Rigpapa,
As usual, excellent work.
Just one noob question.
I’m using this plugin for civil twilight.
If I’m ok with location, I don’t know how to feed the date and tzoffset. See below if I’m not clear

https://api.sunrise-sunset.org/json?lat=65;765987&lng=6.89574&date=**[isodate]**T12:00:00**[tzoffset]**&formatted=0

The plugin will supply those. They are special keywords the plugin understands (you could have left the latitute and longitude ones in place as well). As long as your Vera timezone and location settings are correct, you should be good to go…

Perfectly clear !
But 1 and 2 values never show true or false statut ?

For some reason (which I don’t quite understand and the SiteSensor docs don’t appear to address?), my SiteSensor keeps switching itself to “Unarmed”.

It’s not something I often check, but every time I do think to look at SiteSensor – all it does is pull in weather info from OpenWeatherMap – it shows itself not to be Armed, and so I switch it back to Armed status. Weird!

I can confirm that the recipe I’m using is basic and not failing in any way. Should I be watching for another condition that might cause this issue?

EDIT: Oops, let me check House Mode. Not used to dealing with sensors, and recall that Vera defaults to un-Armed except for ‘Away’, so I may have to assert the ‘Armed’ setting manually.

UPDATE: Yep, that was the cause. Plus, I remembered that SiteSensor lets me uncheck “Only ping when armed” under Settings, which also solves the problem.