// the library you will need --
// https://github.com/arduino-libraries/NTPClient
//
// NodeMCU NodeMCU NodeMCU NodeMCU
#include <NTPClient.h>
#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
const char *ssid = "";
const char *password = "";
const long utcOffsetInSeconds = -25200; // more or less vs. YOUR TIMEZONE
char daysOfTheWeek[7][12] = {"SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT"};
int hh;
int mm;
int ss;
int comparisonsecs = 55; // to closer sync actual NTP change
// Define NTP Client to get time
WiFiUDP ntpUDP;
NTPClient timeClient(ntpUDP, "pool.ntp.org", utcOffsetInSeconds);
//SoftwareSerial playerSerial (D5,D6);
void setup()
{
WiFi.begin(ssid, password);
delay(2000);
Serial.begin(115200); // not essential, OMIT when Ready
timeClient.begin();
}
void loop()
{
timeClient.update();
Serial.print(hh);
Serial.print(" ");
Serial.print(mm);
Serial.print(" ");
Serial.println(ss);
if(hh == 18 && mm == 30 && ss == 00) // 6:30 PM
{
// turn on the light
// do your pinMode in SETUP()
// do your digitalWrite here
Serial.println("Turned ON");
}
if(hh == 21 && mm == 00 && ss == 00) // 9:00 PM
{
// turn off the light
Serial.println("Turned OFF");
}
}
I don't understand why testing should take days with my current code
Haha, I just mean to see if it turns on and off correctly takes a day. Finding little flaws one by one will take days. So I might make a test to see if it turned on from 0:30 seconds to 0:45 seconds, just stuff the seconds into miutesSince00.
Then worry about making that do something at an hour and minute, setting it like it seems you are doing, like for 5 minutes from now. Or if you are fast enough, 3 minutes… life is short.
Then… a full up 24 hour test. Using a range as I suggest means you can next test the response to a power failure, during and not during the on interval. You may see the point of using a range.
Testing for hh:mm:so exactly is only more problematic. If you aren't there to see it, you don't get to react.
@McGregz I can't offer anything other than to make sure you are doing the modifications correctly and
to liberally dose your code with Serial.pritn() statements to check the values of keys variables and confirm the flow that they inform.
I like functions as much as the next person, but here you have two identical calls to numMins()… or are they?, and two calls that are actually constants.
If you have to use a function, call it once to establish the current time in minutes when you need to, and call it in setup() to fix values for constants ON_MINUTES and OFF_MINUTES or whatever.
I think it's clearer just to say 60 * H + M right when if you need to calculate that. And do the constants as global const variables.
Thanks @anon85221860 this doesn't seem to work, i've added the library and uploaded code exactly but with relevant time, ssid and pw but the serial monitor is just 0 0 0 and there's no light.
I'd figure you're not getting network. Mine gets in with network and all expeditiously, so I didn't include any waiting about for that to come round. Maybe your situation is different. This version of setup() allows for a network where things don't go so fast --
Hey yeah it defo had been taking a while before. Weird thing is that it wont connect to the normal wifi now but if i tether my phone it does the 000 thing but the serial monitor is spewing out the reading in milliseconds
No. If it is okey that On is done "several" times during 30 minutes, and the same for turning Off.
As other helpers suggest, check the connection with the network. Adding a temporary
Serial.print(" Time read from NET. ");Serial.println(millis();
in loop could tell the condition of the connection.
A RTC is last century. It doesn't do daylight savings, so it's wrong half of the year.
Experimenting with something similar, but using a tzapu WiFiManager configuration portal, which has NTP code built-in. Some lines of code (I live in New Zealand). Not ready to share my full code yet.
Daylight savings varies. Some don't, some do what they chose, even state to state here there is no standard. I'd expect to have to correct for that because humans need correcting for.
If Dallas Semiconductor has a newer, better RTC I think that not needing wifi once initialized and kept powered (has long life battery) to tick away.
That D1 board must have a crystal, same as an RTC. The Uno has a resonator instead of a crystal, can drift like 3 and a half minutes a day where a crystal you measure tiny drift over a month. The D1 can do the job if it has the code and nothing blocks it which is why I present an RTC as an alternate path.
It has a starting point with an On time and an Off time, pretty easy to understand.
And I demo'd that it works.
All in all, a lot more than anybody else has done.