Giter Club home page Giter Club logo

ntp's People

Contributors

fkollmann avatar morres83 avatar redoxcode avatar sstaub avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

ntp's Issues

DST syntax question

Thank you for your library, it's awesome.

We have recently changed to DST however my time did not change. Can you please review my settings and identify my mistake. The time should have gone forward by 1 hour at 3am on 29/9/2019. I'm assuming that the daily time update happened correctly as it normally does.

NTPServer.ntpServer(NTPServerName);
NTPServer.updateInterval(NTPRefreshTime);
NTPServer.ruleSTD("NZST", First, Sun, Apr, 2, 12 * 60);
// first sunday in April at 3:00, timezone 12 hours
NTPServer.ruleDST("NZDT", Last, Sun, Sep, 3, 12 * 60 + 60);
// last sunday in September at 3:00, timezone 13 hours
NTPServer.begin();

Thanks

Would it be possible to have update() return true by default?

Right now, update() checks the time interval and, if it's too soon, it returns false. If it's time to sync with an NTP server, it returns the success of that action. Returning false for the "too soon" case makes it impossible to distinguish the case of "too soon" from the case of a server sync failure. Would it be possible to have update() return true in the case where it's too soon?

If all else fails, the 3 cases we care about

  1. Too soon
  2. Sync succeeded
    3 Sync failed

could be handled with an ENUM with the values set to maintain backward compatibility.

Thanks for listening.

epoch() returns UTC time

The epoch() method returns the UTC time. If this is the desired result (but then, what is the use of the utc() method?), Would it be possible to add a local() method to return the value of the local variable?

Feature request: Get_UTC and get_localtime

Thanks for this great lib!
I do not know if this is a good feature request, because the requested functionality is a (bit) more then this lib is probably ought to do. But it would be great. 😄

Adding two functions would be great; I like to set my RTC to epoch and sometimes I need to display the localtime. As far as I know, in the ESP 8266 Arduino code there's not yet a working solution for converting between time zone.

So maybe you could add the function ntp.localtime(), which would display the the time of the ntp object, but if you put in it another the epoch or a timestamp ntp.localtime(epoch) it would just convert the given time into the "local" epoch (with timezone and DST).

ntp.gmttime() could result in the actual epoch without any timezone information and DSTs.
and ntp.gmttime(epoch) would convert the epoch back to UTC/GMT time, based on the DST information stored in the object.

Problems: Nesting will result in wrong times ntp.gmttime(ntp.gmttime(epoch))

It would also be possible to have different ntp objects:
ntp
ntp_ger
ntp_us
which could hold different time zone.

But maybe this is "too much" for this library. Just my two cents.

Thank you very much!

Stop NTP change time zone and restart

I have an application where using a web page I want to change time zone. I've tried this but it crashes and causes a reboot. Is there a better way?

 ntp.stop();

ntp.ruleDST("MDT", Second, Sun, Mar, 2, -360);
ntp.ruleSTD("MST", First, Sun, Nov, 2, -420);
ntp.begin();

Time shift after udp->flush is removed

The flush at the start of ntpUpdate() is mandatory to keep the NTP server in sync after an UDP timeout.
If you leave out the flush sometimes suddenly an exact NTP::updateInterval timeshift will happen.

The code I use to fix this was:

bool NTP::ntpUpdate() {
// flush any existing pending input packets
while(udp->parsePacket() != 0) udp->flush();
if (server == nullptr) udp->beginPacket(serverIP, NTP_PORT);
else udp->beginPacket(server, NTP_PORT);

Gives random time or one hour behind

Hi,
I was not sucessful to get this lib running with currect time and I ran into two different issues:

  1. first day time is correct but at midnight it goes back one hour and stays there forever (time+date is exact but one hour behind). I have this behaviour if I ask once a minute (via serial ) for time (ntp.update() + ntp.hours(),...). This is part of a huge clock project so it is difficult to debug.

  2. So I thought just to debug it via web interface:

ntp.update(); s+=ntp.formattedTime("%Y-%m-%d %H:%M:%S");

In this scenario update does not run once a second or minute just a few time I reload page. Result: more or less random time (e.g. 30 years ahead, totally wrong time of day).

You can find full source code here: https://github.com/flyingdogsoftware/Tower-Clock-Wifi/blob/master/src/main.cpp

Thank you!

Compile error: 'NTP' does not name a type

I'm having trouble figuring this one out ...

I'm writing something on a Raspberry Pi Pico W. I've just started out and when I tried adding in the NTP code I get this compile error but it isn't making any sense to me.

My code:

#include <ArduinoLog.h>

#include <WiFi.h>
// #include <WiFiClient.h>
// #include <WiFiServer.h>
#include <WiFiUdp.h>

#include "NTP.h"

const char* ssid = "myssid";
const char* wifiPassword = "mypassword";

WiFiUDP wifiUdp;

NTP npt(wifiUdp);

void setup() {
  delay(1000);

  Serial.begin(9600);
  if (!Serial) {
    delay(500);
  }

  Log.begin(LOG_LEVEL_VERBOSE, &Serial);

  Log.infoln("Starting...");

  WiFi.begin(ssid, wifiPassword);
  while (WiFi.status() != WL_CONNECTED) {
    Serial.println("Connecting ...");
    delay(500);
  }
  Serial.println("Connected");

  ntp.ruleDST("EDT", Second, Sun, Mar, 2, -240);  // second sunday in march 2:00, timetone -240min (-5 GMT + 1h summertime offset)
  ntp.ruleSTD("EST", First, Sun, Nov, 2, -300);   // first sunday in november 2:00, timezone -300min (-5 GMT)
  ntp.begin();
  Serial.println("start NTP");
}

void loop() {
  delay(1000);
  ntp.update();
  Log.infoln("Tick... %s", ntp->formattedTime());
}

Throws the error:

/Users/xxx/Documents/Arduino/Layer_Clock_NTP/Layer_Clock_NTP.ino:15:1: error: 'NTP' does not name a type
   15 | NTP npt(wifiUdp);
      | ^~~

Any idea what's the error? Hovering over the "NTP" shows "class NTP" so it looks like the IDE has the idea but the compiler doesn't.

Usage with WiFi or Ethernet

First of all thank you for this really (!) good libary. I'd like to propose an enhancement:
Is it possible to move the definition of the UDP "Connector" (instance of EthernetUDP or WiFiUDP) away from the constructor to the init() or begin() method? I'd like to check before, if an internet connection is possible via wifi or Ethernet (cable).
I tried several ways to accomplish this with Release 1.6 from PlatformIO registry. But I didn't get the clue.
Thanks
Matthias

Bug in NTP::ntpUpdate() ?

In the code below the string "udp->flush();" IMHO is not needed. In fact it sends empty malformed packet before the packet with real NTP query will be issued.

bool NTP::ntpUpdate() {
udp->flush();
if (server == nullptr) udp->beginPacket(serverIP, NTP_PORT);
else udp->beginPacket(server, NTP_PORT);
udp->write(ntpRequest, NTP_PACKET_SIZE);

]~> tcpdump -n -p -i eth0 udp port 123
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

17:22:13.514331 IP 192.168.0.2.123 > 192.168.0.10.123: [|ntp]
17:22:13.515070 IP 192.168.0.2.123 > 192.168.0.10.123: NTPv4, Client, length 48
17:22:13.515131 IP 192.168.0.10.123 > 192.168.0.2.123: NTPv4, Server, length 48

Incorrect DST handling for southern hemisphere?

DST for southern hemisphere timezones does not seem to work correctly.
NTP::summerTime() assumes that utcDST<utcSTD, and NTP::beginDST() assumes both utcDST & utcSTD apply to current->tm_year. Then it follows that NTP::summerTime() always returns false for the southern hemisphere.

System loses time with each update

I'm having a very bizarre issue with your library. I have added it to an ESP8266-based weather display (written by someone else) to maintain the displayed time. The problem I have is that when I call update() and it decides to get a packet from the NTP server, the time in the packet is a few minutes earlier than the current time. As a result, the system continues to lose a few minutes on every update.

I have added code to print the result of minutes and seconds around an update and I see this:

NTP - E3FA49E3  604FCB63
02:27 02:28 02:29 02:30 02:31 02:32 02:33 02:34 02:35 02:36 02:37 02:38 02:39 02:40 02:41 02:42 02:43 02:44 02:45 02:46 02:47 02:48 02:49 02:50 02:51 02:52 02:53 02:54 02:55 02:56 02:57 02:58 02:59 03:00 03:01 03:02 03:03 03:04 03:05 03:06 03:07 03:08 03:09 03:10 03:11 03:12 03:13 03:14 03:15 03:16 03:17 03:18 03:19 03:20 03:21 03:22 03:23 03:24 03:25 03:26 03:27 03:28 03:29 03:30 03:31 03:32 03:33 03:34 03:35 03:36 03:37 03:38 03:39 03:40 03:41 03:42 03:43 03:44 03:45 03:46 03:47 03:48 03:49 03:50 03:51 03:52 03:53 03:54 03:55 03:56 03:57 03:58 03:59 04:00 04:01 04:02 04:03 04:04 04:05 04:06 04:07 04:08 04:09 04:10 04:11 04:12 04:13 04:14 04:15 04:16 04:17 04:18 04:19 04:20 04:21 04:22 04:23 04:24 04:25 04:26 04:27 04:28 04:29 04:30 04:31 04:32 04:33 04:34 04:35 04:36 04:37 04:38 04:39 04:40 04:41 04:42 04:43 04:44 04:45 04:46 04:47 04:48 04:49 04:50 04:51 04:52 04:53 04:54 04:55 04:56 04:57 04:58 04:59 05:00 05:01 05:02 05:03 05:04 05:05 05:06 05:07 05:08 05:09 05:10 05:11 05:12 05:13 05:14 05:15 05:16 05:17 05:18 05:19 05:20 05:21 05:22 05:23 05:24 05:25 05:26 05:27 05:28 05:29 05:30 05:31 05:32 05:33 05:34 05:35 05:36 05:37 05:38 05:39 05:40 05:41 05:42 05:43 05:44 05:45 05:46 05:47 05:48 05:49 05:50 05:51 05:52 05:53 05:54 05:55 05:56 05:57 05:58 05:59 06:00 06:01 06:02 06:03 06:04 06:05 06:06 06:07 06:08 06:09 06:10 06:11 06:12 06:13 06:14 06:15 06:16 06:17 06:18 06:19 06:20 06:21 06:22 06:23 06:24 06:25 06:26 06:27 06:28 06:29 06:30 06:31 06:32 06:33 06:34 06:35 06:36 06:37 06:38 06:39 06:40 06:41 06:42 06:43 06:44 06:45 06:46 06:47 06:48 06:49 06:50 06:51 06:52 06:53 06:54 06:55 06:56 06:57 06:58 06:59 07:00 07:01 07:02 07:03 07:04 07:05 07:06 07:07 07:08 07:09 07:10 07:11 07:12 07:13 07:14 07:15 07:16 07:17 07:18 07:19 07:20 07:21 07:22 07:23 07:24 07:25 07:26 07:27 07:28 07:29 07:30 07:31 07:32 07:33 07:34 07:35 07:36 07:37 07:38 07:39 07:40 07:41 07:42 07:43 07:44 07:45 07:46 07:47 07:48 07:49 07:50 07:51 07:52 07:53 07:54 07:55 07:56 07:57 07:58 07:59 08:00 08:01 08:02 08:03 08:04 08:05 08:06 08:07 08:08 08:09 08:10 08:11 08:12 08:13 08:14 08:15 08:16 08:17 08:18 08:19 08:20 08:21 08:22 08:23 08:24 08:25 08:26 
NTP - E3FA4A25  604FCBA5
03:33 03:34 03:35 03:36 03:37 03:38 03:39 03:40 03:41 03:42 03:43 03:44 03:45 03:46 03:47 03:48 03:49 03:50 03:51 03:52 03:53 03:54 03:55 03:56 03:57 03:58 03:59 04:00 04:01 04:02 04:03 04:04 04:05 04:06 04:07 04:08 04:09 04:10 04:11 04:12 04:13 04:14 04:15 04:16 04:17 04:18 04:19 04:20 04:21 04:22 04:23 04:24 04:25 04:26 04:27 04:28 04:29 04:30 04:31 04:32 04:33 04:34 04:35 04:36 04:37 04:38 04:39 04:40 04:41 04:42 04:43 04:44 04:45 04:46 04:47 04:48 04:49 04:50 04:51 04:52 04:53 04:54 04:55 04:56 04:57 04:58 04:59 05:00 05:01 05:02 05:03 05:04 05:05 05:06 05:07 05:08 05:09 05:10 05:11 05:12 05:13 05:14 05:15 05:16 05:17 05:18 05:19 05:20 05:21 05:22 05:23 05:24 05:25 05:26 05:27 05:28 05:29 05:30 05:31 05:32 05:33 05:34 05:35 05:36 05:37 05:38 05:39 05:40 05:41 05:42 05:43 05:44 05:45 05:46 05:47 05:48 05:49 05:50 05:51 05:52 05:53 05:54 05:55 05:56 05:57 05:58 05:59 06:00 06:01 06:02 06:03 06:04 06:05 06:06 06:07 06:08 06:09 06:10 06:11 06:12 06:13 06:14 06:15 06:16 06:17 06:18 06:19 06:20 06:21 06:22 06:23 06:24 06:25 06:26 06:27 06:28 06:29 06:30 06:31 06:32 06:33 06:34 06:35 06:36 06:37 06:38 06:39 06:40 06:41 06:42 06:43 06:44 06:45 06:46 06:47 06:48 06:49 06:50 06:51 06:52 06:53 06:54 06:55 06:56 06:57 06:58 06:59 07:00 07:01 07:02 07:03 07:04 07:05 07:06 07:07 07:08 07:09 07:10 07:11 07:12 07:13 07:14 07:15 07:16 07:17 07:18 07:19 07:20 07:21 07:22 07:23 07:24 07:25 07:26 07:27 07:28 07:29 07:30 07:31 07:32 07:33 07:34 07:35 07:36 07:37 07:38 07:39 07:40 07:41 07:42 07:43 07:44 07:45 07:46 07:47 07:48 07:49 07:50 07:51 07:52 07:53 07:54 07:55 07:56 07:57 07:58 07:59 08:00 08:01 08:02 08:03 08:04 08:05 08:06 08:07 08:08 08:09 08:10 08:11 08:12 08:13 08:14 08:15 08:16 08:17 08:18 08:19 08:20 08:21 08:22 08:23 08:24 08:25 08:26 08:27 08:28 08:29 08:30 08:31 08:32 08:33 08:34 08:35 08:36 08:37 08:38 08:39 08:40 08:41 08:42 08:43 08:44 08:45 08:46 08:47 08:48 08:49 08:50 08:51 08:52 08:53 08:54 08:55 08:56 08:57 08:58 08:59 09:00 09:01 09:02 09:03 09:04 09:05 09:06 09:07 09:08 09:09 09:10 09:11 09:12 09:13 09:14 09:15 09:16 09:17 09:18 09:19 09:20 09:21 09:22 09:23 09:24 09:25 09:26 09:27 09:28 09:29 09:30 09:31 09:32 
NTP - E3FA4A66  604FCBE6
04:38 04:39 04:40 04:41 04:42

The lines that begin with "NTP - " show the hexadecimal values of ntpTime and utcTime respectively. The other data in the printout show the current values of minutes() and seconds() as they march along. The update interval is 6 minutes.
In the first interval, the ntpTime is 0xE3FA49E3 and that corresponds to a minutes:seconds value of 02:27. 6 minutes later an update occurs and the new ntpTime is 0xE3FA4A25. Six minutes have passed but the difference between the first packet's time and the second packet's time is only 0x42 or 66 seconds. Note that the seconds:minutes value goes from 08:26 before the update to 03:33 after the update. I've lost about 5 minutes.

Clearly, I'm doing something wrong here but I can't figure out what it is. I tried using wireshark to observe the UDP packets but I didn't have any luck. Do I need to do that to make progress on this issue? I'm hoping that you've seen this kind of problem before and you have a quick fix.

Thanks.

library fails to compile

Hi,
I'm probably using this wrong but for me the library fails to compile with the error:

*** [.pioenvs/nodemcuv2/src/main.cpp.o] Error 1
In file included from .piolibdeps/NTP_ID5438/NTP.cpp:23:0:
.piolibdeps/NTP_ID5438/NTP.h:46:12: error: expected ')' before '&' token 
NTP(UDP& udp);
^

It also raises an error: src/main.cpp:10:18: fatal error: WiFi.h: No such file or directory
But I assumed that was ok since I have ESP8266WiFi.h
Is WiFi.h part of some dependency that I need to install?

I'm on PlatformIO version 3.6.0a3 on up-to-date archlinux x86_64 machine

Unable to retrieve hours in 24h format

I tried:

ntp.hours() - gives 1 for 1pm
ntp.formattedTime("%I") - gives 1 for 1pm
ntp.formattedTime("%H") - gives 1 for 1pm

At least for the %H I was expecting to get 13 instead of 1. What do I have to do in order to get the current hour in 24h format? Or is there a function to retrieve the am/pm value?

epoch() does not return updated time

The inline function epoch() returns utcCurrent.
utcCurrent is not updated if not any method calls private method currentTime() previously.
Consequently, in this case, epoch() will always return the value of the first sync (because ntp.begin() calls currentTime() once).

.update() liefert niemals true

Hallo Stefan,

habe Deine NTP-Bibliothek in mein Projekt eingebunden. Danke für Deine Arbeit und die Veröffentlichung. Leider bekomme ich von der Methode .update() niemals true zurück.

Definitionen im Kopf des Sketch:

#include "NTP.h"
#include "WiFiUdp.h"
WiFiUDP wifiUdp;
NTP timeClient(wifiUdp);
String letztesNTPUpdate;
boolean erfolgLetztesNTPUpdate;

Im setup() habe ich diesen Code:

timeClient.ruleDST("CEST", Last, Sun, Mar, 2, 120); // last sunday in march 2:00, timetone +120min (+1 GMT + 1h summertime offset)
timeClient.ruleSTD("CET", Last, Sun, Oct, 3, 60); // last sunday in october 3:00, timezone +60min (+1 GMT)
timeClient.updateInterval(1000 * 60 * 30); // Update alle 30 Minuten
timeClient.begin("10.0.0.1"); // Router im LAN stellt NTP bereit
erfolgLetztesNTPUpdate = timeClient.update(); 
letztesNTPUpdate = tc.formattedTime("%H:%M:%S");

Im loop() dieses:

erfolgLetztesNTPUpdate = timeClient.update();
if (erfolgLetztesNTPUpdate) {
  letztesNTPUpdate = tc.formattedTime("%H:%M:%S");
}

Den Inhalt der Variable letztesNTPUpdate lasse ich mir dann auf einer generierten HTML-Seite vom Webserver, der auf dem ESP läuft anzeigen. Doch auch nach nun einigen Stunden bleibt der Inhalt der Variable letztesNTPUpdate auf dem Stand beim Start des ESP. Anscheinend erhalte ich nie true von .update() zurück. Die gesetzte Uhrzeit im timeClient ist aber korrekt und stimmt +-1 Sekunde mit der "richtigen" Zeit überein.

Wo mache ich einen Fehler?

Grüße

Frank

1.7 Version is not on PlatformIO

I don't know why and how it works, but your lasted version is no updated in Platformio, and it's a pity. There, the lastest is 1.6. How can we solve that?

Using local port of 123 for UDP listening

Using Ethernet.h and NTP.h with an Arduino Uno R3 and an Ethernet Shield R3.

NTP client won't receive responses from remote NTP server when local/source UDP port is 123.

Changing line 54 to use a different local/source UDP port allows it to function.

NTP/NTP.cpp

Line 54 in 564a820

udp->begin(NTP_PORT);

Original, doesn't work with my hardware configuration:

	udp->begin(NTP_PORT);

Changed, works with my hardware configuration:

	udp->begin(8888);

Could we possibly create a mechanism to allow local modification of this local/source UDP port?

Example sketches available upon request.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.