I’m trying to figure out how to set up the daylighting controls using the room property tool (see ref. image below) and could really use some help. The tooltip suggests that I need to set the x, y, z coordinates for the sensor within the room. However, after selecting the room, it seems like the process completes without an option to specify the sensor location.
If I select two rooms, it only provides one sensor location for both, which makes me think I need to select each room individually for the correct setup. Can you confirm if this?
Additionally, I can’t see any visual indication of where the sensor is placed within the room. Is there a default, backend-determined sensor location that’s applied automatically?
Lastly, how can I determine if the control setup is using stepped or continuous controls? Are there any built-in assumptions for this, such as a default schedule?
This is really a question for @mingbo but I think the answer is “yes”. Otherwise, you’ll be setting the lighting in all of the rooms to be controlled by a sensor that’s just in one room.
I’m going to reassign this issue to @mingbo to confirm but, to offer my suggestion, this seems like a case where the automation of Grasshopper is really helpful. When I assign daylight sensors to my energy models, I tend to just use the HB Apply Daylight Control component, which is set up to place a sensor in the geometric center (aka. pole of inaccessibility) of each room by default. Here is a script you can use to assign these default daylight sensors to the model that you built in Rhino and then you “Bake and Replace” the edited model from Grasshopper back to Rhino:
This gives you a good starting point and, if there are any rooms where the sensor is placed in a location that you don’t like, that is where the Rhino Plugin’s ability to set the sensor position comes in handy as you can use it to just change one room at a time.
It’s all Continuous at the moment. The stepped controls are something that can eventually be added if you need it but it would take some time. There’s also no availability schedule applied to the daylight control object, meaning that it’s effectively “Always On.” We didn’t see a major urgency to add the availability schedule because it’s a little bit redundant, given that daylight controls are already applied on top of the lighting schedule. So you could ensure that the daylight controls don’t operate for a certain hour by setting the value in the lighting schedule to zero. In our minds, that makes the model easier to check since you only have one schedule that you need to look at to understand the lighting instead of 2. But a lot of this is up for debate and, if you tell us that you need a certain E+ feature, we will add it to the GitHub issues and eventually implement it.
Thanks for this. I have successfully used this workflow as an alternative approach, and therefore consider this item closed.
However, regarding your comments on lighting control, I note that it will take some time to implement. Notwithstanding, I believe this is an important feature to simplify the lighting control process and ensure strict compliance with ASHRAE 90.1, specifically section 9.4.1.4, which I have attached for your review.
As a result, I believe the current approach would introduce some limitations, given that a schedule-based approach would be based on specific profiles or predetermined time-based schedules, but not necessarily reacting dynamically to actual daylighting conditions.
The limitation is that while a schedule can control when daylighting controls are in effect, it does not accurately represent the actual daylighting conditions that vary throughout the day (sun position, time of day, etc.). If the lighting schedule does not match the actual daylight scenario, there may be times when the lights are either unnecessarily dimmed or not dimmed enough, leading to either overuse or underuse of electric lighting.
Therefore, should you have any final thoughts on this, I would appreciate your feedback.
If it was not clear, I don’t recommend using schedules to account for daylight controls unless you have run a detailed daylight simulation with Radiance and you’re using something like the HB Daylight Control Schedule to generate the schedule for you from the Radiance results.
In my previous response, I was just explaining why we haven’t prioritized adding an availability schedule for daylight controls. But I don’t think you should use schedules like that because the basic daylight controls give you (almost) everything you need.
The daylight controls that you assign with the HB Apply Daylight Control object are compliant with ASHRAE 90.1 section 9.4.1.4 as long as you set the off_at_min to True. When I said that the lighting control is “continuous” you can essentially think of this as “hundreds of steps,” which meets the requirement of having “a least one control step. between 50% and 70%” If you select, off_at_min, this means that the electric lights will shut off at the min_power_in, which defaults to 30%. So that meets the requirement of being “no greater than 35%.”
Granted, I realize that there is a limitation of the daylight controls we have right now in that they are idealized and are probably not a very good representation of the real controls that are being specified for real buildings. I know most real daylight controls don’t have a fully continuous dimming of lights as the illuminance in the space rises. If only for the cost savings on the of the illuminance sensors, most real controls tend to break down the daylight control into a relatively small number of steps. So I’ll plan to expose the stepping behavior at some point and I opened an issue for it here:
You’ll know that the capability is close to being exposed when that issue gets closed.
