Some interesting observations, at least from my perspective:
Early today I tried some more server call tests from my loc. The first few with lat,long failed, but then they started working and have not failed since. The unreliability of these calls is a problem. They are referred to as weather calls, but they are needed to adj for dst, sunrise/sunset, etc. Even a system that does not use weather adjustments can be impacted by these failures. E.g. The values for sunrise and sunset in you system are the default (“sunrise”:360,”sunset”:1080) while the values I get for your location are (“sunrise”:365,”sunset”:1221). If you were doing anything based on sunrise/sunset it would be incorrect (your time problem aside). Also, if the system is not adj for dst, scheduling could be an hour off.
Ray, given the importance of this regular server call, it seems like lswc should always be visible in the UI, not just when there is a weather key. Also something should be put in the log when OS reboots because there hasn’t been a successful server call for 24hrs. This failure is too silent.
I set my OS to your location (lat,long) to see if I could reproduce the issue. So far, no. My server calls, with your location, are working. The time zone info is right: “tz”:92 translates to gmt+11, which means gmt+10 + DST. Please verify that I’m looking at this correctly. Also the local time on my OS matches what the world time map shows for your area.
The time offset (in secs) from correct time to bad is relatively consistent for the 2 data points you shared: 49161652 and 49161676. There going to be some variation just based on how much time elapses when you take the samples, but these 2 numbers differ by only 24s. I wonder if Ray finds this particular number interesting.
Your server call experiment showed that the use of “loc”:City, Country worked. Yet when set that way in the config, the server calls still failed (It has always worked for me). The server request that I used is not exactly what OS emits. Based on the code, your config server call might be more like:
http://weather.opensprinkler.com/weather0.py?loc=-35.28200,149.12868&key=%5Byour-key-here%5D&fmv=215
or
http://weather.opensprinkler.com/weather0.py?loc=Canberra,Australia&key=%5Byour-key-here%5D&fmv=215
I’ve tried these and they work. You may want to give them a try, too.
A suggestion: I saw nothing in the 2.1.6 FW rel notes that relates to the problem you are seeing, but it might be helpful if you could update to this FW. One of the inputs to the server call is the FW version number so there is likely some difference in the handling on the server end between the 2 versions. If there is a bug in the FW would be good to know if its in the current FW and debug it there.