- This topic has 58 replies, 6 voices, and was last updated 9 years, 4 months ago by
.
-
Posts
-
&scale=-1&tz=16&sunrise=402&sunset=1020&maxh=-1&minh=-1&meant=-500&pre=-1.000000&prec=-1.000000&hc=-1
That’s the correct return.
So I repeated your experiment: setting time zone manually on the controller to +14:00, upon NTP syncing, it got the time of UTC+14:00, then after about 30 seconds it reset the time zone to UTC-5:00 and obtained the current time of UTC-5:00 (because the location is Boston,MA). I can’t reproduce the issue you reported, and I honestly don’t have a clue.
I originally had the controller out in the garage using a network extender, but have moved it into the office connected directly to the router for these tests. It hasn’t made any difference.
It has been brought up in another thread that when OpenSprinkler’s port number is not 80, the query to weather script will fail, and I realized this will affect the time zone query as well because the time zone query uses the same script. I didn’t think it’s related to your case, because you said you performed a reset of the controller, so the port number must be reset to 80. Just to bring this up in case it’s relevant.
That was it! I set it to port 80 and the NTP set the clock correct to my zip code.
I did do a reset and the port defaults to 80, but then I reset the port to 90 to access the menu through the web interface. I wanted to use a port that isn’t so obvious.
This also explains why my Wunderground wasn’t making the expected adjustments and sometimes coming up blank.
Is there a chance this will be fixed in future updates?
Yes, I’ve found the bug in the firmware that leads to the port number and will be releasing an update very soon. Thanks.
Ray,
Thanks for hanging in there with me to figure this out. The issue wasn’t a big deal since I could have manually set the time, but you took my issue seriously and came up with the solution. I’ll be watching for the update.
Walt
- You must be logged in to reply to this topic.