- This topic has 14 replies, 4 voices, and was last updated 4 years, 1 month ago by
.
-
Posts
-
Hi.
I have a 2.3 (AC) running 2.1.9 firmware located in Australia that get’s the correct time from the NTP server after a reboot but always ends up being 24 hrs out after a couple of days. For example.
Right now it is 5:00pm on Thursday 5 March but the Opensprinkler interface is saying it is 5.00pm on Wed 4 March.
The diagnostics are saying that it was last rebooted on 3 March which is correct.This presents a problem with the schedules as it will water the plants and then do it again the next day. I guess I could just set the schedules with the knowledge that the days will end up being out by a day but I believe the weather adjustment doesn’t work as it knows it going to rain on Friday for example but waters the lawn because it thinks it’s actually Thursday.
I’ve tried setting another NTP server with the same result. It looks like the Opensprinkler only updates from NTP upon reboot.
A. Is anyone else seeing this behaviour?
B. Is there somewhere I can configure NTP updates to occur automatically?
C. Is there a script I can run to reboot automatically each day?Cheers
I suggest that after a reboot (after it gets correct time), you turn off NTP (in the Settings page -> Advanced, you can turn off NTP). Monitor it for a few days and see what happens.
That is a great idea Ray. Can’t believe I missed that option particularly since I had been in there and added a different NTP server as a test.
Finger crossed.
Cheers.Hmm, Which settings page?
I’m going to (Rubik’s Cube Button) > under programs and settings, “Edit Options” > expand “Advanced”, and I’m not able to find it. (I’m running OSPI if that matters).
Thanks!Attachments:
If you use OSPi: this option is not available because for RPi NTP is managed by Raspbian, the firmware does not manage NTP at all.
I experienced this same behavior recently.
Per Ray i turned of NTP and it stopped, but time drifts a little.
I turned NTP back on 2 days ago and set it to 132.163.96.6 and have not seen it happen so far, i expect it to fail, but hope it does not.
Thanks, Ray! I thought that might be the case.
For anyone who is interested, I used the following command to verify that NTP was operating properly on Raspbian:
timedatectl statusIt showed “NTP service: active” for me, and I didn’t do anything special when I set up Raspbian, so I assume it’s enabled by default.
It has been 4 days since turning off NTP and the date is still correct. I have lost a couple of minutes, so am seeing the drift that Gary mentioned. Will give it a few more days to confirm behaviour before trying another NTP source again.
I tried to put back an NTP and it was working for about three days, but i just looked at it and it just lost time.
If you look at the attached image the time at the top (is blurry) is 3/9/2020 15:02, but the time of the last call shows it took place Mar, 10 10:00. It is impossible for the call to be 18 hours past the current time.
It did the call and then either in the weather call or NTP call (if there are 2 different calls) it got set back in time.
Also, if you look at the image instead of saying it made the call “x hours ago” it says it is going to make a call “in 18 hours”. Instead of showing a call in the past it is displaying a call to be made in the future. This behavior only started happening in the last couple of months. Maybe after the firmware update. By the way, i also have a 2.3 (AC) running 2.1.9 firmware.
If there was feature logging weather calls and NTP calls it could be perhaps further narrowed down to what is causing this.
Given that you have a large number of zones and programs, to isolate the possible causes of the problem, I suggest that you temporarily set the number of zones to a smaller one (like 16), and reboot, and see if this makes any difference. I personally can’t reproduce the issue you are seeing — I’ve imported your configurations on a test OS 2.3 and I don’t see any NTP or timing issue. But I wonder if the problem maybe due to the rather large number of zones and programs, such that when accessing the controller, transferring this amount of data is triggering some buffer overflow problem that we haven’t discovered, and that in turn affects NTP. The easiest way to test is to make the number of zones smaller, so that when you access the controller, the data remains small. At least this is worth a try since I otherwise have no clue why this is happening.
bigmaxy, how many zones do you have?
I have two OS systems, one online and a backup offline. The time change did not happen on the test system, but i somehow rebooted itself at 2am last night. There problem seems to arise after 24 hours usually. I will plug the spare into a UPS so to mitigate power issues (which i really don’t have, so i don’t know why it rebooted last night).
Once i see it happen on the test system again, i will reduce the zones to 8 and then monitor it.Hi Gary. I have a system expanded to 32 zones. Of which 21 are configured plus 2 masters.
@Ray. Will disabling the zones I am currently not using so that I have only a couple be enough or do I actually need to delete them for the test?
I have the master zones set to Zone 31 and Zone 32 so not ideal to drop it down to 16 for a test as it will require re-wiring.I have physically 40 stations, but i have it configured as 48 stations. I have one master on station 8 (on main controller). I have 30 zones plus the master psychically wired. The 8 stations above 40 I use for RF devices. I have had it configured this way for a number of years, but it is only recently the time changing issue started.
Maybe this is an issue with 2.3(A/C) running 2.19 with a “larger” number of zones. I do not have one, but perhaps the 3.0 version does not have the issue.
There is no need to delete any zone information: you can just go to Edit Options -> Station Handling, and set the number of zones to a smaller number, like 8 or 16. Then reboot so the controller starts from fresh. The previous zone information is still preserved, so in the future when you change the number of zones back, the zone name, programs etc. are still there, they are not lost.
The reason to try this experiment is to check whether something is corrupting the Ethernet buffer, which may cause the weird NTP sync problem. One such possibility would be if you have a large number of zones or programs, as soon as you access the controller, transferring that amount of data from the controller to the app / UI may trigger the corruption. So by capping the number of zones, it allows us to tell if this might be the root cause of the problem.
Firmware 2.1.9 uses a different library and mechanism to handle Ethernet connections, so it’s possible this is a new bug that wasn’t in previous firmwares.
- You must be logged in to reply to this topic.