Are you sure that’s the error it’s complaining about? I use this construct all the time. Does rain exist in the response? You can’t dereference through null, that would be an error anyway.
No, as mentioned, the .rain parameter was not being passed during my testing; I was trying to anticipate it from the Docs on OWM.
How do you normally account for sometimes-missing keys? SS throws up a Lua (nil) error in the log in this case.
I mainly wanted to be sure I was on the right track syntax-wise?
I found SiteSensor yesterday while I was trying to figure out how to get some Swedish weather provider’s data into my Vera. Awesome! If you need any function to your Vera, @rigpapa as probably done it already!
A question, is there a way to name your expressions? Would be super to label them in some way so it becomes easier to know which one does what when using them.
2 Likes
I may give up at this point. I’ve wallowed around in all the SiteSensor and LuaXP documentation that I can find, but even trying this alternative construct…:
if(response.rain.3h,response.rain.3h,0) / 25.4
I appear to be no closer to handling a non-existent JSON parameter gracefully (e.g. returning a zero value when the IF test condition returns null). SiteSensor still gives me a:
10:49:49: SiteSensor: Failed to parse expression `"if(response.rain.3h,response.rain.3h,0) / 25.4"', { location=16, ["__source"]="luaxp", message="Invalid operator", type="compile" }
10:49:49: SiteSensor: Eval #3: "if(response.rain.3h,response.rain.3h,0) / 25.4"=("nil")nil
error in the Log.
You cannot refer to response.rain.3h if response.rain itself does not exist.
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.
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.