First time here? Check out the Help page!
1 | initial version |
I initially thought it could be two things:
AvailabilityManager:NightCycle
reporting tolerance of 1C by default. I'm thinking having set the Supply Air Fan schedule to always 0 might be triggering some built in availability manager with a hardcoded tolerance of 1C
Then I realized it was something else entirely. I actually have a DOAS supplying unconditioned air to the zone as well. I've created all my systems (DOAS and ZoneHVAC) by using the OpenStudio API. Turns out I have assigned the ZoneHVAC component to the zone before I assigned the DOAS's AirTerminalUnit (ATU). As OpenStudio will generate the cooling and heating priorities based on this specific order (as pointed out on unmethours and on uservoice), my ZoneHVAC had a priority of 1 and the DOAS 2, the exact opposite as what you need to do.
From there I had two solutions: either assign the equipment to the zone in the right order, or just use setCoolingPriority
and setHeatingPriority
(see SDK Doc)
Here's a ruby example of the second method:
# I've already added the ZoneHVAC equipment, now I add the DOAS ATU
atu = OpenStudio::Model::AirTerminalSingleDuctUncontrolled.new(model, model.alwaysOnDiscreteSchedule)
# I could just have created this terminal BEFORE creating the other and it would have ended as first priority for cooling and heating
# But I'll set it after the fact as a good reminded that OS will by default use whatever order equipment to create the ZoneHVAC:EquipmentList
# You should always have the least controlled equipment (DOAS, etc) first in line, to let the most controlled one pickup the remaining load
zone.setCoolingPriority(atu, 1)
zone.setHeatingPriority(atu, 1)