Simple Calculation of Sunset Time required

Actually, as someone that does HA software, I'll say that a photocell, by itself, might not work!

For one, what's the interface to the controller? You got a varying resistance, and you must code for it's meaning.. (and actually interface it!) the fact that the resistance goes high or low does not indicate light/dark, unless you look at it over time. (ie, someone could have walked in front of the photocell and it could be "dark" for 30 seconds.. does this indicate dark and cause all the outdoor lights to come on?

Sunrise/dawn is also another interesting time.. What does the photocell see then? is it any different than a car passing by with it's lights on? (need to take the value over time to see if it's "really dark" and not something blocking the photocell..)

A photocell is the $9 home depot solution to the problem! A "smart" HA solution can do things like only pay attention to inside motion sensors between dusk and dawn, and not be fooled if a cloud passes by. Doesn't mean that lights cant be turned on at other times by using the wall switch!

That's why the OP talked about +/- 5 minutes for sunset.. Doesn't need to be exact, but "about right"

Real example.. My HA system knows sunrise/sunset/time etc.. On cloudy days, I might hit the wall switch to turn on the lights. The lights will stay on.. But after sunset, if there's no motion detected in the room (yup, I left the lights on and went off to do something else..), they'll turn off, until someone comes back into the room..

The real thing here, is the OP was looking for a SIMPLE way to determine sunset based on Jdate and lat/long within about 5 min - yet this has turned into a discussion about "leap seconds" and photocells!

Go back to the title of the thread "Simple Calculation of Sunset Time required"

You guys clearly don't really understand the application. How would you hook a photocell to the computer on your desk? That's what the OP is talking about. He wants his computer to know when it's dark (based on the position of the sun) without interfacing a photocell!

If someone comes to your desk to chat, will the photocell tell the computer it's dark? Only if they are there for more than 5 minutes?

Another real case.. I want my outside lights to come on at sunset and stay on until 11pm. What I don't want is my outside lights to come on at 2pm because it's cloudy, and then go off 10 minutes later because the clouds have passed. Then come on again at 3:15 and off at 3:20, etc...

What if the photocell says "dark" at 6pm? Is that a cloud or is it past sunset? Could be either based on the time of the year! A real HA system will prevent the "daytime flickers" and only turn the lights on when it is after sunset!

You guys like your leap seconds, etc, but you'll also be the first ones on the phone to customer support if your HA system kept turning on your outside lights during the day because it was cloudy! "but, but, a photocell should handle it!"

This thread demonstrates that the super stable system you and everyone else here inherits from astronomical timekeeping principles is barely understood by some and severly mangled by others,the most cretinous example being the belief that the Earth's rotation makes a 'bad clock'.The exquisite thinking of my astronomical ancestors never implied axial rotation could be tied to clocks as an observed motion,they just adaprted the pre-Copernican Equation of Time principles which create the average 24 hour day and transfered it to axial rotation as a convenience and not as an observation.

The core principles allow as much flexibility as possible,make your leap adjustments, geographically re-arrange the timezones boundaries (within reason),apply DST ect but it all hinges on knowing that where the 24 hour cycle comes from and how it was adapted to the daily cycle and terrestrial longitudes as an inviolate correlation - 24 hours/360 Deg.This stable system never invokes a direct correlation to observed axial rotation and to think it does is not the reasoning of an intelligent person yet many believe it does -

"Leap seconds are necessary because time is measured using stable atomic clocks (TAI or International Atomic Time), whereas the rotation of Earth slows down continually, though at a slightly variable rate. Originally, the second was defined as 1/86400 of a mean solar day (see solar time). This is determined by the rotation of the Earth around its axis and its orbit around the Sun; time was measured by astronomical observations."

Your reasoning is intellectually insipid whereas that of 'astronomers' here is downright toxic.Not even the treatise of Huygens appears to remove the pretension of axial rotation tied directly to celestial sphere geometry and while you may not understand it,it is causing enormous problems on different fronts.

That's not a problem. If the sky is clear, it's some 100 times darker at sunset than at full daylight. But lights need not be turned on right at sunset - one can wait until the Sun is some 3 degrees below the horizon, and then th light level is some 1000 times darker than at full daylight.

A very dark cloud otoh will bring down the ambient illumination by only a factor of 10 or so. Thus, a properly adjusted photocell which turns on the light when the Sun is a few degrees below the horizon on a clear day (somewhat earlier on a cloudy day) will NOT turn on the light just because a dark cloud passes by. Unless the cloud is extremely thick and dark (e.g. a tornado cloud), but then you might WANT the light turned on.

If properly adjusted, the photocell should not say "dark" because a cloud passes by, if he Sun is well above the horizon. See above.

When I hear hoofbeats, I tend to think horses rather than zebras. I doubt anyone "into" home automation couldn't string two wires from their controller to an outside window or location. That skill kind of goes with the territory. That means I would rank the possibility of "no access to natural light" very low in a formal requirements analysis, unless we know for sure the OP lives in a mineshaft. Most people don't, though. I am sure there are some automators I don't know of who can't string cable, but for them, there are low cost RF solutions. As for the actual requirements, TomCee told us:

Which makes me curious as to why would you think we have too little information to assume he wants to turn lights on and off via an automation controller at dawn and dusk? I pulled the above information from two of TomCee's posts, FWIW. It seems the requirements are pretty straightforward and *very* suitable for a photocell controller.

Something as simple as an X-10 Hawkeye sensor and an X-10 transceiver can do the job for under $30 without any wires, assuming his controller can speak X-10. That's what I use and it works quite nicely. Implementing a wired photocell might cost all of $10, and if you have some wire lying around, perhaps as little as a buck.

Since he's got an automation controller, he could install and poll multiple sensors to help insure that a single photocell isn't reacting to some artificial light source. It may be that some bytes might have to be used to "damp" the photocell's response so that only a true drop or rise in natural light triggers the night/day flag, but it wouldn't be many.

I readily agree that if the underlying requirement is to have lights come on at a precise time, then a photocell is NOT the right tool. But it seems as if the OP (and indeed most "automators") want external lights to come on in response to either motion or an absence of natural light so no one trips on the stairs and fractures their skulls.

Mr. Stockton's photocell solution covers very nasty, dark days when extra light may be very much needed. The calculator solution does not. It's not likely someone wanting to turn lights on and off at dusk and dawn, and who is concerned about total memory usage in his automation controller gains as much benefit from using a dawn/dusk calculator as he might from a simple photocell. Programmers and other technically inclined people are often so beguiled by working out the details of a complex solution that they overlook the simpler and far more elegant one. Sometimes simple is better.

Considering all the equipment that goes haywire in my house when DST arrives or leaves, I'd also have to add that calculating a sunrise/sunset time is a lot more prone to error than a photocell system. As an automator, reliability is of the utmost importance to me and I'd rather not have to futz with my light control code every time the Feds decided to change DST rules or I moved. The photocell solution covers both those cases as well as the "dark skies" case with ease. The calculator version does not. Those factors alone made it a no-brainer for me to use a photocell. Unless the OP lives in a concrete-walled bunker without a masonry drill, I suspect he would realize the same benefits as I do using a photocell to control the lights. (-:

-- Bobby G.

I think you should re-read the OP's posts. TomCee was definitely discussing an automation controller with very limited memory, not a desktop PC. He wants to turn lights on and off based on dawn and dusk. Automation controllers have input and output lines where you attach devices like photocells. Common sense dictates the photocell be placed where it does NOT get exposed to artificial light sources. Someone capable of programming the complex equations we've seen into his automation controller wouldn't have too much trouble figuring out how to programmatically evaluate the output of a photocell so that it only registered long term light changes and not "passing clouds."

-- Bobby G.

Having (thankfully!) missed most of this topic it seems that someone wants something to switch on at dusk and off at dawn.

1. There is a big difference in "lighting up time" between clear evenings /mornings and cloudy ones which will be tricky to program in.

1. There are optical sensors which will cope with the task of switching when the ambient light level crosses a preset threshold without recourse to correcting for leap seconds.

First of all, I have no idea if this is a home automation project. The OP may be a consultant, setting up a commercial control system. And as located, it is perfectly possible that accessing an outside sensor could be a problem (I can tell you from personal experience that getting wires run from inside a building to outside can be a huge problem with facilities managers). Besides that, many industrial controllers do not have analog inputs on them at all, which means adding external circuitry or buying an expensive industrial module in order to detect the actual light levels. So like I said: too little information to recommend a photocell as the "best" solution.

Actually, we do have one very good piece of information here: the OP is looking for a mathematical solution to the problem. I prefer to assume that he knows the most about his own application, and has already decided that a calculated sunset time suits his requirements best.

_________________________________________________

Chris L Peterson Cloudbait Observatory

Second of all, he may be a clod like you.

Yeah, like the device isn't exposed to the outside and there's no wiring leading out to a photocell. Tell the device the location, the date and let it do the calculating. Quite simple.

Do you really need to know the time of Sunset or do you just need to do something when the Sun sets? If it's the latter, just use a photocell. Just my $0.02

If it's for lighting, use a photocell switch. That will compensate for cloud/clear skies, etc.

And this,my good man,is why the topic brought in so many people insofar as the problem may look simple but the resolution is far from being so .The Earth does not suddenly develop a 366 day orbit every

4th year and although you may believe that software has the priority in determining the geostationary terms of sunrise/sunset or the heliocentric view of axial and orbital motions of the Earth,the fact of the matter is that software will highlight that timekeeping astronomy is not in line with structural astronomy in a serious way,specifically with a calendrical twist.

Had anyone paid attention to what Huygens wrote,they would have received the outlines of an answer -

"Here take notice, that the Sun or the Earth passeth the 12. Signes, or makes an entire revolution in the Ecliptick in 365 days, 5 hours 49 min. or there about, and that those days, reckon'd from noon to noon, are of different lenghts; as is known to all that are vers'd in Astronomy."

AND

"In the morning then, when the Sun is just half above the Horizon, note, what hour, min. and sec. the Watch points at, if it be going; if not, set it a going, and put the Indexes, at what hour, min. and sec. you please. Let them goe till Sun-set, and when the Body of the Sun is just half under the Horizon, see, what hour, min. and sec. the Indexes of the Watch point at......,"

The orbital motion of the Earth is referenced off a system of 365 days

5 hours 49 minutes whereas the people who have to adjust their softwae for a leap year ( in determining sunrise/sunset) are working off a system of 3 years of 365 days and 1 year of 366 days.Huygens references axial rotation within the orbital period of 365 days 5 hours... therefore you can actually create a software program that recognises the geostationary terms of sunrise/sunset and its heliocentric equivalent of axial and orbital motions using the central Sun and only the Sun as a eference (not the stellar background)

I do not find fault with anyone for staying away from this particular astronomical Gordian knot but the resolution is pretty much the same - split timekeeping astronomy from structural astronomy and do not allow the former to dictate the latter.

Using a photocell would require tracking the last detected time

(I came back to this thread because I woke up today to find a significant number of clock-enabled devices to be reporting the wrong time because of DST. That issue alone highlights the significant benefit of the photocell method, especially if the goal is simply to turn the lights on when dark and off when there's daylight.)

Well, one important clue to consider would be the cross-posting to a *home automation* newsgroup. (-:

He may also be the town crier, a dawn/dusk researcher, a Druid, the clock setter for his local church or a zebra. (-: Even if this *is* a commercial application, the photocell would work just as well. For example, many streetlights have operated for years and years with nothing but a photocell controller. They're used in such applications because they are incredibly simple (and therefore incredibly reliable), they are immune to DST law changes and can provide light in unexpectedly dark conditions, such as a severe thunderstorm.

When your goal is providing light only when it's dark, isn't it better to know when it IS dark rather than what time it is?

With photocells properly pointed skyward as they are on streetlights, they don't experience false activations from passing cars, although a hovering helicopter with a "nightsun" searchlight might set them off. But that would be another of those pesky zebras - a possibility so remote it requires only passing acknowledgement, even in a thorough systems analysis.

Now we've moved from zebras to unicorns, an even less likely source of hoofbeats. To rule out the photocell solution, you have to add some severe additional caveats that are indeed possible, but just aren't likely given what we already know. First, you have to assume that this a commercial application. Then you have to posit a cranky facilities manager and a windowless environment. Possible? Of course. So is a direct asteroid hit on his house. The question still is: are those hoofbeats we're hearing horses, zebras or unicorns?

We have the OP's introductory remarks about the severe memory limitations of the controller. That doesn't sound like an industrial controller to me, but yes, it's possible those hoofbeats are zebras. The "can't run a wire to the outside" is another special case scenario because for it to be a real concern requires the OP to live in a dark, cavernous building. More importantly it requires believing that running a two conductor cable to a place that receives natural light to be a Herculean task, not one that telecom and CATV jockeys with one month's experience do every day in homes across the world. Another zebra, if you will. I'm afraid it's not very likely given what we know about the world in general or this particular OP.

Most of your reservations thus far are predicated on the unlikely assumption that this is a commercial operation (the zebra). Once you've got one zebra, it's quite easy to build a corral and turn it into a herd. One unlikely constraint path can lead to a host of limitations that seem valid, but have little to do with the actual system requirements or operational environment. If you've already convinced yourself "an expensive industrial module" is needed for your industrial control system it means the zebras are breeding.

Even if this were a commercial application, there are any number of ways to very inexpensively detect dawn and dusk and generate a contact closure that wouldn't require an analog controller input. It would be a "no brainer" for the home automation controllers I am most familiar with: HomeVision, the Ocelot, and the X-10 CM15A. It might be a little harder with others. Since we know without question the OP's controller memory is severely limited, the photocell solution preserves that precious memory for other uses and operations that can't be performed as elegantly as a photocell.

Only if you're adding in zebraic assumptions that drastically change the original nature of the beast. It seems that we're now automating a commercial establishment (with a tyrannical facilities manager who harbors profound anti-wire sentiments) when the OP, who gave us some pretty detailed constraints, never said a word about those possibilities.

We actually have many more pieces than that (see OP's quote below). But for argument's sake, even if "the mathematical solution" were the only piece of good information we have, does that mean that the photocell idea was previously reviewed and discarded by the OP? Of course not. Ironically, it's on THAT issue that we have too little information. It could just as easily be that the OP didn't think of photocells. He might simply have failed to consider implementation issues (the very dark and rainy sunrises and sunsets mentioned by JR Stockton) that formula-based solutions simply can't deal with.

I say this based on the number of times I've come to Usenet with Solution X in mind only to find out that there were better, far easier solutions Y and Z to be had. I recall going to a tool group and asking how to sharpen a spade bit I was using to drill through joists only to learn that I should be using a Forstner bit. Just today I learned that there's a NEW kind of spade bit with cutting ears that cuts as well as a Forstner bit but is quite a bit cheaper. That sort of stuff happens to everyone, all the time. Having one solution in mind doesn't mean that all the bases have been covered thoroughly. Often, it means precisely the opposite.

If I were creating a requirements document out of what we already know, I would consider the approach the OP/client has initially chosen as a solution far less important than the problem he wants to solve within the constraints he's outlined. I'd also consider his memory limitations and look for the most memory-efficient solution. That's another mark in the plus column for a photocell. It takes very little code to implement. No code, no testing. No code, no updating required if DST changes. Automation controllers need reliability, not complex code subject to bugs, typos, programming errors, controller reset issues, synchronization issues, law changes, etc.

That's an interesting assumption, but that's all it is, and I'll explain why. Since he hasn't commented or mentioned the photocell in any posts or replies, it's equally valid to assume that he may not have thought about using a photocell. It took a rather long time in this discussion before either Mr. Stockton or I realized it might be a good idea. I prefer to think that the OP might have done the same and simply overlooked the photocell solution since he already had a solution in mind. That's the infamous "go to a carpenter, get a hammer diagnosis" problem of having a solution in mind locking out other, possibly superior solutions. Since we're injecting our preferences into the requirements analysis, I prefer to think he might not been aware of the many benefits of the photocell approach.

Plenty of smart people get wrapped around the axle trying to figure out a complex solution when a much simpler one will do. Legend has it that Ben Franklin cut two small doors in his house to allow his two cats, one large, one small, to enter and exit at will. When he saw both cats using the large door, he realized his error. Examine TomCee's own words closely against the assumptions you've made and perhaps you'll see why I think the issues raised about commercial operations or inability to reach natural light with a pair of wires are zebras.

Home automation group posting, memory limits, turning lights out, preferring lights to turn on early. These are the hoofbeats of horses, not zebras! (-: If you want to control electric lights to be on when it's dark and off when it's daylight, it makes lots more sense to detect actual dark and daylight and not compute dates.

-- Bobby G.

I can see what you mean but the OP did ask for a computational solution for a problem. . If I were addressing this professionally I'd write a list of requirements, constraints and assumptions.

Amongst the requirements would be 'to compute the time of sunset'.

Amongst the constraints would be 'limitation on memory'.

I would NOT include amongst the assumptions 'the problem can be solved by a light sensor'

I may ask for clarification of the 'requirements', but if the client states that a computational solution is needed I would not 'assume' that (s)he is mistaken in her/his requirements.

That's fine. Nobody would disagree that actually looking at the light level will provide the best results. But the OP asked for a mathematical approach, and that may be because monitoring the light level isn't an option.

In fact, you can do quite well with a clock. The solution in an automation controller is very simple: you don't worry about DST at all. Internally, you simply maintain standard time, or even UT. Your devices that had problems this morning were devices that were designed to display civil time- not a requirement of a lighting controller.

_________________________________________________

Chris L Peterson Cloudbait Observatory

About eight years ago I was asked to design and install a lighting system for an indoor native fresh-water fish stream/aquarium at an Audubon Nature Center. To keep the organisms happy, the lighting was needed to mimic natural daylight.

I considered using a digital microcontroller and calculated values. I concluded that the limiting factor on accurate lifespan with a non-networked uC or PC was going to be the long-term accuracy of the real-time clock and, even for networked controllers, the life of the clock battery. I didn't want to be in the business of servicing the device or to have it "fail". So I chose an analog route.

I hooked up a Panasonic PNA4603H light sensor

a Crydom 10PCV2450 analog-input solid-state dimmer. a simple home-brew op-amp buffer to adjust signal offset, span and gain.

The setup was a success because it required no maintenance on the part of the Nature Center staff. It just works. And it was (I assume!) smart enough to 'account' for the solar eclipse in 2002 and is ready for 2012. Unless someone paints over the sensor or causes some other situation that I would consider 'breaking' it, the arrangement will continue working no-fuss/no-muss as long as the lamps that the device dims are replaced when they burn out.

HTH ... Marc Visit my ongoing Home Automation and Electronics Internet Porch Sale at

Marc_F_Hult

Then you'd miss the opportunity to discuss other possible solutions, some of which might actually prove more useful to the client.

I'm located down in a "notch" between two hills. I use a photocell with a collimating tube to "watch" the streetlight which has a photocell WAY higher than I can get ;-)

...Jim Thompson