[akom]

Confirmed that was it.
I worked around it in a way that would still work on official boards, and would also help if an RTC failed:

===================================================================
--- main.cpp	(revision 798d2fea340b9bccdb317a7bac285a5d3c31d33a)
+++ main.cpp	(date 1586518946000)
@@ -297,9 +297,14 @@
 
 	pd.init();						// ProgramData init
 
-	setSyncInterval(RTC_SYNC_INTERVAL);  // RTC sync interval
-	// if rtc exists, sets it as time sync source
-	setSyncProvider(RTC.get);
+	if (RTC.detect()) {
+		setSyncInterval(RTC_SYNC_INTERVAL);  // RTC sync interval
+		// if rtc exists, sets it as time sync source
+		setSyncProvider(RTC.get);
+	}
+	// else no RTC: relying on NTP and for the clock to be somewhat accurate.
+	// May need to reduce NTP interval if the drift is bad
+
 	os.lcd_print_time(os.now_tz());  // display time to LCD
 	os.powerup_lasttime = os.now_tz();

Happy to make a PR if that’s appropriate.

Many thanks for the guidance.

[akom]

That must be it (it eventually happened with 0.0.0.0 as well). I’ll dig through the code.

Thanks again!

[akom]

Thanks for the reply.
I had it configured to use my NTP server (on my local LAN) that is known to function correctly (all my DHCP clients use it).
I’ve now set it to 0.0.0.0 and will monitor stability.

[akom]

I know this is old, but I’m having the same issue with the unified firmware. When OS boots up it gets correct time from (my local) NTP server and displays correct time in the web UI. Sometime after (hours or minutes), the time switches to this: Feb 06, 2106 02:58:49. This is repeatable.

This is all I have in the serial debug output:

NTP Syncing…
X.X.X.X
NTP done.
1586435525

(That’s the output from boot, there is no further output when the time gets screwed up).

I have not configured a Weather Underground key (assuming that this is OK), and the forecast is displayed correctly and for correct dates.
Attached is the diagnostic screen. Note that OS has been up for only about an hour, but “Last Request” and “Last Reboot” are both completely wrong (screenshot is from April 9, 2020)

Happy to provide further details or let me know what I should try on my end.

(I’m running the latest master firmware with some tweaks for my relays, nothing to do with NTP. I can load clean master branch as well for a test)

Attachments:

1. 

   Screenshot_2020-04-09_10-05-21.png
   

[akom]

For the record and if anyone goes down this path, I got it working (well enough for me).
It’s not pretty but should be easy to update when upstream changes occur.

My fork contains a brief explanation and the code: https://github.com/akomakom/OpenSprinkler-Firmware-CustomLatch

[akom]

Thanks Ray, that helps a lot (and explains why D1 and D2 relays don’t work with my modified code). (I had already modified the functions just as you suggested). I’ll play with it and digest your advice. I don’t really need to use the I2C pins in my setup. If I come up with anything worth sharing, I’ll follow up.

[Author]

Posts