Chilled Beams #725
Chilled Beams #725
Conversation
Adding chilled beam telemetry fields
Adding descriptor for chilled beams field
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
abstract types for chilled beams
| uses: | ||
| - chilled_water_valve_percentage_command | ||
| - zone_air_temperature_sensor | ||
| - zone_air_occupied_temperature_setpoint |
There was a problem hiding this comment.
Kind of odd seeing occupied temp setpoint and unoccupied cooling setpoint. shouldnt they both be cooling setpoints?
| uses: | ||
| - perimeter_heating_water_valve_percentage_command | ||
| - zone_air_temperature_sensor | ||
| - zone_air_occupied_temperature_setpoint |
There was a problem hiding this comment.
same comment as above, except heating. id expect these to match.
| - zone_occupancy_status | ||
| uses: | ||
| - zone_air_temperature_sensor | ||
| - zone_air_occupied_temperature_setpoint |
There was a problem hiding this comment.
its odd to me that you have differentiated heating and cooling setpoints for unoccupied times, but there are no equivalent differentiations for occupied setpoints.
in general, we see either a single setpoint that changes based on mode, or we see two effective setpoints (for cooling and for heating) that change based on occ/unocc status. what is the context for this weird configuration?
There was a problem hiding this comment.
There were no heating/cooling setpoints for occupied mode. Unit runs in either cooling or heating mode while zone is occupied and controls to the occupied setpoint. In unoccupied mode the heating/cooling valves modulate to maintain the zone between the unoccupied heating/cooling setpoints.
There was a problem hiding this comment.
can this be fixed? this inconsistency between control in occupied and unoccupied mode is highly irregular.
otherwise, these will need to be modeled separately (e.g. zone temp and occ setpoint together in one abstract type, and zone temp and unoccupied setpoints together in another -- then a single type can implement both pieces of functionality in some non-canonical way, since this is very irregular).
There was a problem hiding this comment.
I see this pretty frequently in terminal units where there is a single setpoint during occupied hours, but during unoccupied hours there is a night setback for both heating and cooling. Do they need to be separated into separate abstract types?
| - zone_occupancy_status | ||
| uses: | ||
| - zone_air_temperature_sensor | ||
| - zone_air_occupied_temperature_setpoint |
There was a problem hiding this comment.
can this be fixed? this inconsistency between control in occupied and unoccupied mode is highly irregular.
otherwise, these will need to be modeled separately (e.g. zone temp and occ setpoint together in one abstract type, and zone temp and unoccupied setpoints together in another -- then a single type can implement both pieces of functionality in some non-canonical way, since this is very irregular).
| ## New fields for chilled beams | ||
| - zone_air_occupied_temperature_setpoint | ||
| - zone_air_unoccupied_cooling_temperature_setpoint | ||
| - perimeter_heating_water_valve_percentage_sensor |
There was a problem hiding this comment.
will this ever exist independently of another valve?
if we know the device lives on a perimeter then would heating_water_valve_percentage_... be sufficient?
There was a problem hiding this comment.
Potentially there could be other heating valves, like reheat or four pipe chilled beams.
|
@nwssullivan are the changes in this PR still needed? |
New extension for chilled beams