Tagged: Lock NTP Syncing
January 7, 2020 at 1:40 pm #63909
I have been using the OpenSprinkler for a number of years and it is awesome.
I want to report this, and i will update if i see it again.
I recently upgraded a 2.3 a/c OpenSprinkler to firmware version 2.19
I was looking at a program using the mobile app on an android phone and making some changes (I don’t that often) and suddenly, i got no response.
I have it plugged into a nano wi-fi as a client. I was able to ping the nano but could not ping the OpenSprinkler
The sprinklers all still worked, i could see the zones starting and stopping.
It is in a hard place to get to and i just went to look at it and the LCD said “NTP Syncing” and it was stuck there.
I powered it off and back on, it did a quick NTP Sync and is back to normal.
I have never seen it do that before and i hope i don’t see that again.
NTP IP 184.108.40.206 port 13650
IP of OS is 192.168.101.220
Subnet Mask 255.255.255.0
DNS Address 220.127.116.11January 17, 2020 at 10:08 am #64027
Hmm, this sounds quite unusual as the ‘NTP syncing’ step is guarded by a timeout (60 seconds by default) so it really shouldn’t be stuck like that for more than 60 seconds. Has this happened again?January 17, 2020 at 1:58 pm #64033
It has not happened since. But i don’t modify programs often.
Timing wise, I was right in the middle of modifying programs on my android phone with the OS app when it happened.
Pure speculation, but perhaps doing the program update coincidentally just as the NTP was syncing is what may have caused it.
What somewhat unexpectedly surprised me is that it only caused the Ethernet to lock up (sprinklers kept going on and off as expected).February 12, 2020 at 3:04 pm #64321
I don’t know if this is related to the NTP not syncing. But today i had another issue. A zone started going off at 12 noon, however I know it is scheduled for 12 midnight. I checked the OS. I have two images of time.gov vs what was on the OS. How can the time get so off? I rebooted and the time issue appears corrected, for now.
Attachments:February 15, 2020 at 9:44 pm #64355
The same thing happened again today. It is feb 15,2020. My sprinkler at noon was running, i checked the clock on the OS and it was incorrectly set at feb 14,2020 midnight. Is there way to track NTP calls and results?February 19, 2020 at 3:10 pm #64384
This could be NTP sync problem but could also be a time zone problem (i.e. the controller wasn’t able to get time zone correctly using your location). To check any time zone issue: if your controller runs firmware 2.1.9 minor revision (2), you can check the system diagnostics (at the home page, swipe left to right to open the left side menu, then click on System Diagnostic). It will show when the last weather call was sent out and when the response was received. The time zone data is obtained through the weather call.
I noticed that you said on your OS, the NTP IP is 18.104.22.168 port 13650: is this a custom NTP server IP? I think the default NTP server is different. Also, where is port 13650 coming from? I think by default NTP uses port 123, I don’t think the controller even provides an option to configure NTP server port.February 19, 2020 at 3:23 pm #64388
NTP IP 22.214.171.124
IP of OS is 192.168.101.220 port 13650
Subnet Mask 255.255.255.0
DNS Address 126.96.36.199
i had the port listed in the forum posting on the wrong line. It is the ip of the OS, not the NTP
The other day i changed the NTP to 188.8.131.52 but i still saw the anomaly happen again.
I have been watching it on and off today and so far so good.
attached is an image of system diagnostics, i don’t see anything regarding time zone data.
It does show an “offline” condition for the weather service. Could that be related and any idea what causes that?
Attachments:February 21, 2020 at 1:51 pm #64415
If you haven’t done so, you can submit a support ticket attaching a copy of your configuration (i.e. the file saved from ‘Export Configurations’). I will check if we can reproduce the issue on the test OS.
The fact that it’s reporting ‘offline’ for Weather Service, and also the Last Response is empty seems to suggest there are other issues: Last Response being empty generally means the controller did not receive the result of the weather call. This could be due to your router blocking the incoming traffic (e.g. if you have set up a firewall etc.), or it could be the weather url has been changed and the weather server is unreachable. In any case, if you send us your configurations we can take a look and find out more.February 21, 2020 at 2:49 pm #64416
I just looked it again, and it happened again. It is currently 2/21/2020 at 2:47. The weather call had just gone out and the weather services shows online and it shows the wrong date and time for when it was received as well. I rebooted the OS and after rebooting the correct date is back.
Attachments:March 12, 2020 at 8:43 am #64625
I am trying to narrow down the time drift issue on the 2.3AC running 2.19 firmware. I was waiting for it to happen again on my spare test system, after which i was going to reduce the number of zones to see if it happened again.
Yesterday for some unknown reason the OS rebooted itself. I have it on a backup power supply so there is no reason it should have rebooted.
This morning i attempted to look at it in the browser and could not access it. I looked at the display and it displayed something i had seen one time before and posted originally in this thread. See attached image.
Attachments:March 12, 2020 at 11:03 am #64629
I just watched it more closely, and yes it it timing out and restarting and then getting stuck on the NTP Syncing message, and then restarting again, repeatedly.
I reset the power and the NTP Synced and the OS came back online.
- You must be logged in to reply to this topic.