ESP8266 Community Forum

- Thu Jan 28, 2016 2:31 am #39857 Hi all,

I've spent a number of days trying to get a simple NTP update sketch working. I'm a bit new to most of this, but I'm struggling with finding libraries that work with the various examples that one finds laying around. Currently, there are probably at least 6 different libraries for the ESP8266 boards and they all "digress" into their own special methods of utilizing the features of the chip. (adafruit, sparkfun, extrand, igrr, etc...) This sort of reminds me of the general chaos which mostly turns me off about gnu linux. The work from Igrr seems to be most complete, but has references to header files which don't seem to be part of the base IDE installation (queue.h, memory.h, iirc).

Basically I'd be happy if I could get anything with UDP running right now just to see if I'm getting closer. I have avoided the messiness of the AT commands in hope that the libraries already have functions for all of this, but I haven't yet found a way to see if I actually have a localport up and I have yet to see anything from the board going out over wi-fi using what I currently have for an ntp sketch (point was to set time on a DS3231). I'm just using a Leonardo board and Sparkfun's ESP8266 shield. The webserver examples worked fine and I could poll temperatures, etc over TCP + HTTP. Wi-fi setup seems to work ok, but again, Sparkfun's jist on functions deviates considerably from other libraries.

So, my questions are:
1. What is the "authoritive" source for ESP8266 libraries and where is it hosted?
2. Does anyone have a simple UDP "echo" sketch with references to which ESP8266 libraries (and to which WiFiUDP libraries, there seems to be far too many as well) are used?

Thanks in advance for any help
S.

- Fri Jan 29, 2016 1:19 am #39918 I don't think there's any authoritative library, but I like the Arduino IDE that supports the board (https://github.com/esp8266/Arduino). Coincidentally, it actually includes an NTP client example: https://github.com/esp8266/Arduino/blob ... Client.ino

- Fri Jan 29, 2016 4:31 am #39924

I don't think there's any authoritative library, but I like the Arduino IDE that supports the board (https://github.com/esp8266/Arduino). Coincidentally, it actually includes an NTP client example: https://github.com/esp8266/Arduino/blob ... Client.ino

I can recommend this solution, this example works "out of the box".

Output from today's test:

Code: Select allConnecting to MyRouter
.....
WiFi connected
IP address:
192.168.0.29
Starting UDP
Local port: 2390
sending NTP packet...
packet received, length=48
Seconds since Jan 1 1900 = 3663048762
Unix time = 1454059962
The UTC time is 9:32:42


- Fri Jan 29, 2016 3:12 pm #39959 Hi,

I wish I could say that I hadn't been down this road already. This is "igrr's" library work that I referred to earlier. It introduces conflicts between the IDE's (version 1.6.7) libaries and these libraries. Dropping these libaries into the the local user library path results in multiple compilation errors and basically kills all of my earlier sketches because igrr's WiFiUDP library introduces references to header files not in the base IDE (in addition to the name space polution of having multiple libraries of the same name). It would be nice to get these updates pushed out to be included in Arduino IDE releases, so that bugfixes and feature enhancements become part of the mainstream code base, instead of some random fork. As a hardware vendor, this approach has almost no disadvantages.

philosophy rant: If the Espressif people are interested in the wide spread use of their chips (which I like a lot conceptually), then having users with early-on success is just as important as cool IDE's. This also means that they should get vendors on board with one central code base and committer priv's instead of everyone re-inventing the wheel with just a little different color.

There also seem to be some pin inconsistencies on some esp8266 based shields. It would be nice if one could introduce some hardware based defines. The Sparkfun shield is documented as using pins 8 & 9 as software serial ports. Some example sketches use other pins, to some extent unsupported baud rates, unknown firmware version dependencies, etc. There are lots of assumptions in a lot of sketches that make for a lot of broken examples that don't just "work out of the box", unfortunately. This example is unfortunately one of them because of the breakage in WiFiUdp.