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