[Equest-users] PHOTOCELL-CTRL Idea/Suggestion

[Aaron Powers]

Nick,

I just came across the same question recently, here's what I've discovered.
 In my case, I was looking at the difference between using photosensors or
simply using the BAS to control exterior lighting.

This was part of a larger eQUEST project, but I also created a spreadsheet
to look at the difference between operational hours.  For the BAS, we were
assuming monthly schedules, but these could actually be different by each
day.  A simple algorithm can be created on an hourly basis to calculate
sunrise and sunset, but the BAS works on an hourly resolution.  This means
that if sunrise is at 5:30, you'll have to leave the lights on until 6:00.
 In addition, to be conservative for safety sake, we let the BAS keep the
lights on shortly through sunrise and before sunset.  The spreadsheet shows
that using a photocell can reduce hours vs an average-ly programmed BAS.

In the spreadsheet, I assumed a horizontal flat plate collector surface for
the photosensor, which I believe is also what eQUEST assumes.
 Consequently, there's no need to worry about cloud data or any
other miscellaneous solar data, which are only used to calculate the
irradiation on a tilted surface given the irradiation on a horizontal one.
 Global horizontal radiation (diffuse plus beam) and diffuse horizontal
radiation are actually measured at the TMY3 stations.  It's also important
to remember that the TMY files are not averaged data, but each month is a
"typical" month, and two of the primary parameters in determining a typical
month are global horizontal and diffuse horizontal radiation.  So the solar
radiation data in TMY file should pick up regularities such as "June Gloom"
in Southern California for instance.

The major weakness in the spreadsheet is how to determine the efficacy
(Lumens/watt) of sunlight.  In fact, I resorted to using 93 Lumens/Watt for
direct sunlight, which I got from Wikipedia.  For the diffuse radiation, I
assumed 10% the efficacy of direct radiation.  I have no idea if this is
close to valid, but I'm fairly certain that the atmosphere reflects/absorbs
visible light at a higher proportion to IR radiation.  The efficacy of beam
radiation should be fairly constant, but the efficacy of the diffuse
radiation gets very complicated.  In theory, it should depend on the
particulate properties of the atmosphere.  At best, I think we could hope
for an efficacy model which depends on solar geometry and cloud cover.
 This wouldn't be able to account for things such as smog in a dense city.

Anyway, if you were to do an hourly report in eQUEST with global horizontal
radiation and an on/off flag for the photosensor, I think you'll see that
it's simply on and off with this value.  According to the spreadsheet
attachment, this misses approximately 163 hours of operation in Memphis,
which you may or may not consider significant.

Interestingly, the product that was chosen for the final design included a
photosensor/motion sensor combination.  The lights were to remain off for
all hours unless it was night time and motion was detected.  The lights
will remain on for 15 min after motion is detected.  Now, tell me how you
would model this with hundreds of lights across a campus?  I thought about
using a probability distribution to model motion detection at different
areas and finally decided that the eQUEST PHOTOCELL-CTRL is good enough!!

Aaron

-- 
Sent from my DynaTAC 8000x

Hey all!

Something new occurred to me recently triggered by a photocell scheduling
question.

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:
http://astro.unl.edu/classaction/animations/coordsmotion/daylighthoursexplorer.html
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 hood?

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.  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?

Thoughts?

~Nick



NICK CATON, P.E.
SENIOR ENGINEER

Smith & Boucher Engineers
25501 west valley parkway, suite 200
olathe, ks 66061
direct 913.344.0036
fax 913.345.0617
www.smithboucher.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120125/6faf64d5/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exterior Lighting Hours.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 416346 bytes
Desc: not available
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20120125/6faf64d5/attachment-0002.bin>