Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heat recovery unit #1048

Open
wants to merge 17 commits into
base: master
Choose a base branch
from
Open

Heat recovery unit #1048

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
a5a01dc
heat_recoevry_runmode added
adelin-diac Jun 1, 2023
b9cc6c8
heat recovery run mode states
adelin-diac Jun 1, 2023
2937ae5
added RSM type from previous PR
adelin-diac Jun 1, 2023
3635f54
rest of HRU types
adelin-diac Jun 2, 2023
00f98ab
fixed auto formatting
adelin-diac Jun 2, 2023
8dc6b5a
update descriptions
adelin-diac Jun 6, 2023
5b4db0f
Update states.yaml
adelin-diac Jun 6, 2023
453458a
Merge remote-tracking branch 'upstream/master' into heat-recovery-unit
adelin-diac Jun 14, 2023
ef6c007
update heat_recovery_run_mode states
adelin-diac Jun 14, 2023
6bf80ef
replaced OVERRUN with FAN_ONLY
adelin-diac Jun 15, 2023
1f5c9bd
added two states to run_mode
adelin-diac Jun 15, 2023
7e2131c
Merge remote-tracking branch 'upstream/master' into heat-recovery-unit
adelin-diac Jun 28, 2023
61125d8
fix based comments
adelin-diac Jun 28, 2023
c390cd9
fix autoformatting changes
adelin-diac Jun 28, 2023
9e3f6f9
removed FAM
adelin-diac Jun 28, 2023
2ef1224
Update AHU.yaml
adelin-diac Jun 28, 2023
286148a
Merge branch 'master' into heat-recovery-unit
cstirdivant Jul 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions ontology/yaml/resources/HVAC/entity_types/ABSTRACT.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6618,3 +6618,48 @@ VMADC:
- mixed_air_damper_percentage_sensor
implements:
- CONTROL

RSM:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use SS and mark the field run_command as missing? It seems this is not doing anything different than SS, its just that the field for the command doesnt exist or can't be passed to cloud.

guid: "e6aa94d5-1860-4a5d-8269-0edb968895e1"
description: "Run status monitoring"
is_abstract: true
uses:
- run_status
opt_uses:
- failed_alarm
implements:
- OPERATIONAL

SEFC:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see supply_air_flowrate_sensor or exhaust_air_flowrate_sensor. Those fields need to be added if this device controls the fan speeds to maintain flowrates to a setpoint.

Secondly, this type could be avoided if you instead apply the types SFVSC, EFVSC, SFC, and EFC. Please consider using those abstract types in your canonical type definition.

description: "Supply fan and exhaust fan control."
is_abstract: true
uses:
- supply_fan_run_command
- supply_fan_speed_percentage_command
- exhaust_fan_run_command
- exhaust_fan_speed_percentage_command
- supply_air_flowrate_setpoint
- exhaust_air_flowrate_setpoint
opt_uses:
- failed_supply_fan_alarm
- failed_exhaust_fan_alarm
- return_fan_speed_percentage_command
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the return fan work in this instance? Is it a booster back to the exhaust air stream? And why would this not be required if it were part of the coordinated control sequence that this type is trying to describe?

implements:
- CONTROL

FAM:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it could be made optional on the canonical type, or perhaps even on the general type. I dont see the need for a new abstract type for a single point; lets land this somewhere existing.

description: "Fire Alarm monitoring"
is_abstract: true
uses:
- fire_alarm
implements:
- MONITORING

HRC:
description: "Heat recovery run mode control"
is_abstract: true
uses:
- heat_recovery_run_command
- heat_recovery_run_mode
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have the mode and the command? Doesnt the mode indicate what the command is doing?

implements:
- CONTROL
14 changes: 14 additions & 0 deletions ontology/yaml/resources/HVAC/entity_types/AHU.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3982,6 +3982,20 @@ AHU_SFSS_SFMSC_SFVSC_FDPM_CHWSC_RTM_RACO2C_SSPC2X_VOADM2X_SAIDC2X_RAIDC2X_SSPC:
- RAIDC2X
- SSPC

AHU_HTSC_VOADM_ETM_RMM_FDPM2X_RSM_SEFC_FAM_HRC:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please address abstract type recommendations above before reconstructing this canonical type.

description: "Unit with temperature monitoring, differential pressure sensors and heat recovery control."
is_canonical: true
implements:
- AHU
- HTSC
- VOADM
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used when you have a device that mixes return with outside air, usually for economizing purposes. The rest of the context in this PR indicates that what you have is more of a single-pass DOAS system. Can you please confirm the configuration of this device and how it functions? (VOADM defines mixed_air_temperature_sensor, which is only appropriate for systems that can recirculate air from the space, mixing it with outside air).

- ETM
- RMM
- FDPM2X
- RSM
- SEFC
- FAM
- HRC

###################################
### Existing Non-standard Types ###
Expand Down
9 changes: 9 additions & 0 deletions ontology/yaml/resources/fields/telemetry_fields.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3110,3 +3110,12 @@ literals:
- ultraviolet_irradiance_sensor:
fixed_min: 0.0
flexible_max: 2000.0

- heat_recovery_run_mode:
- OFF
- ON
- STARTUP
- WARMUP
- OVERRUN
- INTERMITTENT
- FIREMODE
6 changes: 6 additions & 0 deletions ontology/yaml/resources/states/states.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,3 +90,9 @@ SOFTSTART: "Mode of operation of rectifier where the input power supply is gradu
NORMAL: "Function, state or flow which is an ideal or expected condition."
REVERSED: "Function, state or flow which is opposed to the expected or normal condition."

# FOR HEAT RECOVERY UNIT
STARTUP: "Operation mode where unit is starting up."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are startup and warmup modes substantially different from normal operation?

WARMUP: "Operation mode where unit is warming up."
OVERRUN: ""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs specific definition, and should be well-distinguished from all other mode states.

INTERMITTENT: ""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

FIREMODE: "Operation mode during fire alarm."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be a separate operating mode, or would it just be OFF when the fire_alarm field is returning ACTIVE?