[Equest-users] PHOTOCELL-CTRL Idea/Suggestion
ncaton at smithboucher.com
Tue Jan 24 10:24:06 PST 2012
Something new occurred to me recently triggered by a photocell
To ground and set up this idea - first check out this interesting online
visual explaining how annual day/night hours vary based on latitude...
play around a bit with the bars to see how daylight hours vary based on
latitude and time of year:
Note that regardless of location, the yearly average on a daily basis
always works out to 12 hours.
Now take the typical case of a simple ON/OFF photocell control for
exterior lighting. From an exterior lighting control standpoint, the
model linked above is simplified from reality in that the effects of
cloud cover/weather are not accounted for. While the sun on a given
day may officially set at 6PM, for example, overcast cloud cover, rain,
smog, fog and similar conditions may cause a photocell to turn on the
exterior lights hours earlier, by reducing the daylight illumination
reaching the photocell/ground.
Based on some explorations - the current PHOTOCELL-CTRL schedule appears
to demonstrate something like a "simplified" model per the above link,
assuming clear skies. I'm observing approximately 12 hrs of photocell
operation per day averaged over the year for different locations' TMY
weather files (slightly less, actually... ~11.95). I would assume by
extension it's using a function based on the location's latitude or
perhaps referencing something like the "sun up flag" in the weather
files. Does this jive with what anyone knows to be going on under the
If my understanding is correct, I would like to suggest a few
improvements for present discussion and future development:
1) First I think it's worthwhile to retain the "clear sky"
PHOTOCELL-CTRL function as it currently exists - I can conceive
applications where a simplified "on when the sun sets" model could be
both desirable & useful, such as in comparing output with simple
daylight simulation models. It could also perhaps be more specifically
named "ASTRONOMICAL-CTRL" in reference to mechanical/digital
astronomical timeclocks which calculate daily on/off times very much
like the animated model linked above.
2) An improved PHOTOCELL-CTRL scheduling function could be defined
working around the following:
a. It's my understanding that weather files may contain hourly
measured illuminance readings that inherently account for cloud cover
and other weather conditions.
b. Actual photocell systems will turn on and off at prescribed,
sometimes different levels. For example, here's a link to a product
which turns fixtures on at 3fc and off at 8fc, with a nominal delay to
minimize nuisance cycling: LINK
D%20Luminaires.pdf> . The equipment literature I've checked cite values
from 1fc to 10fc.
c. Per the above, an improved PHOTOCELL-CTRL scheduling option
could accept inputs for one (possibly two) exterior footcandle levels to
define on/off behavior. Hourly ON/OFF behavior could then be determined
directly referencing the exterior hourly horizontal ground illuminance
measurement from the weather file used, switching lights when the
appropriate threshold is crossed.
d. Such a scheduling option could more accurately gauge the full
impact of exterior lighting retrofit and controls upgrades. This is
often relatively low-hanging fruit, in my experience.
A related query for the weather gurus: I'm uncertain whether TMY
weather files, representing averaged data over many years, would be
particularly constructive or not for representing the effects of cloud
cover and so forth... Growing up in FL, I recall a definite
"rain-season" mid-summer which I expect would be captured in the
daylight measurements of any FL weather station... but where
weather/cloud cover is much less regular (such as here in KS), perhaps
the effects would be lost in averaging?
NICK CATON, P.E.
Smith & Boucher Engineers
25501 west valley parkway, suite 200
olathe, ks 66061
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 1459 bytes
More information about the Equest-users