Daylight Control Package: Who has used, and how have you found it?

[wkearney99]

Really, this is like using the low light setting on the occupancy sensors just without the occupancy as necessary. i.e. lights in a common area are on from 8 AM - 10 PM whenever it is dark when the lights are off.

If you're not using occupancy as a guide then why not just tie it to sunrise/sunset? Or are there days where it's overcast enough that the sensor would be beneficial?

Otherwise, I agree, why can't the Daylight sensor that's already available work with RA2? Seems like a no-brainer.

[schalliol]

It's the overcast level you discuss, but I think also a true daylight control would fade to give an appropriate lighting level regardless of level of sun outside.

[bjm5090]

I am currently in the process of deploying a GRX-CESO-120 PKG in a Homeworks QS project. Unfortunately the system was spec'ed and equipment purchased a while ago (long before the LRF2-SSW became available).

The reason for the daylight sensor in our application is that the sales-man who sold the job promised automation that would automatically turn lights on/off based of motion and daylight. The homeowner is very adamant about begin able to walk through the house and lights turn on automatically if it is dark, but stay off if there is plenty of light in the room. Unfortunately we could never get the ambient light detect mode built into LRF2-OCR2B (ceiling mounted occ sensors that we have installed all over this guys house) to accomplish what we want. So we have one of these daylight package sensors, mounted outside the attic, detecting ambient light outside and triggering a variable in the system of whether it is bright or dark outside, and basing the occ sensors performance off that.

The biggest problem we have found so far is that dials for adjusting the foot-candle thresholds are very tricky to get just right. Finding that "sweet-spot" of how low the ambient light needs to go to trigger the contact closure and how bright it needs to get to then open again has been the biggest frustration. This is primarily due to the delay time it takes for the trigger to open/close (logically it makes sense to have the delay to account for a passing cloud or something) and also the simple fact that we can not control the weather outside to figure out how much cloud density/rain/etc is necessary to achieve the ambient foot candle levels outside that we want to trigger this thing. It literally involves booking install time/service calls during cloudy/rainy days and at dawn/dusk to test out at what levels this daylight sensor actually changes from one state to the other.

Currently, we simply have astronomic timeclock events running the daylight variables in the key rooms in the house and testing other rooms with the sensor. But yeah to answer the original post on this thread... it has an application, and can be used to prevent/enable automated lights from turning on/off based off ambient light, but it is such a frustration and hassled to get it calibrated that I don't think it is worth it.

Having never worked with the new RF daylight sensors, I can't speak to their functionality, but from what I've seen online, they seem to be the better choice. Only problem is they are only RF to a QSM on the wired QS link. Why they can't live on the RF repeater link.... idk. Guess that's what happens when you bring over hardware from Quantum.