OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Wrong time on the unit?
- This topic has 27 replies, 7 voices, and was last updated 3 years, 7 months ago by Ray.
-
AuthorPosts
-
April 22, 2020 at 1:53 pm #65335
robiParticipantI’m pasting this here too as it looks like the issues on GitGub get less attention (no feedback received there) from anyone.
I am using OpenSprinkler 3.1 – AC running firmware 2.1.9 (3). A few days ago I’ve noticed that waterings scheduled for the night start running during the day.
After some investigation I’ve noticed that OpenSprinkler’s clock is ahead with 7 hours (I’m located in Central Europe). The clock is wrong both on the web interface and on the LCD screen.The unit is set up to use an NTP server, and also the coordinates of my location are good. It’s not possible to select the timezone manually, however the timezone in the web interface is also correct (+2:00). Seems that timezone isn’t correct internally…
If I untick the NTP sync, I am able to set the clock manually. The clock sets up well in both the web interface and on the LCD screen.
If I tick it back to sync NTP and reboot the unit, after connection it starts NTP syncing, and it jumps forward to 7 hours ahead. This can be seen on the LCD too.The NTP server is good (it’s an internal one using a GPS receiver with 1PPS reference signal) because dozens of devices are using it and it’s also part of the public NTP pool.
I’ve tried downgrading the firmware back until 2.1.9 (1) but still the same. I’ve tried resetting to factory defaults, nothing changed.
What could have happened? Until a few days ago, everyting was fine…
April 22, 2020 at 1:57 pm #65341
RayKeymasterThe time is calculated using two pieces of information: the NTP time (which is UTC+0 time) and the time zone (this is obtained from the opensprinkler weather server, which calculates your time zone using your location). If you export your configurations to a .json file, and open the file, there is a variable called “tz”, which is the time zone. This value should be equal to your time zone (sign included) times 4 plus 48. For example, if your time zone is UTC+0, it should be 48, if it’s UTC+2, it should be 56; if it’s UTC-4, it should be 32 and so on.
Basically if time zone is correct, then the issue has to do with NTP sync, otherwise it has to do with time zone not being calculated correctly.
April 23, 2020 at 10:00 am #65368
robiParticipantIn my .json file I have
"tz":56
.
The NTP server doesn’t provide any information about the timezone. All time data handled by NTP is in UTC; it’s the local time zone setting which determines the offset from there.For some reason OpenSprinkler doesn’t calculate the correct time based on the timezone.
Is the timezone information avilable at the moment of calculation? Because i’ve noticed that after reboot, the first thing is to do an NTP sync. Maybe during boot the NTP sync and time calculation is done first, and connection to opensprinkler weather server afterwards, thus the determination of the timezone is done after the time has been calculated?Just a tip…
April 23, 2020 at 10:06 am #65375
RayKeymasterYou said “The NTP server doesn’t provide any information about the timezone” — yes, of course, that’s why I said “The time is calculated using two pieces of information: the NTP time (which is UTC+0 time) and the time zone.
Your time zone looks fine: 56 means UTC+2, which I assume is the correct time zone for your location. If time zone is correct, then the only thing I can think of would be NTP is getting an incorrect UTC+0 time for some reason. Go to Edit Options -> Advanced, NTP Server IP, what’s the IP set there? If you have firmware 2.1.9(3), you can set it to 0.0.0.0, which will make it use the default pool.ntp.org. Otherwise if there is a valid NTP IP address, it will use that server.
April 23, 2020 at 3:08 pm #65377
robiParticipantAt NTP server IP, I have my own NTP server running from a 1PPS reference signal provided by a GPS receiver. This server is also part of pool.ntp.org.
What do you mean by “the only thing I can think of would be NTP is getting a UTC+0 time for some reason”? All NTP servers always provide UTC+0.
April 23, 2020 at 3:08 pm #65378
robiParticipantFyi, I’ve changed the NTP address to 0.0.0.0 but it behaves exactly as before.
April 23, 2020 at 3:09 pm #65381
robiParticipantAnything changed on server side maybe?
Because suddenly it fixed all by itself.
April 23, 2020 at 3:09 pm #65382
robiParticipantSorry for posting so many times but it looks like this forum engine is enforcing moderation on every post and not allowing me to edit my previous post.
Looks like I’m not the only one who has/had this issue.
April 23, 2020 at 3:11 pm #65390
RayKeymaster“Anything changed on server side maybe?” What server? NTP server — we have no control over that; opensprinkler weather server — we made no change, plus, your time zone is correct, so that’s not the issue.
The post you linked to said specifically that’s not a NTP issue, it’s a WiFi connection issue. So that post and the issue you encountered are not the same.
April 24, 2020 at 8:50 am #65391
robiParticipantI was referring to the opensprinkler weather server, which calculates your time zone using your location, which you mentioned before.
The problem flow:
– The NTP is rock solid, and gives UTC time as standard. Verified as being part of pool.ntp.org – it can’t give false time.
– I’m in UTC+2 – that’s based on the calculation from the map, by opensprinkler server
– After NTP sync, time is set to UTC-6 (or UTC-5 can’t remember exactly).
Looks to me as a bug in the firmware somewhere. In the exact moment of time setting the timezone information may be invalid on the unit – that’s what I’m trying to conclude. And that may be different from what’s in the config, because the config export I can make in the browser happens much later than the time calculation happens.
If the timezone info would be accurate in every moment, I don’t see how an UTC-6 would come into the picture. If at boot there’s no timezone info, the unit should default to UTC+0, not UTC-6.April 24, 2020 at 8:50 am #65394
robiParticipantAnother idea: what happens if/when OpenSprinkler can connect to the NTP server but can’t connect to opensprinkler weather server during boot?
April 24, 2020 at 8:55 am #65398
RayKeymasterYou misunderstood how the time is calculated. The time zone (tz) variable is stored in flash memory space and it’s preserved whether or not the controller can reach the opensprinkler weather server or not. Also, it’s not updated frequently, the controller only sends out a weather request at reboot, and every two hours afterwards. Next, every time the controller receives a valid NTP result, it stores it in the real-time clock chip, which is battery backed, so even if the controller is offline, the real-time clock will keep the time remembered and keep it going.
Since you’ve made a lot of posts, I am getting confused exactly when the time change is observed, so here are some questions:
1. Upon reboot, while the LCD displays ‘NTP syncing’, is the time correct?
2. If you observe time change, roughly when does it happen? Immediately after NTP syncing, or some time after?April 24, 2020 at 5:12 pm #65399
robiParticipantI just tested now again.
Unplugged from power, re-plugged it.
1. Yes, the time is correct during the LCD displays ‘NTP syncing’.
2. The time changes to wrong value immediately after NTP syncing.Waited a few minutes. Unplugged from power, re-plugged it. Now it fixed itself:
1. The time is the same as before cutting the power (the wrong value) during the LCD displays ‘NTP syncing’.
2. The time changes to good value immediately after NTP syncing.April 24, 2020 at 5:12 pm #65401
robiParticipantI made a video about it:
https://youtu.be/1HUUPU7f9L4April 24, 2020 at 5:17 pm #65415
RayKeymasterI honestly have no idea what’s causing this. I suggest that you submit a support ticket with your configurations attached so we can import it on a test OS and see if we can reproduce the issue. If it’s a time zone issue, one thing you can do is to clear your location (click the cross icon next to location) and then the time zone will become editable. So you can set the time zone manually.
April 25, 2020 at 8:45 am #65425
robiParticipantTicket sent. Thanks.
May 4, 2020 at 9:07 am #65639
robiParticipantFactory reset from the buttons on the unit (according to the manual) + restoring the config fixed the issue.
May 9, 2020 at 1:25 pm #65869
franzsteinParticipantToday I updated my OpenSprinkler 3.1 – DC from Firmware Version 2.1.9 (2) to 2.1.9 (3). The update went very easy. No factory reset and no change of the WiFi address was performed during the update process. There was also no need to restore the saved configuration, as everything was still in place afterwards. However, after the update the OpenSprinkler’s clock is ahead with 10 hours! I checked the timezone variable “tz”:56, which corresponds to my local time UTC+2.
After following the hints given in this thread I changed the NTP IP address from 50.97.210.169 to 0.0.0.0, which will make OpenSprinkler use the default NTP server pool.ntp.org. This gives the correct local time again and solves the issue!
I am not sure where the NTP IP address 50.97.210.169 comes from? I think it’s not pointing to a valid NTP server anymore and has to be removed to get the correct local time.
May 9, 2020 at 1:27 pm #65876
RayKeymaster50.97.210.169 is an NTP server we’ve used for a long time in previous firmwares. I am not sure where I got it from, probably from an open-source piece of code. It seems this NTP server is no longer working reliably, that’s why in firmware 2.1.9(3) we changed it to use DNS name like pool.ntp.org
May 13, 2020 at 11:54 pm #65940
NicolaParticipantI had a very similar experience (OS 2.3, fw 2.1.9). As the unit is located in Italy, I changed the time server to ntp1.inrim.it (193.204.114.232) and it works well now.
June 3, 2020 at 9:07 pm #66556
gpsheadParticipantRecommendation for OpenSprinkler maintainers:
(1) Update your 2.1.9 (3) upgrade instructions today to mention the need to change this “Advanced Setting” to 0 when upgrading.
(2) Make future firmware versions and/or config UI versions reject and highlight as bad the known bad former default pre-configured NTP server IP Address. Anyone with that value set is just going to have a bad (offset) time and will either abandon opensprinkler or be reaching our via support tickets and forums.I made a PR proposing one possible way to tackle (2) on the firmware side of things. https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/128
September 22, 2020 at 3:15 am #68309
deon.dupParticipantI have the same issue, and followed the thread, but can’t figure it out. Firstly I don’t have a setting under Settings>Advanced to switch NTP either on of off; there is no setting. I have “fwv”:219, and “fwm”:4. I also don’t see ntp in the /jo? json. The ntp settings {1,2,3,4} are all 0, which I guess is a good start.
Attachments:
September 22, 2020 at 3:20 am #68311
robiParticipantGuys from opendata-stuttgart ran into exactly the same issue on their environmental monitoring product which is using the same chip as OpenSprinkler, and managed to resolve the issue:
https://github.com/opendata-stuttgart/sensors-software/issues/729#issuecomment-692966276September 22, 2020 at 11:26 am #68312
deon.dupParticipantI tried that UDP on port 123, but not sure if the Pi actually sees that. I think main issue is to first get NTP setup on the Pi, and thereafter why the NTP check box is missing from the Advanced settings tab.
September 22, 2020 at 2:16 pm #68317
RayKeymasterFor OSPi, you will NOT see NTP option because time is managed by your RPi, the firmware does not manage time directly. So if you get a wrong time, you should check your RPi settings, there you can change NTP server etc.
For microcontroller-based OpenSprinkler, the firmware allows you to choose which NTP server you want to use. Since firmware 2.1.9(4) the default is 0.0.0.0, which tells the firmware to use pool.ntp.org. Otherwise if you put in a custom server IP, then it uses that IP.
-
AuthorPosts
- You must be logged in to reply to this topic.
OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Wrong time on the unit?