Not satisfied with the handheld remote control for his outdoor patio lights, [timabram] decided to build an automatic timer using an ESP8266. He’s using a set of string lights from Costco, but as you dig into his project you’ll see the method he uses can be applied to almost any set of lights that have a remote.
He does this by connecting GPIO pins from the ESP8266 GPIO into the remote control in order to simulate a user pressing the button. Both boards are packaged together in a 3D-printed enclosure that utilizes the front portion of the remote control, so that manual operation is still possible.
His firmware gets the date and time from an NTP server, and then makes an API call to an online service that returns the local sunrise and sunset times for a specific location. He tries to minimize the power consumption by experimenting with different intervals to wakeup from deep sleep and ping the time server. But in the end, he realizes the RF remote control carries quite some distance, and installed the unit inside a closet where it could be powered by adaptors connected to the mains.
We wondered how the remote control knows if the lights are on or off, and [timabram] notes this is a shortcoming which could be addressed in a future version. If you’ve ever seen a mechanical version of an astronomic timer switch, packed full of gears and dials and setting pins, you can really appreciate a no-moving-parts solutions like this project. If you want to make one that doesn’t use the internet, check out this Arduino-based solution that we wrote about back in 2013.
Why over complicate it? LDR with filtering.
Has built in planetary compensation :D
…or one could simply take a photo-diode and measure the environment light and turn on the patio light accordingly (even without a microprocessor) – but that wouldn’t bee nerdy enough
Sometimes it’s about the journey and not the destination.
Tasmota firmware could have done this easily. Why reinvent the wheel?
Is there an easy way with Tasmota to download the astronomical info into your program? I hate the idea of having to rely on a service (that’s invariably going to change) for this kind of stuff.
I just set latitude/longitude/altitude and it sorts it out. It also let’s you set offsets. My patio lights turn on 30 min after sunset for 3 hours.
Tasmota rulez! Sunset and sunrise calculations are done local and should work without problems until 2099: https://github.com/arendst/Tasmota/blob/5e805e0c4ac1304bfe86a3abd1b6b99b7dda2daa/tasmota/xdrv_09_timers.ino
The bridged-contact remote is an under-advocated part of a lot of builds (and a favorite around here), since it gets rid of having to handle mains current directly, along with its associated risks and hazards. The worst-case failure modes – usually continuous cycling of the remote device – are much less likely to cause problems, and the likelihood of getting an electric shock from the remote is nil, meaning you can turn a younger person loose with it with a bit of supervision.
I have a remote control outlet doing exactly this for some lights. The results are not optimal. In winter I would like the lights to turn ON earlier than sunset, while in summer it could be a bit later.
So turning lights on/off by the sunrise/sunset time is not a good replacement for a light sensor.
If you run Home Assistant, it’ll let you control based on sun angle vs sunset. Not worth it if you’re not already running HA though
Probably better. But it still does not account for the huge difference in light levels depending on cloud coverage.
i was thinking how silly it is to consult the network to find sunrise/sunset (even though when i want to know, myself, i just google it). especially now that just about everything on wifi has an accurate clock in it thanks to ntp…that and a look up table ought to do it…oh, right, ntp’s network too. just seems like everything i can come up with involves IP traffic. 2021, i am in you.
The algorithm is out there, it just needs to know your lat/long to a degree or so, though it will link in the entire floating point library to do so. NTP should only be needed every now and then to keep the clock accurate.
I had an X-10 controller in the 90’s that did this. Typed in my ZIP code and it automagically knew sunrise/sunset times. Wasn’t as cool as building it myself but it just worked. Not sure it it required a net connection. It did build an entire year’s worth of on/off times in one run though. Those would just download to the controller and it didn’t need a PC connection after that.
@electrobob – If you’re looking it up online, perhaps consider nautical or civil twilight times instead of actual sunrise/set. The delta between sunrise and twilight is different summer vs. winter. If you’re not looking it up online, maybe adding in a temperature sensor to create an offset would be good enough? IE, it’s usually warmer in summer so the temp sensor + light sensor delays lights out and reverse that in winter when the temp sensor is cooler. (Guessing you don’t live in the tropics. :) )
Yeah, I had my X10 controlling my Christmas tree lights like this!
Certain models of Siemens logo! controllers have a built in astronomical clocks, I use one to control my outside lights. I have also programmed it so that it adjusts for time of year automatically, During the winter months the Lights turn on prior to sunset and during the summer months the lights turn on around 8:45pm.
Kind of awesome, as its about 500 cuss words simpler than the solution i made before i realized what had been done.
‘He does this by connecting GPIO pins from the ESP8266 GPIO’ – Eh, that doesn’t make much sense :D
I would have gone the route of NTP updated RTC and use one of NOAA’s sun tracking algorithms to calculate sun azimuth and altitude. The algorithm is pretty much a bunch of trig, but it is easy to implement in most uC with reasonable accuracy. Using an RTC also means that medium term internet outages are not a problem if using the NTP over plan old manual time correction.
While you could argue that an LDR circuit is sufficient, sometimes it’s ‘more about the journey than the destination’ and this project serves as an educational project over a more pragmatic design.
Also with an LDR you would have to account for clouds/storms which will keep turning them on and off.
I did the same thing using pythons Astral and has worked for years now.
An LDR also won’t let you set an event an hour or so before sunrise or sunset.