This working group seeks to be a place of discussion and refinement for all future AHU proposals. I'm looking forward to working with everyone, and seeing all the creative ideas to extend the AHU structure.

The first proposal I'd like to discuss is the Heat Recovery system defined here: https://project-haystack.org/forum/topic/605.

I'd like to start a discussion about how we can improve the definition of AHUs. The current definition is:

equipment designed to heat or cool air.

which is extremely generic. One could argue VAVs with hot water coils are also designed to heat air, but we would not tag them with ahu.

Here are a few questions to get us started:

• What is the defining feature of an AHU?
  • A fan?
  • Multiple chambers?
  • An outside air section?
  • Filters?
  • That air is delivered into ductwork?
  • Some combination of these?
• Do we think the Wikipedia definition is better?

  A large metal box containing a blower, heating or cooling elements, filter racks or chambers, sound attenuators, and dampers.

Yeah, definitely needs some work. As stated "equipment designed to heat or cool air" could be a radiator or a Yeti.

Don't much care for the wiki definition either.

"Fan" fits in the definition can't think of any AHUs that do not have a fan.

"Multiple chambers", do you mean chamber as equipment that has an air input and an air output chamber... that's the same as a toilet exhaust, but we're getting closer.

"An outside air section" perhaps fits, at least that would differentiate it from a toilet exhaust.

"Filters" are sometimes located remotely from the air handler unit so filters don't work.

"That air is delivered into ductwork" has merit. All AHUs that I'm familiar with have fans that deliver air into ductwork.

That leaves us with "Equipment with a fan that delivers outside air to a space via ductwork"

Still needs work, because my home has an AHU, but no outside air connection... of course that's not a commercial application.

Thoughts?

I found a decent defintion from ANSI/AHRI Standard 430-2014 A central station AHU (CSAHU) is “a factory-made encased assembly consisting of a supply fan, or fans in parallel, which may also include other necessary equipment to perform one or more of the functions of circulating, cleaning, heating, cooling, humidifying, dehumidifying and mixing of air.”

I've seen commercial AHU's that do not incorporate outside air. Maybe this is just an uninformed mechanical engineer who is calling the unit an AHU when it should not be? But I would leave "outside air" out of the definition because I don't agree that all commercial AHU's have outdoor air sections.

I also agree with Scott that the delivery of air into ductwork is important, but I would add that the ductwork is typically recirculating air within a given space. This would differentiate an AHU from something like an exhaust fan or a supply fan.

I think this additional work to extend the AHU tagging models is great and needed.

I also want to suggest that the AHU WG submit to get on the Haystack Connect 2019 schedule for a live meeting per our earlier invitation here https://project-haystack.org/forum/topic/676

It will provide a great opportunity to discuss these topics in person and drive further work.

Just submit via the Call for Speakers link on the site

Good idea John. Jay as champion, can you coordinate this? I'm not a member but would be happy to participate.

Thanks John, I've registered the AHU working group for a live meeting at Haystack Connect.

Great points Scott and James! My thoughts

• It's interesting ANSI specifies "a factory-made encased assembly", because many AHUs are custom-built rather than factory assembled.
• I agree with Scott about leaving the outside air section requirement out of the definition, as I have seen return-only equipment that otherwise seems identical to other AHUs.
• I also like the fact that the Wikipedia and ANSI definitions call out things the AHU can contain or can do - I think that alone helps differentiate them from a simple supply fan.

Combining a few of the different ideas, I came up with the definition below. What do you guys think?

A large metal box with a fan that delivers air to a space via ductwork and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, or mixing the air.

That sound good to me. A bit concerned about the term "large metal box" perhaps "An enclosure with a fan..."

Haha yeah, that was the part I was least comfortable with Scott. Revised to:

An enclosure with a fan that delivers air to a space via ductwork and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, or mixing the air.

Jay - I think that definition looks great!

While you guys are working on this, can you please also consider the definitions for unitary equipment:

• fan coils
• heat pumps
• unit ventilators

And maybe re-examine terminal units such as VAV. And what others are we missing?

For example, does that definition for AHU you propose make a clear distinction b/w an AHU and FCU?

We are also introducing the notion of subtyping in Haystack 4.0, so we also need domain experts to define the taxonomy/tree structure of these equipments. For example should we create the concept of a terminalUnit and/or unitaryEquip that groups more specific equipment?

That's a great lead-in Brian, because how AHUs relate to fan coils and unit ventilators was what I was actually interested in with defining AHUs. Let's attack FCUs first.

Background

The current haystack definition:

Fan coil units are unitary heating/cooling assets which use the zone itself for supply air.

Questions

I'd like to qualify that I'm less technically familiar with FCUs than AHUs, so please forgive me if I ask stupid questions.

• Can FCUs have input airsteams in addition to zone air? Perhaps discharge air from an upstream AHU?
• Is an FCU a type of AHU, or are they mutually exclusive? That is, could we use the fcu and ahu tags simultaneously on a piece of equipment?
• If they are mutually exclusive, what is the distinguishing feature between them?
  • Do AHUs deliver air into ductwork, whereas FCUs deliver it directly into a zone?
  • FCUs are unitary, and AHUs are not? How do we reconcile that with the rooftop tag?
  • FCUs are sourced by zone air? Are there not return-air-only AHUs?
  • Are FCUs always located within the zone, whereas AHUs are remote?
• If they are not mutually exclusive, what makes an AHU an FCU?

Hi - I've been following Project Haystack's work with interest.

If you are not already familiar, it may also be helpful to know that there is a glossary of HVAC-related terms maintained by ASHRAE through TC 1.6 (Terminology), that includes terms like AHU, heat pump, fan coil, and can be slightly different than the ANSI definitions above.

I've seen cases where it looks like a definition needs to be updated or made more precise (eg radiant is defined as radiating rays of light), but it's an existing public glossary of over 3,000 terms that will presumably be maintained over time.

For what it's worth, their AHU definition has:

"assembly consisting of sections containing a fan or fans and other necessary equipment to perform one or more of the following functions: circulating, filtration, heating, cooling, heat recovery, humidifying, dehumidifying, and mixing of air. Is usually connected to an air-distribution system."

Dana,

Thanks for pointing that out. Think that we got pretty close to the ASHRAE definition with a few less words. I'm in favor of less verbose definitions as long as the context is equal or improved.

So for FCU our ASHRAE brethren have:

FCU - fan coil uni, factory-made assembly that provides the functions of air circulation, cooling, heating, or cooling and heating.

That definition works for me. Seems that the distinguishing factor is the lack of air distribution system.

heat pump ASHRAE has the following for heat pump - thermodynamic heating/refrigerating system to transfer heat. The condenser and evaporator may change roles to transfer heat in either direction. By receiving the flow of air or other fluid, a heat pump is used to cool or heat. Heat pumps may be the air source with heat transfer between the indoor air stream to outdoor air or water source with heat transfer between the indoor air stream and a hydronic source (ground loop, evaporative cooler, cooling tower, or domestic water).

Probably gonna have to whittle on this one a bit :-)

Then we have...

unit ventilator - fan coil unit package devised for applications in which the use of outdoor and return air mixing is intended to satisfy tempering requirements and ventilation needs.

That's agreeable as well, however a bit verbose. Think that we could perhaps delete "...devised for applications..."

Could you explain to me, why a rooftop AHU is different to any other AHU. Here in the UK we do not distinguish between an outside AHU and an inside unit. After all the AHU might be on the ground rather than the roof. I appreciate it will need to be weather tight but that’s the only difference. Alan Jones BMS consultant.

As I read the "rooftop" tag it is used in conjunction with ahu to further define the equipment being described. As you state the difference between the two is that one is a weatherized version, which I feel is appropriate. Indeed there are cases that an RTU is not mounted on the roof, but it is nonetheless a weatherized package. Does it make sense to drop the notion of "rooftop, ahu" and replace with "weatherized, ahu"? For novices this maybe a reasonable description and term, but the majority of us would think it odd and use the term rooftop.

I'm of the opinion that the "rooftop" tag is a bit shortsighted. There's a lot of equipment that we can find on a "rooftop" that are not associated with "ahu". I looked at the "geo..." series of tags which are related to lat/long but not level. Tag "level" doesn't fit either as it's associated with fluids.

I can't seem to find a series of tags that describes the floors and/or areas of a building, which to me seems to be a necessary tag.

How about outdoor? Also indoor… so something mounted on the roof or otherwise exposed to the weather is tagged outdoor, and something that is largely sheltered from the weather is indoor.

Could work for lots of things (e.g. outdoor temp).

Scott,

Check out the public review site for Haystack 4.0 and look at the space def (https://project-haystack.dev/doc/lib-phIoT/space). There will be a series of defs (tags) that describe the floors and areas of a building in Haystack 4.0.

Hey, sorry for being MIA for the past few weeks. There's been some good discussion here, and I've reworked a few of the suggestions into the proposed definitions below:

• ahu: An enclosure with a fan that delivers air to a space via ductwork and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, or circulating the air.
• fcu: A unitary, factory-made enclosure with a fan that delivers air directly to a space and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, or circulating the air.
• uv: A unitary, factory-made enclosure with a fan that uses outdoor and return air mixing to satisfy tempering requirements and ventilation needs.

Most of my questions revolve around the unit ventilator definition:

• How do we differentiate between ahu and uv, or is one a sub-category of another?
  • Is it that uv is unitary and ahu is not?
  • Is it that ahu has a downstream ductwork system and uv does not?
• How do we differentiate between fcu and uv, or is one a sub-category of another?
  • Is it that uv has outside air and fcu does not?
  • Or that uv lacks heating/cooling coils?

Finally, defining a general heatPump tag seems wider than the scope of this discussion, since the term "heat pump" spans airside and waterside systems.

Please see airHandlingEquip taxonomy for what the current proposal entails.

There needs to be a general term for the "base class" of these things which seems to be a very elusive term. I picked airHandlingEquip for now as a place holder.

The definitions need to correspond to how the taxonomy is organized (which is also just a proposal). For example what is common to all of them? What specifically makes a unitVent different from a FCU? Note based on current feedback I've make unitVent a subtype of fcu.

(With apologies, as I doubt I have the bandwidth to maintain consistent engagement in this discussion, but felt the need to chime in. Tried to scan the thread to see if I was repeating anything.)

1. Either fcu or unitVent could be subsets of the other. It might be worth considering that some energy modeling software tends to put both under "unitary equipment", which I admit isn't the strictest definition itself.
2. Unit ventilators may have coils for conditioning air, and (news to me) looks like energy recovery now too? Example of a unit ventilator. (Full disclosure: I have no association with the manufacturer, this is just what popped up.)
3. I would offer that the tag unitVent is preferable to uv. With uv, I see future confusion with ultraviolet germicidal irradiation (UVGI) equipment that is used in certain AHU applications.
4. I like ASHRAE's AHU definition, but my first thought was of recirculating filtration units used in some healthcare spaces. I think they can be ducted (don't quote me), but they are a fan and a filter with no conditioning. One could make the argument that it "handles air", but there's part of me that would cock an eyebrow at using the phrase "air handling" while describing them. Then again, that's more based on what I'm used to from industry than anything else.
5. Agreed that heatPump is a separate item. Heat pump applications can vary in size from unitary to full AHUS (whatever that means) to water-to-water. It's more of a cooling/heating conditioning option in the same lane as defining whether something is served by DX, gas heat, hot water, chilled water, etc.

Alright, thanks for the input guys! It was awesome to discuss these topics with all of you that came to Haystack Connect 2019.

I've finalized a proposal, and listed the proposed definitions below:

• ahu: Air Handler Unit: An enclosure with a fan that delivers air to a space via ductwork and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, ventilating or circulating the air.
  • mau: Makeup Air Unit: An AHU that brings in 100% outside air and no recirculated air.
  • rtu: Roof Top Unit: A unitary AHU that is weatherized for outdoor use.
• fcu: Fan Coil Unit: A unitary, factory-made enclosure with a fan and coil that recirculates air in a space and performs one or more of the functions of cleaning, heating, cooling, humidifying, dehumidifying, or ventilating the air. Unit heaters are examples of FCUs.
  • unitVent: Unit Ventilator: An FCU that has direct access to outside air to provide the space with ventilation.
  • crac: Computer Room Air Conditioner: An FCU designed to condition a computer room.

These definitions appear to align closely with the ASHRAE Terminology and most community interpretations.

If you have strong feelings or issues with these definitions, please speak up. Otherwise, I think we can call this working group complete.

Just a small (perhaps slightly pedantic) suggestion: in English, AHU was originally an abbreviation for Air-Handling Unit often known simply as an Air Handler but not generally Air Handler Unit which is a mashup of the two.

Hi All,

I want to echo some of the concerns raised already around the use of rtu:

rtu: Roof Top Unit: A unitary AHU that is weatherized for outdoor use.

What it's really trying to capture is if the unit can be exposed to the elements. Perhaps this was discussed at the meeting, but why use Roof Top when it could apply to any exposed location?

Yes Richard we did discuss it. I believe that we resolved that location could be determined by tags related to specific floors of a building (ref: Haystack 4). It was pointed out that some applications have "RTUs" on the ground level. We decided that rtu was appropriate because it is an understood type of equipment that is being described.

@Jacqueline

AHU was originally an abbreviation for Air-Handling Unit

Great point! Thanks. This will be changed.

@Richard & @Scott

Scott is exactly right - thanks for speaking up. Since "rooftop unit" is so widely used in the industry and typically denotes the unit design more than the physical placement, we determined that it should be reflected here.

There have been some concerns about using the rtu abbreviation, as it may be confused with a "remote terminal unit" from the networking world. I find the rooftopUnit tag name to be a decent alternative, but I'm interested in others' thoughts.

@Scott @Jay, thanks for the clarification. Completely agree on location being determined by other means.

Using "rooftop unit" to describe an AHU that isn't on the roof just seems odd to me. To be honest I wouldn't really use the term at all, I'd just call it an AHU (maybe prefixing with "external" or "outdoor"). It's probably down to the fact that the normal industry terms may change depending on where you are in the world. My experience is in Ireland and the UK. I note that Alan Jones, from the UK, also questioned it above.

Apologies for not inputting sooner, but when I saw it included in the finalised proposal I wanted to flag it. I appreciate that a wider audience has already discussed and accepted it, so will not push it further.

Hey Jay - would the rooftopUnit be camel case or utilize the new conjuncts? rooftop-unit might be problematic because of the unit def...?

Hey Admins, I believe this working-group's work was completed with Brian Frank shortly after Haystack Connect this spring. Can we close it? Thanks!

Hey guys, there are a few different requests that I think could be rolled up into our working group:

• Heat recovery
• Humidifiers
• Economizers

I'll put together a proposal and a list of guiding questions for handling each of these this weekend, and will email you guys a invite to have a call next week to discuss the proposals.

Of course, if anyone else has experience with AHUs we'd be glad to welcome them into this working group and our discussions as well. Thanks, and I look forward to talking to you!

Dear Jay

About the heatRecovery item in below link: https://project-haystack.org/forum/topic/605

I wanted to check if the suggested tags can be used already?

Many thanks for your efforts and looking for your reply.

Regards Ashkan

Hey Ashkan,

Those tags have not been formalized and brought into the Haystack Standard quite yet. We actually have a meeting in 1hr to discuss them, if you'd like to join and add your point-of-view. If so, just join this working group and I'll add you.

Thanks!

Alright, so we've reached internal consensus and are ready to get input from the wider Haystack Community. Our proposal for AHU updates is below:

• Humidifiers
  • humidifier will be a new top-level equip, with run/enable state point children. It will operate similarly to fan, where it can either be a point on an airHandlingEquip or a separate equip entirely.
• Dehumidifiers
  • dessicantDehumidifier will be a new tag to indicate a Boolean point that controls the dessicant dehumidifier, and will be added to airHandlingEquip children (similar to heatWheel).
  • Non-dessicant dehumidifiers (those relying on reducing air temp beyond the dew-point) will not be defined, as modeling them using existing cooling/heating equipment is already possible.
• Economizers
  • economizing will be a new tag for boolean points that indicate the state of an economizing mode. Economizing in this context means an energy-reduction process, which on AHUs translates to increasing outside air flow to reduce heating/cooling requirements.
    • This tag is pretty general so that it may be used to indicate economizing conditions on other equipment, like chilledWaterPlants, chillers, etc.

Please respond with any questions, comments, or concerns. Thanks!!

Hi, just a reminder that we're looking for feedback from the community on the proposal above. It covers tagging for humidifiers, dehumidifiers, and economizers. Let us know what you think! Thanks.

Hi,

I have two proposals. The first proposal regards heat recovery in ventilation systems. So long, there is no tags or equip in HayStack 4 then heatWheel (tag indicating command state of AHU's heat wheel) for heat recovery equipment and sensors. There are two kinds of heat recovery systems that are traditionally used in Norway: rotary thermal wheels and fixed plate heat exchangers. The third concept - heat pipes, I saw just once in my career. Two parameters that are interesting and which always are presented in building automation system are: 1. Percent(level) of speed for rotary thermal wheels or percent(level) of air going through fixed plate heat exchangers (not bay-passing). 100% indicates full speed for rotary thermal wheels. For fixed plate heat exchangers, 100% indicates that all return air goes through heat exchanger. 2. Efficiency of heat recovery (in %), indicating how much heat from return air is transferred to fresh-outside air. I propose that heat wheel should be equip and child of ahu, since it is not logical to put it into outside, discharge, return or exhaust duct.

The second thing that I want to discuss regards ahuRef. I work with tagging in HayStack 4 and I think that it is useful to have spaceRef in haystack model. Now I can easily find all equipment and points for one room if I write in Axon: readAll(spaceRef->navName=="Room_033"). Otherwise, if there was no spaceRef then I needed to write: readAll(equipRef->navName=="Room_033" or equipRef->equipRef->navName=="Room _033" or equipRef->equipRef->equipRef->navName=="Room_033" or equipRef->equipRef->equipRef->equipRef->navName=="Room_033")

spaceRef appeared automatically for all equipment and points which are parts (children) of space when I made a space in SkySpark. This feature is not included for ahuRef in SkySpark. When I made children of ahu they didn’t have ahuRef automatically. Is that deficiency of SkySpark or I didn’t understand meaning of ahuRef. It will be useful to have ahuRef for one system that stands high in hierarchy of one building. Do I understand right meaning of ahuRef?

Children of site are space and equip in Haystack 4. Shouldn’t be better to separate (differentiate) systems in one building in space, ahu, lighting (now just a marker tag), heating, cooling? Some of the systems are maybe overlapping in some cases, but I think that top hierarchy will be useful. I came maybe late in this discussion, so excuse me if I repeat something that was already discussed.

Regarding spaceRef and ahuRef - Haystack 4 standardizes space as the top-level entity type for all spaces (floors, rooms, etc). Adding spaceRef to an equip or point means that equip/point is contained by the space.

The ahuRef tag right now isn't actually registered as a tagOn anything. It should probably be a predefined tag on vav or maybe any airTerminalUnit? But there should probably be some other tag/term for modeling how spaces are served by the HVAC system. What has been discussed is something like airSupplyRef which would be applied to spaces to reference to their terminal units or direct AHUs and form the model of the "air distribution system".

I think that spaceRef is really good feature from practical point. It enables easy searching (sorting) of points, which I mentioned in previous post. It sounds logical to me that vav ( airTerminalUnit) is part of space, since automatics of vav (airTerminalUnit) is independent from systems that supply them with air. Similar will be for radiator thermostat, cooling coil thermostat, rom lighting. They should be also part of space.

I don’t agree with you that ahuRef should be predefined tag on vav, airTerminalUnit (coils or radiators). Those equipment can have airSupplyRef as you said. New tags hotWaterSupplyRef, chilledWaterSupplyRef would indicate from which equipment is supplied hot water and chilled water.

I think that ahuRef, chilledWaterPlantRef, hotWaterPlantRef and steamPlantRef can be also top-level entities (like spaceRef) since they are top-level equipment working autonomously from other systems.

The other question is, why containedBy and contains is not applied in SkySpark. Why SkySpark doesn’t define containedBy tag with referance to parent when we define one child. It is maybe duplicating of ahuRef, but since we already have containedBy and contains tags in HayStack 4, why we don’t start to use them? Similar question is about receives and supplies tags. Instead for airSupplyRef, we can use receives relationship.

Best regards, Marko Masic

we already have containedBy and contains tags in HayStack 4, why we don’t start to use them?

They are used - those tags are applied to the definition of a ref tag to indicate its semantics. For example the equipRef def uses containedBy:

def: ^equipRef
is: ^ref
of: ^equip
containedBy: ^equip
tagOn: [^equip, ^point]
doc: "Reference to equip which contains this entity"

I would say the final design for ahuRef and airSupplyRef or whatever we call it should be another topic for the standing AHU group and just lump decisions related to the air side of HVAC into this WG

I agree that final design for ahuRef should be another topic for the standing AHU group.

Is there anyone who have a comment on tagging of heat recovery in ventilation systems?

Hi Marko,

This is a proposal that hasn't yet been accepted into the standard for fixed plate heat recovery. As for heat recovery wheels, I think those point suggestions make a lot of sense, and should be fairly easy to add in to the standard.

I'll add designing a solution for the ahuRef or airSupplyRef as well as additional heatWheel points to this working groups priorities.

Thanks! Jay

I have incorporated Jay's proposal from 26-Feb-2020 into the Haystack preview version 3.9.8 for final review

Hey Jay - looking at the economizing point, am wondering if we can incorporate the following to be clear about usage of different tagsets for the majority of AHU configurations:

• Outside air damper:
  • Generally used in two scenarios:
    1. When the AHU does not utilize economizing
    2. When the AHU uses economizing, but has a separate damper for economizing control. In that scenario, this damper is typically referred to as the minimum outdoor air damper.
       • Tagset: outside damper actuator equip
• Economizing damper:
  • Used when an AHU has two outdoor air dampers. This is the economizing damper, while the other damper is the minimum outdoor air damper.
  • Tagset: economize damper actuator equip
• Outside air and economizing damper:
  • Refers to a single damper on an AHU which is used as the outdoor air damper as well as for economizing control.
  • Tagset: outside economize damper actuator equip

These would all equipRef->ahu and I think this gives users a better understanding of control points to expect? Another question to tackle is can we add additional tags to delineate expected damper control capabilities:

• modulating - Expect 0% - 100%
• openClose - Expect boolean control points

Interested in others thoughts and thanks for all the work on this!

Essentially what you are proposing is the economizing tag is also used to describe a damper. The original WG work we did last month was only to use that tag for points. I think if we are going to start making a distinction b/w an economizing vs fresh outside air damper that is require some WG effort to gather consensus. And we would have to consider the common case where there is only one outside damper. So this should go on the docket for further AHU work.

another question to tackle is can we add additional tags to delineate expected damper control capabilities:

That is already handled by the existing model - you would look at the damper cmd point and check if its kind tag is Number (percentage modulation) vs Bool (open/close). See damper tag.

Great idea Cory. Thanks Brian for the clarification.

To parrot Brian, the economizing tag is currently intended for an economizer mode point, which would typically be a boolean. It's not meant to indicate a damper or a damper position. In fact, Brian, I suggest we consider revising the tag doc to something like this:

Boolean point indicating the state of an economizing mode, meaning an
energy-reduction mode. In air handling units, this commonly refers to
using additional outside air in order to reduce the energy needed to
condition a space.

However Cory, your use-cases make total sense. Internally our organization uses the following tag-set to denote minimum outside air dampers: {air, damper, outsideMin}. It's certainly not pretty, but it gets the job done. I like your solution above much more, and will add it to the list of priorities for this working group.

That is already handled by the existing model - you would look at the damper cmd point and check if its kind tag is Number (percentage modulation) vs Bool (open/close). See damper tag.

True - I guess I'm trying to understand in which instances do we need to inference vs. when do we need to be explicit. We could keep it the way it is, or add some simple typing tags to enable better type mapping using marker tags. Something like a damper actuator modulating I would expect to have a point cmd point modulating vs. something like a damper actuator openClose I would expect to just have a cmd point. Just a thought.

Jay - I would be interested in contributing to this working group. Do you guys have regular meetings? Will you extend an invite? Have some thoughts I would like to share.

@Cory - Sure, we'll be glad to have your expertise! We don't currently have regular meetings - we tend to just accumulate items and then schedule meetings when they reach a critical mass. Since you're now a member of the WG, you'll get invited to those. That said, if we think a standing open-forum style meeting would be helpful I'm totally open to it.

I've been following Haystack for a while with interest, and I'd like to dive in and start working more on the various definitions. With that, a few comments and questions about airHandlingEquip...

heatPump - @JayHerron said above,

defining a general heatPump tag seems wider than the scope of this discussion, since the term "heat pump" spans airside and waterside systems

With that in mind, is heatPump going to be removed as a subtype of airHandlingEquip? I agree that the current definition is too limiting. For example, what about air-to-water or water-to-water heat pumps?

Has there been any consideration to adding a DOAS (dedicated outside air system) as a subtype of ahu? The current definition of MAU: An AHU that brings in 100% outside air and no recirculated air sounds more like a typical dedicated outside air system to me.

While a DOAS typically delivers 100% outside air for ventilation, I would classify an MAU as a specific subtype of a DOAS that delivers outside air as a makeup to an exhaust system (i.e. for a kitchen or other exhaust-driven space).

Lastly, I think it makes sense to have an RTU tag since rooftop packaged units are so,so common, and RTU is such a commonly thrown around term, but the line between AHU and RTU can be kind of murky. To me, an RTU is less a subtype of AHU and more like an attribute of one. An MAU, for example, could easily meet the definition of RTU (outside, unitary) so the terms are not necessarily mutually exclusive.

Seems this discussion thread has pivoted towards humidifiers/dehumidifiers and economizers, but I wanted to get my 2 cents in before it's too late.

Seems like we should start discussions back up again!

Hey Annie,

Thanks for your input and perspective! You make really great points.

I'll schedule an in-person discussion for our working group sometime next week, so keep an eye out for an email invite.

Hey Jay - so on this same topic, would like to also tackle supplemental heating (as is often associated with heat pumps), but in a generic way. Likely we could have two concepts:

• primaryHeatingProcess
• secondaryHeatingProcess

Both of which are of type heatingProcessType. We would have to have an elegant way to structure the tags, or heatingProcess becomes some sort of enum? for discussion.

You got it Cory. I'll add it to Monday's discussion topics. Thanks!

I've always considered the term "system" to be open to include more than one equip. I think this would be the case for DOAS. DOAS could be treated more like a plant where MAU is a child equip but not necessarily a subtype.

Hey Chris,

Thanks for the input! We don't really have an airside system concept equivalent to something like a plant. Do you have a suggestion for a different name for an AHU that delivers 100% outside air, but doesn't have a dedicated exhaust system (in contrast to an MAU, which would provide makeup air for the dedicated exhaust system)?

Also, if you're interested in being involved in these discussions earlier on, feel free to join the working group and you'll get invited to the future meetings. Thanks again!

Hi Jay,

I guess it's just the name "system" that throws me off. I always thing of a system as a group of components. Thinking about it, DOAS is such a common term and it will always be used in that abbreviated form its just fine as tag. Similar in the way haystack doesn't use "unit" for "equip" but MAU works fine as a tag.

Hi all, I am working with the organizing committee for Haystack Connect and we plan to have a series of working group updates. The conference is virtual and taking place between September 13-15, 2022.

Is there anyone on your WG willing and able to present a good update of the latest activity, or the latest thinking, of your working group for the broader community? This is a good way to get more people engaged and to bring new ideas to the forefront. If you see this as a good opportunity to engage the community, please submit an abstract here to speak at the conference:

https://www.haystackconnect.org/speakers/

What's the current status of the AHU WG? Are there any proposals available for review? Do you have regular meetings?

This WG does not meet regularly anymore. Any new AHU work would probably be done within the Labs WG, so I would suggest we close out this WG. Let me know if there any objections.

I think that’s a good idea. I haven’t been driving things much over here and the Labs working group has good momentum. Thanks Brian.