- This topic has 25 replies, 5 voices, and was last updated 9 years ago by
.
-
Posts
-
I am having a problem where the weather adjustment parameters are updating correcting except for the % watering. That is always at 100%.
In searching thru the forum, i have rebooted multiple times. Made sure that I can reach the OS from the internet. Changed my port forwarding around but the percent watering will always stay at 100%. Even though it is wet and chilly here. 🙂
http://weather.opensprinkler.com/weather1.py?loc=pws:KUTSOUTH11&key=*removed*
returns
&scale=0&restrict=0&tz=24&sunrise=393&sunset=1218&maxh=91&minh=31&meant=55&pre=0.160000&prec=0.200000&hc=92&eip=*removed*
so I would expect some change to the percent watering…..
What’s my next steps in troubleshooting?
Thanks.
Dennis
Attachments:
Been reading a lot of other threads with similar issues as mine.
Thought I would post the output of my var’s.
{“fwv”:213,”tz”:20,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:23,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”hwv”:21,”ext”:1,”sdt”:0,”mas”:0,”mton”:1,”mtof”:0,”urs”:0,”rso”:1,”wl”:100,”den”:1,”ipas”:0,”devid”:0,”con”:110,”lit”:100,”dim”:15,”rlp”:0,”uwt”:1,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”lg”:1,”reset”:0,”dexp”:1,”mexp”:5}
Here’s the latest output of my wundergound station near me.
&scale=0&restrict=0&tz=24&sunrise=391&sunset=1218&maxh=96&minh=46&meant=48&pre=0.380000&prec=0.480000&hc=79&eip=*removed*
I’m at a loss right now.
D
Does the device show the correct timezone? This is part of the reply from the weather service. Also, the sunrise and sunset times under the forecast page (clicking the weather icon on the home page) will show the controller’s sunrise and sunset times for the current weather (future days are calculated in the app).
Are you using a static IP on the device? If so, what is your gateway IP? Do you have any firewall appliances possibly filtering OpenSprinkler weather requests?
Just some thoughts to try and troubleshoot, thanks.
No, the timezone is off by 1 hour. I thought this was because the firmware doesn’t support Daylight Savings Time. Correct?
The sunrise and sunset times are off. I am seeing continued requests going to wunderground. I can only do a packet capture on my Firewall for 60 seconds at a time. Looks like every 2 1/2 minutes the unit will do a GET request to wunderground. I will send you a pcap as a private reply.
I am using DHCP but as a fixed IP on my Meraki FW device. GW is 192.168.1.1. It should not be filtering anything.
Daylight Savings Time is supported through the weather lookup and makes sense that it is also incorrect. The weather query also retrieves the day’s sunrise and sunset which explains why those are also incorrect.
We had one user on the forums who had an issue with the controller not reading weather reply when a firewall was installed between the device and the Internet. I think we might have found the firmware issue related to this and resolved in 2.1.4 which should be released very soon.
Is there anyway to disable the firewall just to test?
Here’s the pcap. It is formatting the GET request appropriately. The response comes back from sunrise at 390 and sunset at 1220. But is never being set. The capture is on the LAN side of the FW.
OS is at 192.168.1.23 and GW is 192.168.1.1
Thanks for the help.
This is frustrating me and usually i can figure these things out.
Dennis
PS. I am consuming a lot of API requests. Got the overage emails from wunderground yesterday and today.
I noticed in the packet dump you sent me the packets are being tagged with a VLAN which changes the ethernet header, specifically the type. If I am not mistaken, the Arduino library is very limited and not able to handle the VLAN packets and is simply ignoring them.
I understand you have the default VLAN select however I think the mere existence of that tag and the change of the packet from type IP to type 802.1Q (0x8100) causing the packet to be ignored.
If you can, please remove the VLAN tagging from the port the OpenSprinkler is using and see if that resolves the issue.
I am unable to disable the FW. I did do a quick reconfigure and disabled .1q.
No change. Did a hard reset….
Here’s the latest pcap.
You did a hard reset of the device? You mean you reset all options and let it reboot? Did you also set back the weather adjustment and API key? Also, check the timezone and sunrise/set times again.
Your latest PCAP does in fact look like a normal IP packet being sent to the controller and therefore should no longer be having the issue. Are you still seeing incorrect data, sometimes it can take a few minutes for the controller to query the service and update accordingly.
Let me know once you double check everything after turning off the tagging. If the issue is persisting I am no longer sure why since the PCAP looks correct now.
The hard reset was power off/on. I have removed and added the API key as well. Let it run overnight and timezone and sunrise/sunset times were still reflecting 6am and 6pm.
My next step is clear out the whole config and default it. Do a minimal config and see if that works and then restore the configuration.
Unless you can think of something else. What is the possible fix coming in 2.1.4 related to the FW in your post above?
Dennis
Since changing the network configuration, try clearing the config by doing a reset options (just to rule out any other issues) and try again by setting your API key, weather adjustment method (Zimmerman) and location.
The changes in 2.1.4 are network related (closing sockets instead of leaving them open, properly send multiple packets for large packets exceeding MTU, etc). Overall this a huge stability improvement and I’m curious if it has any effect on your situation. Regardless, try the above and let us know. Otherwise, 2.1.4 should be released, maybe today.
I did a reset on the panel via B1. Added generic config of location(changed from boston), API key and added Zimmerman.
timezone is still -5. Sunrise/sunset is 0600 and 1800.
No Bueno.
I am having similar frustrating problems with weather adjustment. Hoping the 2.1.4 firmware update will fix it.
I was having issues with my OpenSprinkler getting the correct information from Wunderground when it was going through my firewall. I started getting the notifications from Wunderground saying I had exceeded my limits as well and the Sunrise/Sunset time was incorrect as well on the controller. Everything worked fine when I turned anything off on the firewall that scanned the traffic. Once I turned on anything(content filter, A/V scanner, ect…) that scanned the traffic the OpenSprinkler wouldn’t communicate properly with Wunderground and the calls to Wunderground would go up.
I ended up also posting for help in the forum’s used by my firewall and basically it came down to putting a bypass rule in for the OpenSprinkler. The bypass rule told the firewall to ignore all the traffic coming from or going to the OpenSprinkler. Once the bypass rules were in place everything worked and has been working since. Maybe something to try on your firewall as well.
This is the thread I started about it: https://opensprinkler.com/forums/topic/exceeding-wunderground-api-calls/
Thanks. I have checked out the firewall but will have another go in case. Can someone point me in te right direction for the zimmerman formula. I saw it somewhere but can’t for the life of me find it now
You can find the formula here: https://opensprinkler.freshdesk.com/support/solutions/articles/5000017312-using-weather-adjustments (at the very bottom).
Yes, my firewall checked out fine as well. Nothing in the firewall logs showed any kind of error with the traffic, it showed everything working as it should. There was just something the controller didn’t like when the traffic was being inspected. Don’t know what it is, but it just wouldn’t communicate properly with Wunderground when the traffic was passing through the firewall. Putting a bypass rules in just for the controller prevents any of the traffic going from or too the controller from being inspected. I realize it’s a small hole in the security of my network…but it’s small enough that I feel comfortable with it.
@seockwig could you also provide some packet capture data? I’m interested to see if I can find a pattern.
I’m am seeing a TCP segment from the internet to OS. The destination port on OS is 3040. Which is strange cause i am doing port forwarding of just port 80.
Also, within the last 15 minutes my watering percentage changed to 21%. Which doesn’t quite make sense if I understand the formula right.
But it is the first time it has changed…. Sunrise and Sunset are still 0600/1800.
OpenSprinkler does not use port 3040. If you have traffic successfully hitting port 3040 of the device (which it doesn’t listen on), then your firewall rules must be allowing 3040 (can you see the packet information?).
I noticed something interesting when reviewing your PCAP: the reply from weather.opensprinkler.com is split into two packets (ID 18 and 19 of latest pcap). I did a capture on my home network and noticed the reply is contained to one packet. I am wondering if your firewall is somehow splitting the packets. This would likely cause an issue with the firmware reading the HTTP reply. Do you know why the packet might be getting split?
Update: I can confirm after reviewing my own packet capture, the VLAN tagging doesn’t matter. Mine also adds the 802.1Q header, so you can ignore this aspect of it.
@samer…I can, but it may not be for a couple of days.
- You must be logged in to reply to this topic.