Can't get past 'strftime' time formatting on new and old units?

[mtrcycllvr]

First, AWESOME software, thank you!

last fall I assembled a standard ESP32/Waveshare 4.2" epaper display running on solar cell/battery - worked very well..

Just now, I tried to code up a new Waveshare ePaper ESP32 module (builtin PFC24 connector) and found no display output after installing the code.. I tested various demo code - display functions work, but I can't get weather code to run - stops at "WiFi connected at: ...".... I hacked the code for hours - I'm not very good at this. I also ran several isolated NTP examples that work to the serial port.. After a few delays and prints, I find what SEEMS to be happening it this: (subset of UpdateLocalTime() function..)

else { Serial.println("_format dayoutput variable.."); delay(2000); strftime(day_output, sizeof(day_output), "%a %b-%d-%Y", &timeinfo); // Creates 'Sat May-31-2019' <---- THIS!!!! Serial.println("format time_output variable.."); delay(2000); strftime(update_time, sizeof(update_time), "%r", &timeinfo); // Creates: '@ 02:05:49pm' delay(2000); sprintf(time_output, "%s", update_time); }

Results in this:

entering UpdateLocalTime()... stucts and chars set, use getlocalTime() now.... Sunday, January 00 1900 00:-1287651329:00 Got time!! Wednesday, January 05 2022 23:21:08 set varial CurrentHour.. set varial CurrentMin.. set varial CurrentSec.. Format time data.. _format dayoutput variable.. fo

(upside down question marks for a while....)

So I went to get the "one that works only to discover - it no longer works! Same symptoms, though I didn't update the code base.. But it simply stops after the network signon.. The last display update was BEFORE jan 1 2022... I'm sure no bearing, but??

I'm pretty sure the code it choking at the same point - trying to format the time/date data contained in the "timeinfo" struct.

Did the year change screw with strftime somehow? I'm not smart enough to get past this at this point... I'm HOPING that this isn't an RTFM issue... I tired changing over to Metric units thinking an alternative format might be at issue, but that doesn't seem to fix things..

So, two different ESP32's, that can both run basic display and NTP tests, but suddenly won't work with your weather code?

I hate pestering you for such basic stuff - but not clear where else I might turn..

Arduino 1.8.13, updated libraries and boards as far as I can tell.. If there's anything else I can provide in terms of information?

Thank you!

[G6EJD]

Hi Eric,

Can you tell me the exact code your using. There have been some significant changes in the IDE now 1.8.16 and the ESP32 compiler so these may account for the errors your seeing, I will have a look today at the time functions which I believe are working correctly.

Regards

David

On 6 Jan 2022, at 08:09, Eric Timberlake @.***> wrote:

 First, AWESOME software, thank you!

last fall I assembled a standard ESP32/Waveshare 4.2" epaper display running on solar cell/battery - worked very well..

Just now, I tried to code up a new Waveshare ePaper ESP32 module (builtin PFC24 connector) and found no display output after installing the code.. I tested various demo code - display functions work, but I can't get weather code to run - stops at "WiFi connected at: ...".... I hacked the code for hours - I'm not very good at this. I also ran several isolated NTP examples that work to the serial port.. After a few delays and prints, I find what SEEMS to be happening it this: (subset of UpdateLocalTime() function..)

else { Serial.println("format day_output variable.."); delay(2000); strftime(day_output, sizeof(day_output), "%a %b-%d-%Y", &timeinfo); // Creates 'Sat May-31-2019' <---- THIS!!!! Serial.println("format time_output variable.."); delay(2000); strftime(update_time, sizeof(update_time), "%r", &timeinfo); // Creates: '@ 02:05:49pm' delay(2000); sprintf(time_output, "%s", update_time); }

Results in this:

entering UpdateLocalTime()... stucts and chars set, use getlocalTime() now.... Sunday, January 00 1900 00:-1287651329:00 Got time!! Wednesday, January 05 2022 23:21:08 set varial CurrentHour.. set varial CurrentMin.. set varial CurrentSec.. Format time data.. format day_output variable.. fo

(upside down question marks for a while....)

So I went to get the "one that works only to discover - it no longer works! Same symptoms, though I didn't update the code base.. But it simply stops after the network signon.. The last display update was BEFORE jan 1 2022... I'm sure no bearing, but??

I'm pretty sure the code it choking at the same point - trying to format the time/date data contained in the "timeinfo" struct.

Did the year change screw with strftime somehow? I'm not smart enough to get past this at this point... I'm HOPING that this isn't an RTFM issue... I tired changing over to Metric units thinking an alternative format might be at issue, but that doesn't seem to fix things..

So, two different ESP32's, that can both run basic display and NTP tests, but suddenly won't work with your weather code?

I hate pestering you for such basic stuff - but not clear where else I might turn..

Arduino 1.8.13, updated libraries and boards as far as I can tell.. If there's anything else I can provide in terms of information?

Thank you!

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[mtrcycllvr]

Hi David!

I'm using:

//################ VERSION ########################## String version = "12.5"; // Version of this program //################ VARIABLES ###########################

...of the "waveshare_4_2" example - which as noted, worked about a month ago on a standard ESP32..

My methodology has been crude at best - just following the code and inserting "Serial.println..." at various steps so I could determine where it was getting hung up - it appears to get the time okay, but wedges at or around the strftime statements in the updatelocalTime() routine..

Again, thanks so much for your thoughts!!

Sincerely,

Eric

[G6EJD]

And your time zone format string as I’m not seeing any issues.

[mtrcycllvr]

Hi!

I used this timezone string: const char* Timezone = "PST8PDT,M3.2.0,M11.1.0";

I ALSO used this exact time zone sting for the separate NTP test and that correctly works. It ALSO worked from late november till just recently on the "standard" ESP that has stopped working - I have not re-flashed that..

Also, as I added "Serial.println" I also added print date stings statements, and this output I got from modified debug code - ei; echo variables, state what line of code we're on.. It represents sytem time before and after applying the timezone using tzset().. The time is correct at the time for my time zone, and the print statements say that part of the code is working. ex: (before tzset, query server, then after tzset) Sunday, January 00 1900 00:-1287651329:00 Got time!! Wednesday, January 05 2022 23:21:08

[mtrcycllvr]

My bad.. I can't get past this:

void InitialiseDisplay() { Serial.println("confirm we got here at InitiliseDisplay()..."); delay(2000); Serial.println("run display.init..."); delay(2000); display.init(115200, true, 2, false); // display.init(); for older Waveshare HAT's Serial.println("turn off SPI..."); delay(2000); SPI.end(); Serial.println("turn on SPI using waveshare pins..."); delay(2000); SPI.begin(EPD_SCK, EPD_MISO, EPD_MOSI, EPD_CS); u8g2Fonts.begin(display); // connect u8g2 procedures to Adafruit GFX ...

Hangs at:

display.init(115200, true, 2, false);

Never outputs the Serial.println("turn off SPI..."); directly afterwards..

Sigh.. I apologize - I was trusting serial.print to work no matter what - that's what lead to the delays after the prints and further refinement of where the code seems to be getting hung up..

[G6EJD]

Yes, this makes sense as there is nothing wrong with the timezone calculations, the GxEPD2 library has recently been updated around the device initialisation try display.init(115200);

[mtrcycllvr]

OMG.. CLOSED - totally my tool chain somehow.. Went to separate computer, updated libraries, recompiled, uploaded and it works as I expect.. Should have done that FIRST - I'm VERY SORRY!

Thanks for your prompts suggestions..

The one thing I can note is I'm kind of sorry I went with the waveshare ePaper ESP32 - while the display WORKS, it seems somehow dimmer than the version with a builtin 5v levelshifter.. It's bright white right at refresh, but after the data is displayed it's like the background is on 10% grey? Anyway, it works, I seriously appreciate your time and effort and the weather display is just awesome, thank you!! (I re-flashed the everyday ESP32 and buffered 4.2 inch display, it is also now working and the display is sharp and bright - love epaper!)

[G6EJD]

Good to hear it’s working. Early Waveshare displays weren’t buffered, they all are now and so work reliably there are a few initialisation issues as they changed the reset circuit to suit the RPi which then messed up microcontroller operations.