@DaveC and natebarnz: variable ‘lwc’ is the time stamp of the last weather call. It gets set right before the firmware queries the weather server:
Then variable ‘lswc’ is the time stamp of the last *successful* weather call, which gets set after the controller receives data correctly from the query:
So normally lswc is within a couple of seconds after lwc (since a query may take a couple of second to return result). As Dave said, ‘lwc’ gets updated regardless of whether the query went through or not, and ‘lswc’ is really what you should be looking for to check if the result has been successfully received.
The query is typically in this format:
where weather0.py is used if the weather adjustment method is ‘Manual’ (i.e. not using weather service). and ‘loc’ can be any of zip code, city+state name, city+country name, GPS coords etc. When you set a location, OpenSprinkler app actually stores the GPS coords since it would be more accurate for finding a nearby weather station later (when you use a weather-based algorithm). With weather0.py you really only get time zone values and sunrise/sunset values. The other values are irrelevant and ignored.
If weather adjustment method is 1 (Zimmerman method), the query is in this format:
where key is the Wunderground API key. With a valid API key, the ‘scale’ variable in the returned result is the calculated watering percentage.
If weather adjustment method is 2 (auto rain delay), the query changes to use weather2.py, and the ‘rd’ variable in the returned result is the calculated rain delay time.
You can click on the above links directly to see the query result. The weather statistics you see in the UI (which includes humidity and so on) is done separately/asynchornously by the UI (it makes its own call to Wunderground API to get these values). These are the values used to calculate watering percentage. Although they are not directly returned by the weather script, it’s understood that the UI shows the ‘raw weather data’ used for calculation, hence it provides a reference point for validation. However, the issue is that the statistics shows these values at the time the UI query the weather service, and it may be different from when the firmware makes the call. Ideally the weather script should return the ‘raw weather data’ and the firmware caches these, then passes them on to the UI. But it hasn’t been done so far.
‘eip’ is the external IP (four fields combined into a long integer). It being 0 is just another indication that the weather query didn’t come back correctly.
I forgot if I’ve already asked this: if you’ve set OpenSprinkler in static IP, it’s very important you also set the correct gateway (router) IP on OpenSprinkler. Without the correct gateway IP, it won’t receive incoming data correctly.