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.)
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?
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…
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?
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.
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):
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.
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
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…
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.