wrong dates with WeatherUnderground API

[Anonymous]

in “Last Weather Call” and “Last Successful Weather Call”, I’m getting wrong dates, i.e., 6 Feb 2106. Also time is forward about 1 1/2 hrs. Should I delete my WeatherUnderground key and reinstall this feature?

[Samer]

What times are shown for the device time? Also can you possibly make a backup of your configuration and send us that via email ([email protected])? I want to check the timestamp the controller is showing compared to the date displayed on the app (as they app maybe parsing the timestamps incorrectly due to timezone issues).

[Anonymous]

Unfortunately I recently lost the controller hardware completely and I’m looking to replace asap. Support ticket for this issue is being processed separately. I won’t know what’s going on inside software configurations until the unit is up and running again.

In the interim, I’m hooking up a spare Rainbird controller to keep my garden going. Thanks for the response!

[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
   

[Ray]

Can you go to Settings page and check under Advanced, NTP server, what’s the NTP server IP there? The latest firmware has a logic where if NTP IP is 0.0.0.0 it uses the default ntp.pool.org, otherwise it uses your specific NTP IP. At factory reset, it set NTP IP to 0.0.0.0 so it uses the default ntp.pool.org. However, if you upgraded from a previous version of the firmware, it may have some other NTP IP there, which may have stopped working reliably.

[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.

[Ray]

I just realized something: because you are using your own hardware build, it doesn’t seem like you have an RTC chip (DS1307 or PCF8563 or any RTC). The firmware writes NTP time into RTC and syncs with RTC once every hours or so. If you don’t have RTC, it will certainly get incorrect time. You can comment out any code in main.cpp that has to do with RTC.

[akom]

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

Thanks again!

[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.

[Ray]

Sure, go ahead. I am also considering adding an option to disable RTC to provide some flexibility: we did encounter a couple of cases where the RTC chip went defective (it’s detectable but doesn’t work properly) causing the timing to be messed up. Adding the option can help bypass the problem.

[Author]

Posts