faceByPass A binary or numeric point that would depict the state of face and by pass damper

economizerDamper A binary or numeric point that would depict the state of economizer dampers. As the outside damper opens return damper closes.

freezeStat Binary alarm point that would depict the state of the cooling coil in terms of ice built-up.

fanDiffPressure the differential pressure across the fan // Not that this would be used commonly like a numeric. I have worked on a project where I had to create the alarm logic when the pressure was over certain threshold.

diffPressureFlow Air flow sensors sense differential (velocity) pressure of VAV units and other locations in main or branch ducts

airFlowStation I think you can sense fpm (feet per minute) with this device as a velocity and there is a way to calculate cfm out of it. http://www.scientifix.net/air-flow-conversions.html

Comments are welcome.

Comments:

Regarding faceByPass -- Based on further discussion we can see the following scenario:

faceByPass is a marker tag for a certain type of damper That damper can have a status with a value of faceMode or byPassMode Further, faceMode can have an enumeration of heat, cool, none. These available modes could apply for byPassMode as well in some AHU configurations.

Regarding freezeStat -- this would be a boolean point that would indicate that the air temperature reaching the coil has dropped below a minimum value (often 37 degrees -- although others may want to comment on that)

Regarding fanDiffPressure -- this is used to determine that the fan is running. In the current library the tag dischargePressure has been used to achieve this goal. The typical application is as a boolean point that trips at a certain level to indicate fan operation.

Regarding diffPressureFlow Air I agree with the need to define an flow sensor to sense differential (velocity) pressure of VAV units and other locations in main or branch ducts.

Regarding airFlowStation -- this is typically a multi-point sensing device in the duct that is used primarily to provide a fairly accurate measure of airflow based on the calculation of total pressure and area of the duct.

Based on our conversation on the phone.

economizerDamper - This could be used as a tag that would describe the outside air damper is acting as an economizerDamper where the return damper is in reverse acting of the outside air damper vice verse. If this point is a numeric value, we could calculate the return damper position by subtracting 100 and taking the results absolute value. Please feel free to comment.

Okay, let me try to resolve some of these to a formal proposal...

First off the ones that I believe require more conversation and thought:

• economizerDamper: I think we already have this with outdoorDamper tag. Economizing is one control action which effects outdoor damper, but I believe our model is correct. A typical RTU or AHU has one main outdoorDamper and potentially an auxillary minOutdoorDamper
• diffPressureFlow/airFlowStation: not sure I fully understand this yet enough to curate a formal definition. I am going to post a new topic regarding pressure we can use to continue discussion

Here are things that I feel comfortable making as an official proposal to update the model:

• faceBypass: a boolean point of an ahu indicating air flow is by-passing the heating/cooling elements. If true the unit is in by-pass mode, or if false then by-pass is disabled.
• freezeStat: a boolean point of an ahu indicating a freezing condition which might require a control sequence to protect the equipment. If true then a freeze condition is deteted, or false if not.
• fanDiffPressure: a boolean or numeric point indicating pressure differential across the main supply fan of an ahu. If boolean, then true indicates the fan is on and their air flow, of false if sensor detects the fan is off. If numeric, then the pressure differential should be measured in "inH₂O" or "kPa".

NOTE: as part of this proposal we would also beef up filterDiffPresssure to fully describe bool/numeric values consistent with fanDiffPressure where true indicates successful airflow and false indicates a clogged filter or pressure measured in "inH₂O" or "kPa".

Hi guys,

faceBypass is rarely boolean.

The most common application in our area is a steam preheat coil.

When OATemp is cold (below 35) Steam Valve is open (100%) and we modulate the faceBypass Damper.

When OATemp is warm (above 40) faceBypass is full face (100%) and we modulate the Steam Valve.

Mike Silady - ESI

F'stats: We moved from using this terminology to lowTemperatureSwitch for liability reasons. You might get sued when something freezes.

A f'stat is a temperature switch with a 20' vapor filled capillary that snaps the switch whenever any 6" length drops below 35 degF. Examples: Johnson Controls A70 and A11.

Any single point type or averaging type analog sensor does not provide the same protection.

There are several application issues that must be considered: -1- Auto or Manual reset when the switch trips. There is a place for both. It depends on the location of the switch and whether the faclity is manned 24x7.

-2- Cross Ambient conditions. The switch itself is outside the duct. That area must be conditioned (warm). Otherwise the switch will remain tripped all winter.

-3- What are you protecting? If it's a RTU with DX and gas heat, there is nothing in the unit to protect. The f'stat is not needed.

Mike

Mike,

You are right we need more than a Boolean point to define the faceByPass.

faceByPass is a marker tag for a certain type of damper That damper can have a status with a value of faceMode or byPassMode Further, faceMode can have an enumeration of heat, cool, none. These available modes could apply for byPassMode as well in some AHU configurations.

I don't think there was any actual proposal that freezeStat was incorrectly defined? Was that just clarification about how it was used?

Regarding faceBypass, is sounds like to me just need to make it a boolean or a number 0% to 100% consistent with other dampers?

Hi, here is my first comment on site, hope it'll bring interesting things !

Before commenting, let's just say that I'm a french speaking guy so please, excuse me if it's wrongly written... or too direct ! :0)

In our office, we refere to a dischTempLowLimit instead of freeze stat. It's often set to 5-7degC, far from freezing...

I agree with the comment about faceBypass which are modulating devices.

From my point of view, minOutdoorDamper is not enough precise. It's lacking the term position, it's what it is... a minOutdoorDamperPos. Maybe it's too long though. It could be acceptable to shorten that way minODamperPos.

In our office, we refere to a dischTempLowLimit instead of freeze stat. It's often set to 5-7degC, far from freezing

I have already pushed changes to use the freezeStat tag. Although if there is community agreement that we should rename that tag to tempLowLimit or something else let's do it soon.

From my point of view, minOutdoorDamper is not enough precise. It's lacking the term position

I think in the case of Dampers that the point is always modeled consistently as a "%" position with a unit tag of "%". So seems like the shorter version consistently captures what we want. Obviously we could get very verbose, but think we want to capture short identifiers and leave verbosity in the docs.