Issues with weather data

[natebarnz]

Hi,

I have app 1.4.9, firmware 2.1.6 (1), hardware 2.3-DC.

I can’t get weather data to pull successfully. I can find and set my weather station, KAZTUCSO435, without any issue. My api key is correct and verified. My exported configuration shows the pws is set. Whenever I check my weather diagnostics I can see all accurate information (i.e. yesterdays rainfall) however it never shows a last successful weather call date, see attached. I’ve tried resetting options and stations but it still never works. I have my unit behind a basic firewall and my DHCP is set and working properly for all my other devices. Another detail to note is that I’m logged in to opensprinkler to store my configuration between devices.

In addition (possibly unrelated) I have never been able to get my time to set correctly. I’ve tried NTP off and with the underground data set but still to no avail. I’m in mountain standard time.

Here is my exported configuration:

{“settings”:{“devt”:1450198229,”nbrd”:1,”en”:1,”rd”:1,”rs”:0,”rdst”:1450353258,”loc”:”pws:KAZTUCSO435″,”wtkey”:”59b89138184f425d”,”sunrise”:404,”sunset”:1048,”eip”:3519216018,”lwc”:1450196156,”lswc”:0,”lrun”:[0,0,0,0],”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],”wto”:{“h”:90,”t”:90,”r”:90}},”programs”:{“nprogs”:1,”nboards”:1,”mnp”:28,”mnst”:4,”pnsize”:20,”pd”:[[11,127,0,[16444,0,0,0],[600,1500,0,0,900,0,0,0],”Main”]]},”options”:{“fwv”:216,”tz”:32,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:204,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:23,”ext”:0,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:0,”rso”:1,”wl”:100,”den”:1,”ipas”:0,”con”:110,”lit”:100,”dim”:15,”bst”:0,”uwt”:0,”ntp1″:50,”ntp2″:97,”ntp3″:210,”ntp4″:169,”lg”:1,”mas2″:0,”mton2″:0,”mtof2″:0,”fwm”:1,”fpr0″:100,”fpr1″:0,”re”:0,”reset”:0,”dexp”:0,”mexp”:6,”hwt”:220},”status”:[0,0,0,0,0,0,0,0],”stations”:{“masop”:[255],”ignore_rain”:[0],”masop2″:[0],”stn_dis”:[0],”stn_seq”:[255],”stn_spe”:[0],”snames”:[“S01″,”S02″,”S03″,”S04″,”S05″,”S06″,”S07″,”S08″],”maxlen”:24}}

Thanks
-nate-

Attachments:

1. 

   Screen-Shot-2015-12-15-at-1.48.07-PM.png
   

[dun4cheap]

Nate,

I was having this problem as well with 3 different units. One hw 2.1, two with 2.2, running different firmwares, 2.14 and 2.16. After pulling my hair out and scanning the json settings in each, I decided to reconfigure one completely and then the weather started pulling again. So I saved the settings and imported the file in to the other two controllers and they started working. So I reverted back to the previous settings and it stopped. Long story made short, here is what was the problem, it was the gps point pulled using the location finder for the weather. I know you said you setup the weather properly and I am sure you did. But try to relocate the location on the map and pull an updated GPS location and save and test it.

The new 2.16 in the change write up which I read after resolving my weather update problem, there is now a way to set a specific location up. I have not done this yet, after updating my gps location and saving my settings I have not had this problem. So see if this resolves it for you.

Please follow up in your thread to confirm if it resolved you issue or not. Hopefully Ray or Samers can add a note when testing the weather diagnostics, if it fails that they can add it the notes to re-aquire the gps for your location or refer to setting the location.

[natebarnz]

Hi dun4cheap,

Thanks for your reply. I had previously read your posts as I was researching the issue. I feel as if I have tried so many different things, resetting to factory defaults and trying to simply just get the weather data to pull. Unfortunately nothing has worked. I’ve tried setting my location with the map by locating my weather station and also by just selecting a random nearby non pws point, still nothing. It gets my location name correct but the timezone is wrong and the weather data never get as last successful call date. I did find a way to get my timezone correct, I had to wipe my location so it was empty and then the UI let me manually adjust my timezone. So I set my timezone correctly and then saved my changes. Now it keeps my time zone correct but I still can’t seem to get the weather data to pull successfully.

So to try what I believe you are suggesting I have remove my location altogether. I verify that it is empty in the JSON config and then set my location again. I then verify that my location is set to the desired weather station, “loc”:”pws:KAZTUCSO435″. However it still does not work. I have also tried rebooting between these changes as sometimes the location in the UI does not show that it changed. I then try to set my location to a non pws, just lat/long coords “loc”:”32.26273,-110.73243″. I get the same results, I can see weather data for my location on the main UI page and when I run the weather diagnostics I get accurate information for my location, however still not last successful call.

Although I don’t know if any technical logging occurs for wunderground api calls, I do believe it is working. My key is correct and when its entered I see all the weather stations on the map, which doesn’t happen if I don’t have a key installed. I also see accurate data in the diagnostics and the main screen, all implying to my assuming eyes that the api is working and returning data. Why the system does not record a last successful call is still beyond me.

Let me know if you think I didn’t try what you suggested correctly.

Thanks
-nate-

[dun4cheap]

Nate,

Reading your last post, my problem, was that I could not even pull data. However, it appeared that I was pulling data from wunderground or it appeared I was looking at the wunderground site. Interesting that it is not recording the last pull date.

[natebarnz]

dun4cheap,

I appreciate your assistance. I hope I don’t have a faulty unit. I’m a software developer and IT professional so I like to think I am a bit more capable than your average joe when it comes to setting up a mostly “plug and play” device. I’ve tried just about everything I could think of. I have even tried doing it all from the API but still to no avail.

If I begin with a freshly reset unit and simply add my wunderground api key and weather station pws key through the http UI, iphone app, or chrome extension, I would hope that it would work. I think I’ve ruled out any local network issues since it is requesting and displaying accurate live information from the wunderground API, and it can also connect and sync with the opensprinkler.com shared storage. Maybe I have faulty hardware or software. I guess the last thing I could try would be to reinstall the firmware, although mine came factory with the latest version since I just bought it a couple of months ago.

Hopefully Ray can chime in here and get this resolved for me.

[dun4cheap]

Nate,

You may want to look up the api call in the sdk and do a manual call to check the last weather call to see if its just a problem with the webgui. I doubt its a controller issue, its more likely a software problem.

[DaveC]

It sounds like you’ve tried the basic case where your OS is set to (“loc”:”yourcity,Arizona”) and the timezone is correct (“tz”:20) BUT the server (weather) calls are still not successful (“lswc”:0). The server call is to an OS cloud server. The following thread contains some info about the server call and what it is used for.
https://opensprinkler.com/forums/topic/os-regular-connection-to-the-cloud/
I think it would good to find out what is going on with the server calls. Are they getting out? Is there a failure of some kind? I think you can do it with Wireshark, looking for traffic from your OS IP to your gateway. I’ve done it via the logging capability of my router. In either case, the calls should be easy to spot as they occur once an hour.

[Ray]

@nate: The fact that you can get correct time zone rules out hardware issue. From the json output, it looks like you have not selected to use weather algorithm (uwt:0). To enable weather data, you need to select to use either the Zimmerman algorithm, or auto rain delay algorithm. You can set this by going to Edit Options -> Weather and Sensors -> Weather Adjustment Method.

[natebarnz]

Hi Ray,

Thank you for the reply. I have tried that but still am not making any progress with my issue. My current settings are below. My last weather call seems to updated as it should and the data it returns is accurate every time I check. I do however still not get a last successful weather call as you can see in the attached image. Any other ideas?

{“settings”:{“devt”:1451313356,”nbrd”:1,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”pws:KAZTUCSO435″,”wtkey”:”59b89138184f425d”,”sunrise”:360,”sunset”:1080,”eip”:0,”lwc”:1451311209,”lswc”:0,”lrun”:[4,1,1500,1451296801],”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],”wto”:{“h”:90,”t”:90,”r”:90}},”programs”:{“nprogs”:1,”nboards”:1,”mnp”:28,”mnst”:4,”pnsize”:20,”pd”:[[11,127,0,[16564,0,0,0],[600,1500,0,0,1500,0,0,0],”Main”]]},”options”:{“fwv”:216,”tz”:20,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:204,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:23,”ext”:0,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:0,”rso”:0,”wl”:100,”den”:1,”ipas”:0,”con”:150,”lit”:100,”dim”:15,”bst”:320,”uwt”:1,”ntp1″:50,”ntp2″:97,”ntp3″:210,”ntp4″:169,”lg”:1,”mas2″:0,”mton2″:0,”mtof2″:0,”fwm”:1,”fpr0″:100,”fpr1″:0,”re”:0,”reset”:0,”dexp”:0,”mexp”:6,”hwt”:220},”status”:[0,0,0,0,0,0,0,0],”stations”:{“masop”:[255],”ignore_rain”:[0],”masop2″:[0],”stn_dis”:[236],”stn_seq”:[255],”stn_spe”:[0],”snames”:[“Lawn”,”Shrubs”,”S03″,”S04″,”Trees”,”S06″,”S07″,”S08″],”maxlen”:24}}

Thanks
-nate-

Attachments:

1. 

   Screen-Shot-2015-12-28-at-2.39.25-PM.png
   

[DaveC]

nate:
The last server call (lwc) is the time that the call is made by OS. However, if lswc = 0 then it didn’t get through. So your statement: “My last weather call seems to updated as it should and the data it returns is accurate every time I check.” is not really what is happening. The call is being made but it is unsuccessful and therefore doesn’t return anything. Also, the server calls should be successful regardless of the water algorithm settings. I run my OS with the manual weather setting and no auto rain delay and my server calls are successful every hour, except when there is a program running. In that case the call is not made.

It is possible that the problem is not with OS itself but with your network/firewall. It would be worth checking to see if that call is getting out and returning successfully. Wireshark is a useful tool for these checks. You could also try making the server access from a PC on your network to see what happens.

[natebarnz]

Thanks for the response DaveC. I tried to use WireShark but couldn’t seem to find the api call. I’m capturing on the LAN for the OS internal ip address and see lots of UI related calls but nothing else. I’m sure i’m doing something wrong with it.

Although my firewall is the most basic I did disable it to see if it would work and it did not. I also tried making API calls from a PC on my local network and was able to see the response just fine. My firewall allows all responses from connections created from the internal network and I have no issues with any other internal calls that I’m aware of.

I’m not sure of the exact call that OS uses to query wunderground however I did try a few random ones with my api key and they were all successful. Does anyone know if the API call requires a callback? If so then even a basic firewall would certainly block the call back. I don’t see why a callback would be necessary since it appears you can get all the data you need from simple HTTP api requests that return formatted data in the response.

I’m really at a loss here. I’m starting to wish I installed the pi extension so I would have more access to see whats going on.

Any other suggestions would be great. Maybe an example of the internal API call would be useful here too, I can’t seem to find it anywhere.

Thanks
-nate-

[DaveC]

No, you aren’t doing anything wrong. This particular case is difficult to see in wireshark unless you have a way to see the OS server call on the system that is running wireshark. That requires a way to mirror the request to the PC. Sorry for making this sound easier that it really is.

The server call is not specifically a wunderground call. It is a call to an OS cloud server. You can see the call in the OpenSprinkler code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/weather.cpp
The host name is weather.opensprinkler.com. If you do a lookup on this host it returns the following IP addresses:
52.10.151.144 and 54.148.153.152. I just checked to see what my OS used on its server call and it was the 52… address. I use my router’s filtering and logging capability to see what OS is doing externally, but I can’t see the actual GET request that it emits this way.

The return from the server call contains both weather info (scale and rd), if enabled, and non-weather info (sunrise/set, external IP, …). It occurs every hour but will not be made if:
the network check has failed OR a program is currently running OR the controller is in remote extension mode

I appears from the code (Ray can confirm) that the value of lwc is the time that the next weather call is scheduled but it is not an indicator that the call was actually made. The only indicator that the call was made is if it is successful (lswc = epoch time). You can’t tell if it was made and failed.

I would think that you could make the same server call from a browser if you knew what the request looked like. The code for it is the module referenced above. My C++ is not good enough to piece a request together from the code accurately enough to make one that works. This is what I was suggesting wireshark for, but…
perhaps Ray would provide an example request that you could use to test the server call.

Just curious, did you try a simple config that did not use any weather info (key, pws, etc) and where you set your location to yourcity, Arizona (not lat, long) such that the /jc API call returns “loc”:”yourcity, Arizona. This is how my config is set up. Here’s an example of my /jc call (with my eip removed).
http://192.168.1.80/jc?/pw=944c6d5d72868e442a3dda88297ac500
{“devt”:1451485502,”nbrd”:3,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”Ault, Colorado”,”wtkey”:””,”sunrise”:443,”sunset”:1001,”eip”:**********,”lwc”:1451483951,”lswc”:1451483951,”lrun”:[8,6,1540,1451467541],”sbits”:[0,0,0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],”wto”:{}}

I’m looking to see if there is some setting combination that causes the server call to fail.

Dave

[DaveC]

I tried an experiment on my system. My “loc” is in the form “City, State” (See previous post). I set my the location from the Web UI using the map. It showed City,State in the box, but it changed “loc” in my config from “City, State” to “lat, long”. After that change server calls failed (about 8 hours worth of them). I just restored my config to the original and server calls are now successful again.

Ray, what does the server call request look like? Knowing this would be an aid in debugging the problem.

[natebarnz]

Hi DaveC,

Thanks again for all your help. I had no issue looking up the host from an internal server however my traceroute seems a little odd, it stops before it got to the final ip (see routes below). I also tried setting my location to “Tucson, Arizona” and “Tucson, AZ” but was not able to get either to set properly. After I imported the updated settings file it ended up setting “loc” to “undefined” on both attempts (example settings file below).

I’m also still a bit confused because when I have the location set to lat/long or a weather station it does show correct data in the “weather diagnostics” screen (see attached image). This makes me assume that it is making some sort of successful call to the wunderground API in which it returns the data that it prints on the screen. I’m assuming its making the call ok but just not saving or setting it on the system. Unless OS is waiting for some sort of call back that gets blocked by the firewall, however I would guess that it would be documented if this were the functionality since most people likely have their OS behind a firewall.

I noticed my eip is always set to 0, could this be a problem?

If I could simulate the real call from a local server to see what happens that certainly would be great. Ray can you help with that?

Thanks!

weather.opensprinkler.com is an alias for os-weather.elasticbeanstalk.com.
os-weather.elasticbeanstalk.com has address 54.148.153.152
os-weather.elasticbeanstalk.com has address 52.10.151.144

traceroute to 54.148.153.152 (54.148.153.152), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.538 ms 0.398 ms 0.461 ms
2 209.194.249.145 (209.194.249.145) 8.532 ms 8.472 ms 8.411 ms
3 207.114.135.73 (207.114.135.73) 32.772 ms 32.706 ms 32.647 ms
4 209.136.143.5 (209.136.143.5) 32.582 ms 32.532 ms 32.471 ms
5 173.227.35.254 (173.227.35.254) 32.413 ms 32.282 ms 32.208 ms
6 206.169.93.73 (206.169.93.73) 32.143 ms 24.749 ms 24.667 ms
7 216.64.187.197 (216.64.187.197) 24.603 ms 16.536 ms 16.330 ms
8 64.129.234.198 (64.129.234.198) 45.963 ms sjc1-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.249.26) 45.839 ms sjc1-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.249.22) 45.705 ms
9 equinix01-sfo5.amazon.com (206.223.116.177) 45.596 ms 45.475 ms 45.350 ms
10 205.251.229.171 (205.251.229.171) 64.314 ms 205.251.229.175 (205.251.229.175) 57.480 ms 205.251.229.177 (205.251.229.177) 64.068 ms
11 54.240.242.39 (54.240.242.39) 57.219 ms 54.239.41.228 (54.239.41.228) 57.101 ms 205.251.229.189 (205.251.229.189) 60.128 ms
12 205.251.232.141 (205.251.232.141) 64.165 ms 205.251.232.153 (205.251.232.153) 64.066 ms 205.251.232.108 (205.251.232.108) 71.479 ms
13 54.239.48.181 (54.239.48.181) 71.356 ms 205.251.232.165 (205.251.232.165) 71.266 ms 205.251.232.63 (205.251.232.63) 71.175 ms
14 * * *

traceroute to 52.10.151.144 (52.10.151.144), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.393 ms 0.352 ms 0.368 ms
2 209.194.249.145 (209.194.249.145) 18.554 ms 18.617 ms 18.557 ms
3 207.114.135.73 (207.114.135.73) 26.711 ms 26.649 ms 26.592 ms
4 209.136.143.5 (209.136.143.5) 26.529 ms 26.468 ms 26.420 ms
5 173.227.35.254 (173.227.35.254) 26.365 ms 26.308 ms 26.248 ms
6 206.169.93.73 (206.169.93.73) 28.068 ms 10.928 ms 10.743 ms
7 216.64.187.197 (216.64.187.197) 10.616 ms 22.485 ms 22.332 ms
8 64.129.234.198 (64.129.234.198) 46.543 ms 46.454 ms sjc1-pr1-xe-0-3-0-0.us.twtelecom.net (66.192.249.22) 46.369 ms
9 equinix01-sfo5.amazon.com (206.223.116.177) 46.290 ms 46.207 ms 46.125 ms
10 54.240.242.12 (54.240.242.12) 76.126 ms 205.251.229.175 (205.251.229.175) 64.822 ms 205.251.229.171 (205.251.229.171) 64.646 ms
11 54.240.242.21 (54.240.242.21) 64.560 ms 205.251.232.108 (205.251.232.108) 64.570 ms 54.239.42.6 (54.239.42.6) 63.773 ms
12 54.239.41.228 (54.239.41.228) 63.637 ms 205.251.232.161 (205.251.232.161) 63.551 ms 205.251.232.155 (205.251.232.155) 70.541 ms
13 205.251.232.155 (205.251.232.155) 70.378 ms 54.239.48.179 (54.239.48.179) 70.284 ms 205.251.232.167 (205.251.232.167) 70.199 ms
14 * * *

{“settings”:{“devt”:1451985655,”nbrd”:1,”en”:1,”rd”:1,”rs”:0,”rdst”:1452259421,”loc”:”undefined”,”wtkey”:”59b89138184f425d”,”sunrise”:360,”sunset”:1080,”eip”:0,”lwc”:1451985159,”lswc”:0,”lrun”:[0,0,0,0],”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],”wto”:{“h”:90,”t”:90,”r”:90}},”programs”:{“nprogs”:1,”nboards”:1,”mnp”:28,”mnst”:4,”pnsize”:20,”pd”:[[11,127,0,[16564,0,0,0],[600,1500,0,0,1500,0,0,0],”Main”]]},”options”:{“fwv”:216,”tz”:20,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:204,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:23,”ext”:0,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:0,”rso”:0,”wl”:100,”den”:1,”ipas”:0,”con”:150,”lit”:100,”dim”:15,”bst”:320,”uwt”:1,”ntp1″:50,”ntp2″:97,”ntp3″:210,”ntp4″:169,”lg”:1,”mas2″:0,”mton2″:0,”mtof2″:0,”fwm”:1,”fpr0″:100,”fpr1″:0,”re”:0,”reset”:0,”dexp”:0,”mexp”:6,”hwt”:220},”status”:[0,0,0,0,0,0,0,0],”stations”:{“masop”:[255],”ignore_rain”:[0],”masop2″:[0],”stn_dis”:[236],”stn_seq”:[255],”stn_spe”:[0],”snames”:[“Lawn”,”Shrubs”,”S03″,”S04″,”Trees”,”S06″,”S07″,”S08″],”maxlen”:24}}

Attachments:

1. 

   Screen-Shot-2016-01-05-at-9.24.34-AM.png
   

[DaveC]

I don’t understand the relationship between the ‘weather’/server call and the updating of temp/humidity etc., but temp and humidity are not part the data returned from this call. Interestingly, location is a parameter in the call. This provides a linkage, at least in my experiment, between changing the location and server call failures.

Re: I noticed my eip is always set to 0, could this be a problem?
No, I think it is a consequence of the server call failure. The eip is not needed to make the call, rather it is one of the items returned.

Looking at the code, the ‘weather’/server call returns: sunrise, sunset, external ip, water %, time zone, rain delay. Of these only eip has no other data source. I.e. all the others will have values if the call fails. Additionally the lswc is always filled in at the end of the code that processes the return. Since lwsc and eip are both 0 in your data, I would conclude that the server call has not been successful since the last time the system booted.

I’m getting more familiar with this code, so maybe I’ll piece together a working server call soon.

[Ray]

@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:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L674

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:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/weather.cpp#L112

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:
http://weather.opensprinkler.com/weather0.py?loc=01002

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:
http://weather.opensprinkler.com/weather1.py?loc=01002&key=xxxx
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.

[DaveC]

Based on the failures I reported last week using my config and loc…

I changed the location in my OS using the Web GUI map. Loc changed from “Ault, Colorado” to “40.57517,-104.83635”
Since doing that the last 2 server calls by OS have failed.

I manually issued 3 server requests with these results:
http://weather.opensprinkler.com/weather0.py?loc=Ault%20Colorado
&scale=-1&rd=-1&tz=20&sunrise=443&sunset=1012&eip=*********

http://weather.opensprinkler.com/weather0.py?loc=80610
&scale=-1&rd=-1&tz=20&sunrise=443&sunset=1012&eip=*********

http://weather.opensprinkler.com/weather0.py?loc=40.57517,-104.83635
Error: No weather data found.

I think there is an issue on the server end when Lat,Long is sent as the loc.
The Lat,Long I used is what the Web GUI produced. I may also be possible that it is delivering Lat,Long in a format that the server does not like.

Dave

[natebarnz]

Lots of great information. Thanks Ray and DaveC.

I ran a series of tests from my rpi server (see results below) on the same switch connected to the same router via DHCP, just as my OS device is. I have tried zip,lat/long,city/state,pws as loc settings in the past and nothing has ever returned a successful call for me. Also just to confirm all my DHCP devices have no connectivity issues and I have quite a few scripts running from cron sending and receiving data from my internal servers.

curl “http://weather.opensprinkler.com/weather0.py?loc=85749”
&scale=-1&rd=-1&tz=20&sunrise=446&sunset=1058&eip=*********

This one using zip and my wunderground api key with weather1
curl “http://weather.opensprinkler.com/weather1.py?loc=85749&key=*********”
&scale=0&rd=-1&tz=20&sunrise=444&sunset=1057&eip=*********

And using my weather station
curl “weather.opensprinkler.com/weather1.py?loc=pws:KAZTUCSO435&key=*********”
&scale=0&rd=-1&tz=20&sunrise=444&sunset=1057&eip=*********

And just for good measure I did a weather2 call
curl “weather.opensprinkler.com/weather2.py?loc=pws:KAZTUCSO435&key=*********”
&scale=-1&rd=-1&tz=20&sunrise=444&sunset=1057&eip=*********

From what I can tell the data being returned seems accurate and in the correct format.

@Ray: Is there a way to initiate the firmware weather call and see its results? Is there another way to test that the firmware can reach the outside world properly to prove that it is or isn’t a connectivity or network settings issue? When I test my wunderground API key from the UI does it run it through the firmware or does it just test from the UI? My OS is on DHCP which all my other devices use successfully.

Any further help to try and isolate the issue would be great.

Thanks
-nate-

[Ray]

@DaveC: the issue with “Error: No weather data found.” when using GPS coords has happened in the past, mainly due to the free weather services we are using sometimes become unavailable or changed their API. You are right that the UI will convert the location into a GPS coord, and hence this can become a common problem. The work-around is to apply for a free Wunderground API key, and provide the key under ‘Edit Options’ -> ‘Weather and Sensors’. This way, the script will use Wunderground API to resolve GPS coord and it has been working fairly reliably. For example:
http://weather.opensprinkler.com/weather0.py?loc=40.57517,-104.83635&key=db3bc9dfc8d1bfc2
There is no need to change Weather Algorithm if you don’t want to use weather-based adjustment. The point is that as long as the Wunderground API key is defined, the firmware will send the API along with the query, which directs the script to use Wunderground API.

@natebarnz: I am trying to re-collect my thoughts based on your descriptions. The one really weird thing is your controller gets the correct time zone (tz=20), which means it must have received the weather call correctly at least once. This is because the time zone is part of the result of the weather call, so it can’t possibly change the time zone (the original value upon factory reset is 28) without getting a successful weather call.

The weather call is triggered every time the controller is restarted, or every time you change your location, API key, or weather algorithm. Try to change your location, and the firmware will send out a weather call to obtain the new time zone. If you notice the device time has changed, the ‘Last Successful Weather Call’ should be a valid time stamp. If not, something is strangely wrong and I can’t explain.

[natebarnz]

@Ray: Thanks for your response. I actually could never get my time zone to set correctly until I manually set it before selecting a location. After I selected my location and added my api key the ability to manually change the time zone was lost. So to be clear I never was able to get the time zone from setting my location. I’ve tried resetting to factory defaults more than once along with the most minimal configuration possible to try and get the weather calls to be successful. Is there a chance my unit is defective in some way? I doesn’t seem likely to me however I’m at a complete loss at this point.

[Ray]

If you can access the controller then it means the Ethernet controller is working fine and I doubt there is any hardware defect. All OpenSprinkler units have been tested, and the initial RTC time was obtained through NTP, so that we can verify the Ethernet controller is working and can successfully retrieve data from NTP server. I still suspect this has to do with your particular network setup.

If you want to send back and let us take a look to see if there is any hardware problem, feel free to send a support ticket and we will continue there.

[Author]

Posts