ESP32 - Wifi hotspots - and RTC modules

@zander 

You could improve on the date testing by saving the date and time into the onboard EEPROM every time a hall pass is issued. Presumably this would be a rare enough occurrence to avoid burning out the onboard EEPROM. However, it would provide a fairly strict lower limit for deciding if the RTC's supplied date is correct.

@will I am not concerned with the supplied date being 'correct', only concerned with if it is current. I am assuming (will test) that when the battery is changed the timer starts at 0 so any time less than about 5 minutes ago is really enough, but 2000-01-01 is handy since I think some of these RTC's reset the std unix 70 epoch to 2000. both ways work, but why risk the EEPROM if simple logic does the trick. 

The EEPROM is already available and it's free 🙂

@will FREE, Wills favourite word. All true, but so is simple logic. I don't care what way he chooses, both will work, one requires just 1 line of code, the other requires accessing another device. I believe in Occam's razor but it's not my decision so I don't care that much, just offering choices. Another popular method is to compare to the date/time of the module, the current time MUST be after the sketch was created. Again, free and sigma 5 accurate. I offer that as a compromise.

Here is where i have arrived after many failed experiments. i have basically got the same original non wifi sketch but with a chunk of currently commented out code because i cant think how to properly write the setup function where it checks the time and if it isnt X then runs the on demand config. 

This approach, whilst not currently functional i think takes on board what most folks have chipped in with. It has the most simple design where as some of my ideas where overly complex. 

So i will keep tinkering trying to work out how to write the if then else statement for the time and wifi and let you know if i have any luck. 

I am of course still very open to ideas, help and ways to improve. this includes tips on write neat, sensible code. mine is just pieces of cut and paste and messy attempts to bridge it all together.

#include "Adafruit_Thermal.h"
#include "SoftwareSerial.h"
#include "Wire.h"
#include "RTClib.h"
#include 
#define TX_PIN 1 // DFRobot GREEN WIRE labeled RX on printer
#define RX_PIN 2 // DFRobot YELLOW WIRE labeled TX on printer
#define btnPin1 4

int timeout = 120; // seconds to run for

SoftwareSerial mySerial(RX_PIN, TX_PIN); // Declare SoftwareSerial obj first
Adafruit_Thermal printer(&mySerial); // Pass addr to printer constructor

RTC_DS3231 rtc;

void setup() {
Serial.begin(115200);
pinMode(btnPin1, INPUT_PULLUP);
WiFi.mode(WIFI_STA); // explicitly set mode, esp defaults to STA+AP

Serial.println("\n Starting");
Serial.println("Checking Date/Time...");

//below i need to work out how to check the date on the RTC against a fixed reference.

// ??checkdatetime??( ) {
// if date is before 01/01/2022 then run config portal.
// Serial.println("Date incorrect. Running Config Portal.");

// below this line is the on demand config portal code from examples

// WiFiManager wm;
// wm.resetSettings();
// wm.setConfigPortalTimeout(timeout);
// if (!wm.startConfigPortal("OnDemandAP")) {
// Serial.println("failed to connect and hit timeout");
// delay(3000);
// reset and try again, or maybe put it to deep sleep
// ESP.restart();
// delay(5000);
// }
// if you get here you have connected to the WiFi
// Serial.println("connected...yeey :)");
// }
// else {
// Serial.println("Starting Out of Class Pass Machine.");
// }

mySerial.begin(9600);
Serial.println("Printer starting....");
printer.begin(); // Init printer (same regardless of serial type)
printer.println(F("------------------------------"));
printer.sleep(); // Tell printer to sleep
delay(3000L); // Sleep for 3 seconds
printer.wake(); // MUST wake() before printing again, even if reset
printer.setDefault(); // Restore printer to default

//rtc setup
if (! rtc.begin()) {
Serial.println("Couldn't find RTC");
}
//uncomment line below to set time to compile time. must upload, then recomment and reupload so time doesn't get reset every boot.
rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
Serial.println("Ending setup.");
Serial.println("Loop commencing.");
}

void loop() {
//time and printer stuff
//Serial.println("loop reached.");
DateTime now = rtc.now();
int Push_button_state = digitalRead(btnPin1);
if ( Push_button_state == LOW ){
//print to serial for debugging
Serial.println("Button pressed. Current time below");
Serial.print(now.year(), DEC);
Serial.print('/');
Serial.print(now.month(), DEC);
Serial.print('/');
Serial.print(now.day(), DEC);
Serial.print(now.hour(), DEC);
Serial.print(':');
Serial.print(now.minute(), DEC);
Serial.print(':');
Serial.print(now.second(), DEC);
Serial.println();
//print to printer
printer.println(F("------------------------------"));
printer.println(F(""));
printer.setSize('M');
printer.justify('C');
printer.println(F("OUT-OF-CLASS-PASS"));
printer.setSize('L');
printer.print(F("Date: "));
printer.print(now.day(), DEC);
printer.print("/");
printer.print(now.month(), DEC);
printer.println(F(""));
printer.setSize('M');
printer.println(F("This student has permission to"));
printer.println(F("leave the classroom."));
printer.justify('C');
char buffer [25];
uint8_t sec, min, hour;
sec = now.second();
min = now.minute();
hour = now.hour();
sprintf (buffer, "Left class at: %02u:%02u\n", hour, min);
printer.print (buffer);
printer.println(F("Pass valid for 5 minutes."));
printer.justify('L');
printer.println(F("Thank you,"));
printer.justify('C');
printer.doubleHeightOn();
printer.println(F(" MR. PATRICK "));
printer.println(F(""));
printer.doubleHeightOff();
printer.println(F(""));
printer.println(F("------------------------------"));
}
}

I'm off to make the missus a nice roast lamb lunch for mothers day, then after the following food coma i will try my luck again.

Thanks again everyone.

@zander 

I agree, but back on page 1 he said "It worked wonderfully, except when it didn't. The RTC would sometimes lose the time and start spewing out nonsense."

From that, I gathered that it wasn't a simple case of the RTC resetting (as from a power loss) to a known starting date but that the date and time went wild. Hence, if the RTC isn't reliable (and especially if it's not reliably unreliable by resetting to a random date and time) then some test of rational date and time might be required. Furthermore, he claimed that the time was "something that i know may well break regularly".

For these reasons,I assumed that it required continuous checks for reasonable date and time values.

As far as I can remember, there have been no specifics about the exact nature of the RTC failures, so we don't know how often nor how randomly the time function broke down.

Posted by: @ajpatrick  

I'm off to make the missus a nice roast lamb lunch for mothers day, then after the following food coma i will try my luck again.

Enjoy your postprandial dip:)

Posted by: @will

@zander 

I agree, but back on page 1 he said "It worked wonderfully, except when it didn't. The RTC would sometimes lose the time and start spewing out nonsense."

From that, I gathered that it wasn't a simple case of the RTC resetting (as from a power loss) to a known starting date but that the date and time went wild. Hence, if the RTC isn't reliable (and especially if it's not reliably unreliable by resetting to a random date and time) then some test of rational date and time might be required. Furthermore, he claimed that the time was "something that i know may well break regularly".

For these reasons,I assumed that it required continuous checks for reasonable date and time values.

As far as I can remember, there have been no specifics about the exact nature of the RTC failures, so we don't know how often nor how randomly the time function broke down.

@will Again, Occam's razor. IF/WHEN the RTC is PROVEN to be flaky then you can fix it.

@will I will bet a lot that the RTC is rock solid. They are used in millions of devices around the world. It is far more likely the code walked on memory and he interpreted it as an RTC failure. 

I am not feeling well, but here is a couple things worth lookin at. Then figure out how to get the unix time and compare it to whatever 2022-01-01 works out to be, it's #of seconds since 1970-01-01.

@ajpatrick I just googled 'what is todays date in unix time. That took me to a site were I could enter any date/time to get the unix timestamp. Here is the result for 2022-01-01_00-00-00. 

CODE

const uint32_t MagicDate = 1641024000;  // 2022-01-01 00/00/00 in unixtime units

  // start the rtc (see other code snippets for details)

  // there might be ways of checking bools for no power etc

  DateTime now = rtc.now();

  if (now.unix > MagicDate){ // date now is good,, nothing to do

  }

  else{

     // reinit the rtc by firing up WiFiMgr to connect to router then get ntp server date time

   }

}  // end of setup 

I haven't coded C or almost any language since about 2000 so hopefully @will, @inq, @frogandtoad will jump in and correct any of my errors.

@zander FYI @ajpatrick

I would suggest changing the if part to ...

if ( ! (now.unix > MagicDate) ) { // date now precedes MagicDate

     // reinit the rtc by firing up WiFiMgr to connect to router then get ntp server date time

}

This tests the only case in which some action is required and then performs the action.

@will I like to avoid negative logic when dealing with newbies, I find it often confuses them. 

@zander FYI @ajpatrick

Ask and ye shall receive ...

if ( MagicDate>now.unix ) { // date now precedes MagicDate

     // reinit the rtc by firing up WiFiMgr to connect to router then get ntp server date time

}

@will I like that one even better, man I am rusty. I also have a minor error, the magic date is local, for GMT the number is

 but either one is a perfectly good reasonableness check. This should also work if before 2038 when the seconds run out they opt for epoch 2000 instead of uint64_t. It is unclear to me how that conversion will be managed, but it makes Y2K look like a nothing burger. There are literally millions of embedded devices with clocks that will fail in another 16 years or so. At least I won't have to be on that team.