Keeping the Time Mega 2560

The first part of my project, I needed the mega 2560 to keep track of time.
I have an esp8266 (nodemcu) getting time from ntp then sending it via serial to mega 2560.
The mega receives 6 variables- hour, minute, second, day, month, year.
I would like the mega to count up these variables as needed so I can just do an ntp update every few days.
Would using the time library be possible to update these variables until the next ntp update?
The two variables I really only have to have is hours and minutes.
I'm sure I'm doing this all the wrong ways but it took me some time just to get to this point! lol

NTP servers provide raw Epoch Time. Using that is the easiest way to compare two different time stamps.

jhome:
I would like the mega to count up these variables as needed so I can just do an ntp update every few days.

The Mega is unlikely to stay close enough to clock time for longer than an hour or two because the 16MHz clock almost certainly does not operate at precisely 16MHz. That means that 1000 millis() is not exactly one second.

Incrementing the values should not present a problem.

If you need more help you will need to post your program. And please use the code button </>

so your code looks like this

…R

Why not add a RTC like the DS1307 ? It will keep the time better than the Mega and will add more capabilities like Timestamp.

What is wrong with doing an NTP update every, for example, 20 minutes? That won't burden even a very busy time server.

Thank you all for your input!
My code I’m using on the 8266 has the Epoch time broken down already into the 6 above mentioned categories which is why I ended up sending those 6 variables.

#include <ESP8266WiFi.h>
#include <time.h>

#include <SoftwareSerial.h>
SoftwareSerial SUART( 4, 5); //SRX  = DPin-D2; STX = DPin-D1
String str;

const char* ssid = "";
const char* password = "";

int timezone = -5 * 3600;
int dst = 1;

int cDay = 0;
int cMonth = 0;
int cYear = 0;
int cHour = 0;
int cMin = 0;
int cSecond = 0;

void setup() {

  Serial.begin(115200);
  Serial.println();
  Serial.print("Wifi connecting to ");
  Serial.println( ssid );

  WiFi.begin(ssid,password);

  SUART.begin(115200);   //NodeMCU prefers higher Bd to work
  
  Serial.println();
  
  Serial.print("Connecting");

  while( WiFi.status() != WL_CONNECTED ){
      delay(500);
      Serial.print(".");        
  }

  
  Serial.println();

  Serial.println("Wifi Connected Success!");
  Serial.print("NodeMCU IP Address : ");
  Serial.println(WiFi.localIP() );

  configTime(timezone, dst, "pool.ntp.org","time.nist.gov");
  Serial.println("\nWaiting for Internet time");

  while(!time(nullptr)){
     Serial.print("*");
     delay(1000);
  }
  Serial.println("\nTime response....OK");   
}

void loop() {
  
  time_t now = time(nullptr);
  struct tm* p_tm = localtime(&now);
  Serial.print(p_tm->tm_mday);
  Serial.print("/");
  Serial.print(p_tm->tm_mon + 1);
  Serial.print("/");
  Serial.print(p_tm->tm_year + 1900);
  
  Serial.print(" ");
  
  Serial.print(p_tm->tm_hour);
  Serial.print(":");
  Serial.print(p_tm->tm_min);
  Serial.print(":");
  Serial.println(p_tm->tm_sec);

  cHour = (p_tm->tm_hour);
  cMin = (p_tm->tm_min);
  cSecond = (p_tm->tm_sec);
  cDay = (p_tm->tm_mday);
  cMonth = (p_tm->tm_mon + 1);
  cYear = (p_tm->tm_year + 1900);
  
  SUART.print("<Time,");
  SUART.print(" ");
  SUART.print(cHour);
  SUART.print(",");
  SUART.print(" ");
  SUART.print(cMin);
  SUART.print(",");
  SUART.print(" ");
  SUART.print(cSecond);
  SUART.print(",");
  SUART.print(" ");
  SUART.print(cMonth);
  SUART.print(",");
  SUART.print(" ");
  SUART.print(cDay);
  SUART.print(",");
  SUART.print(" ");
  SUART.print(cYear);
  SUART.print(">");
  
  delay(10000);

}

I guess I didn’t realize that millis() can get that far off that quickly. But for my project (a 16 zone sprinkler system controller) time being off a little would not be that crucial.

I certainly could add an RTC. My thought was having WiFi I wouldn’t need it. But at least if no internet, time could be kept more consistently. I’ll also be using Remotexy for control.
Then just use the NTP to keep things on track on boot and every so often?

I had read from someone that updates too often from NTP could lead to be blocked out. Their “terms of service” is kind of vague though. pool.ntp.org: the internet cluster of ntp servers

jhome:
My code I'm using on the 8266 has the Epoch time broken down already into the 6 above mentioned categories which is why I ended up sending those 6 variables.

IMO, that's doing it the hard way.

time_t now = time(nullptr);

The time() function returns Epoch Time. Why are you breaking it down to year, month, day, hour, etc before sending it over SoftwareSerial? It would be a lot easier to just send it as Epoch Time and then convert it (if that's even necessary) on the receive side.

I guess the best reason why I did it that way is because I don't have a lot of knowledge with this stuff. I've made a few things over the years which are still in use today, but if you looked at my code, you would probably be scratching your head!

I have no plans as of now of using anything but hours and minutes but I wanted to have the rest readily available if implemented later on.

The time() function returns Epoch Time. Why are you breaking it down to year, month, day, hour, etc before sending it over SoftwareSerial? It would be a lot easier to just send it as Epoch Time and then convert it (if that's even necessary) on the receive side.

Yes. Please provide the code on the Mega side of things. You are likely complicating things unnecessarily.

The RTClib library has millis() and micros() based software implementations of an RTC, which would allow you to write the code for the Mega as if there were a real RTC attached, and would allow you to transition to an actual RTC easily if desired. The micros() based RTC also lets you adjust for drift caused by the onboard oscillator being a bit off.