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.

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

Conversation

adelin-diac
Copy link
Contributor

Copy link
Collaborator

@tasodorff tasodorff left a comment

Choose a reason for hiding this comment

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

Some questions about the configuration and control of this particular device. Please provide comments on how the device controls so we can better advise on how to proceed with the modeling.

If you have any questions or want to provide us with some schematic of the system to help explain it to us, please contact: digitalbuildings-support@googlegroups.com. Happy to set up some time to discuss as well, if that will expedite the process.

@@ -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.

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.

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.

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?

@@ -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?

# FOR HEAT RECOVERY UNIT
STARTUP: "Operation mode where unit is starting up."
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.

STARTUP: "Operation mode where unit is starting up."
WARMUP: "Operation mode where unit is warming up."
OVERRUN: ""
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

WARMUP: "Operation mode where unit is warming up."
OVERRUN: ""
INTERMITTENT: ""
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?

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).

Copy link
Collaborator

@tasodorff tasodorff left a comment

Choose a reason for hiding this comment

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

Some questions about the configuration and control of this particular device. Please provide comments on how the device controls so we can better advise on how to proceed with the modeling.

If you have any questions or want to provide us with some schematic of the system to help explain it to us, please contact: digitalbuildings-support@googlegroups.com. Happy to set up some time to discuss as well, if that will expedite the process.

@adelin-diac
Copy link
Contributor Author

Thanks for all the feedback so far Trevor. I've updated the heat_recovery_run_mode states for now, but we're just awaiting some more information on them and their description. Myself or Kevin will probably be in touch soon with regards to properly modelling this system.

@adelin-diac
Copy link
Contributor Author

replaced OVERRUN state with FAN_ONLY. Unsure if this is best choice based on information given - "When the HRU is stopped suddenly the supply fan provides an overrun for the heater for 3 minutes."

@cstirdivant cstirdivant marked this pull request as ready for review July 19, 2023 15:30
@cstirdivant cstirdivant self-requested a review July 19, 2023 15:30
@cstirdivant cstirdivant added the ontology model Extensions or edits to the ontology model label Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ontology model Extensions or edits to the ontology model
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants