- This topic has 10 replies, 3 voices, and was last updated 5 years, 6 months ago by
.
-
Posts
-
App Version: 1.8.5; Firmware: 2.1.7; Hardware Version 2.3 – AC
My opensprinkler always says “Water Level: 100%” and never adjusts based on temp/rain/humidity. Weather adjustment method is set to Zimmerman, but it never adjusts.
I must be doing something wrong right?
The first thing to check is at the homepage, swipe left to right (or click the upper-left corner icon) to open the left-side menu, then ‘System Diagnostics’. Look at two time stamps: the Last Weather Call and Last Successful Weather Call. If the Last Successful Weather Call time stamp lags behind the first one, or is simply not available, that means the controller never received the weather call result, which explains why the water level has never changed.
There are several possible reasons why it might not be receiving the result back: maybe you set a firewall on your router to block incoming packets to OpenSprinkler; maybe you set the controller in static IP mode but set the incorrect gateway IP.
If the Last Successful Weather Call is up to date, then the only thing I can think of would be the Location setting is incorrect which causes the weather script to ignore the location and return 100% all the time.
Diag shows no succesful call, however it is showing temp/precip and is updating every hour just fine.
Packet capture shows a succeful get from weather.opensprinkler.com every hour (I have obfuscated my location in dump below to XX.XXXXX):
08:09:32.679263 IP 10.10.24.35.57438 > 10.10.10.11.53: 11102+ A? weather.opensprinkler.com. (43)
08:09:32.917722 IP 10.10.10.11.53 > 10.10.24.35.57438: 11102 3/13/7 CNAME os-weather.uqyefyn54x.us-west-2.elasticbeanstalk.com., A 35.166.80.149, A 54.148.225.19 (510)
08:09:32.930924 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [S], seq 0, win 768, options [mss 550], length 0
08:09:32.942999 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [S.], seq 1484558194, ack 1, win 27600, options [mss 1380], length 0
08:09:32.945217 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [.], ack 1, win 1024, length 0
08:09:32.946624 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [P.], seq 1:146, ack 1, win 1024, length 145: HTTP: GET /weather129.py?loc=XX.XXXXX,-XX.XXXXX&key=&fwv=217&wto=”h”:50,”t”:100,”r”:100,”bh”:30,”bt”:70,”br”:0 HTTP/1.0
08:09:32.957898 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [.], ack 146, win 28160, length 0
08:09:33.505364 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [P.], seq 1:322, ack 146, win 28160, length 321: HTTP: HTTP/1.1 200 OK
08:09:33.505853 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [P.], seq 322:427, ack 146, win 28160, length 105: HTTP
08:09:33.506305 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [F.], seq 427, ack 146, win 28160, length 0
08:09:33.508324 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [FP.], seq 146, ack 322, win 1024, length 0
08:09:33.511047 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [.], ack 427, win 1024, length 0
08:09:33.513409 IP 10.10.24.35.3039 > 35.166.80.149.80: Flags [FP.], seq 146, ack 428, win 1024, length 0
08:09:33.520245 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [.], ack 147, win 28160, length 0
08:09:33.522503 IP 35.166.80.149.80 > 10.10.24.35.3039: Flags [.], ack 147, win 28160, length 0Attachments:
Your ‘Last Successful Weather Call’ time stamp is none so that means the controller has never received the call result. The temp/humidity displayed in the app is acquired independently by the app and does not indicate that the firmware has received such data. Do you have a firewall that blocks the incoming packets to OpenSprinkler, or maybe you set OpenSprinkler in static IP mode but did not set the gateway IP correctly?
Yes, the device is firewalled, however everything it needs is allowed.
I’ve attached a packet capture showing the entire boot sequence.
Packet capture looks good: DHCP, ARP, NTP, then DNS for weather.opensprinkler.com and a HTTP GET for http://weather.opensprinkler.com/weather129.py
HTTP response has data.
HTTP request (location removed):
GET /weather129.py?loc=xx.xxxxx,-xx.xxxxx&key=&fwv=217&wto=”h”:50,”t”:100,”r”:100,”bh”:30,”bt”:70,”br”:0 HTTP/1.0
Host: *
Accept: text/htmlHTTP response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Wed, 12 Jun 2019 14:20:53 GMT
ETag: W/”68-/vS12hYKPzkncby4vbbW5fqfLcY”
Server: nginx/1.14.1
X-Powered-By: Express
Content-Length: 104
X-Cache: MISS from archer
X-Cache-Lookup: MISS from archer:3128
Via: 1.1 archer (squid/3.5.23)
Connection: close&scale=57&rd=-1&tz=32&sunrise=309&sunset=1225&eip=168433699&rawData={“h”:59.25,”p”:0,”t”:63,”raining”:0}
No.
Your forum wont let me post a pcap file, so I’ve resorted to taking a screenshot in wireshark of the boot sequence:
Attachments:
In the GET command, I see a:
/weather129.py
this is rather strange because this means it’s using weather adjustment method 129, which doesn’t exist. The weather service ignores that non-existent number and probably resorts to method 1 (zimmerman), but the fact that the controller is sending out 129 means something is wrong. My suggestion is to export your configurations to a file, as a backup copy, then perform a factory reset, and right after reset, check to see if you can get successful weather call timestamp, then import your configurations.@Ray, I think /weather129.py might be Zimmmerman (1) and California Restriction (128).
- You must be logged in to reply to this topic.