I am a bit new to the haystack project, and I looked at all the docs and tags documentation available on the site. But I'm not sure if my understanding is right. Sorry for the novel-type question but wanna give more details than less.

Say that I have 10 roof-fans that I want to monitor their electrical consumption(kJ). So I have to calculate the fan motor power(kW) via an analog input (frequency reading) on the VFD of the fans. Than measure how much time it will work and I will than be able to measure fan consumption and maybe compare every fans to see if their is a big difference between them and be aware that something is going wrong.

My understanding for tagging the two measuring points would be: VFD Hz sensor: equipRef(different for each fan) point sensor fan freq On/Off sensor: equipRef point sensor fan curStatus

The On/Off sensor give 0 or 1 if the fan work or not and is on a time base so I can get my fan working time.

Am I missing something? What if I want to do the same thing with a pump? Just remove fan tag or I can use the tag pump?

I want to simplify as much as I can the programming job with the tags I give to my points cause we have almost have 2000 measuring points. To monitor roughly 80-100 electrical consumption.

Thanks for your help

There hasn't been a firm decision on whether to model VFDs as their own equip or to just use points on the RTU level. And I think it sort of depends on how many points you would want. I would suggest you start off simple. Here is a simple model of an RTU with those three points:

id: @RTU3
equip
ahu
rooftop
siteRef: @x

id: @RTU3-Fan
point
fan
cmd
kind: "Bool"
equipRef: @RTU3
siteRef:@x

id: @RTU3-Demand
point
kw
sensor
kind: "Number"
unit: "kW"
equipRef: @RTU3
siteRef:@x

id: @RTU3-Freq
point
freq
sensor
kind: "Number"
unit: "Hz"
equipRef: @RTU3
siteRef:@x

My vote is for pumps, fans, etc... to mark them as another equip. I would say if there are more than 2 points make it it's own equip, with a equipRef->ahu.

IE... If you just have a command, and a status then keep it just points under the main equip. This will basically mean if it's a VFD then it will be it's own equip.

I agree with Jason about modelling fans as separate equipment, using an equipRef tag to connect a fan to its owner. We have started doing this with all of our fans and it really cleans up the data model, especially with VFDs. These fans end up with a large number of points, so grouping them as a separate equipment object makes a lot of sense. We are modelling the following points for VFD fan objects:

Discharge Fan Command
Discharge Fan Alarm
Discharge Fan Bypass
Discharge Fan Consumption
Discharge Fan Current
Discharge Fan Demand
Discharge Fan Entering Pressure
Discharge Fan Fault
Discharge Fan Frequency
Discharge Fan Leaving Pressure
Discharge Fan Override Command
Discharge Fan High Pressure Alarm
Discharge Fan Low Pressure Alarm
Discharge Fan Speed
Discharge Fan Speed Status
Discharge Fan Speed Override Command
Discharge Fan Speed Setpoint
Discharge Fan Status
Discharge Fan Torque
Discharge Fan Voltage

We also decided that even if a fan has a single status point, it should be an equipment object to keep our data model consistent, regardless of the available points.

Note: We are modeling pumps as their own equipment as well.

Brian... I agree with Nicholas, let's put this up for a vote, but I'm on board. I think we also should make sure we have all of his options above as well.

Nice job Nicholas, looks good

Fans, pumps as equip gets another vote. We should have this settled in. ;)

Great job Nicholas.

Just clarify,

We will have nested equips. fan under ahu which both of them are equips.

Fan will have equip tag which will be attached to another equip with ahu marker.

If the fan is type vfd, it will get the marker vfd on top of equip and fan.

Points related with fans and vfds will be listed under a record with equip, fan and vfd marker.

I posted a pastebin.

Does this look ok?

http://pastebin.com/crSPhEnB

The point list above was just for display names, but we're more than willing to share our tagging convention for the points above as well:

navName                   kind        Marker Tags
------------------------------------------------------------------
"Command"                 "Bool"      status cmd   
"Alarm"                   "Bool"      alarm sensor   
"Bypass"                  "Bool"      bypass sensor   
"Consumption"             "Number"    kwh sensor   
"Current"                 "Number"    current sensor   
"Demand"                  "Number"    kw sensor   
"Entering Pressure"       "Number"    entering pressure sensor  
"Fault"                   "Bool"      fault sensor   
"Frequency"               "Number"    freq sensor   
"Leaving Pressure"        "Number"    leaving pressure sensor  
"Override Command"        "Bool"      status ovr   
"High Pressure Alarm"     "Bool"      pressure high alarm sensor 
"Low Pressure Alarm"      "Bool"      pressure low alarm sensor 
"Speed"                   "Number"    speed cmd   
"Speed Status"            "Number"    speed sensor   
"Speed Override Command"  "Number"    speed ovr   
"Speed Setpoint"          "Number"    speed sp   
"Status"                  "Bool"      status sensor   
"Torque"                  "Number"    torque sensor   

These points are then attached to fan equipment which is modeled as follows:

id: @dFanExample
navName: "Discharge Fan"
discharge
equip
fan
hvac
horsepower: 5hp
equipRef: @ahuExample
siteRef: @siteExample

We currently model 6 different locations for fans:

• discharge
• hotDeck
• coldDeck
• return
• exhaust
• outside

For terminal units, as we are looking typically at 0 to 1 fans, we model the fan as a discharge fan.

We are not currently using a vfd tag, but I would be open to the addition.

How much of those Fan VFD points could be reused for a VFD pump?

So regarding the pivotal question: should a fan/pump be modeled as a point or a sub equip? The options to vote on:

1. Always flatten them into the parent equip (fan points get merged into AHU, VAV)
2. Always model them as separate equip
3. If its only one point (fan on/off) then flatten into parent equip, otherwise break it out into a separate sub-equip
4. Leave it as discretion of integrator

Jason's suggestion is for 3, which I sort of like that. There are tons of simple cases, especially with Fan powered VAVs where pulling it out as a separate sub-equip entity seems drastic. But in an AHU with multiple VFD fans it would be crazy to flatten the points.

Maybe we could say.

AHU is always #2. Since code will follow the equip.

VAV, FCU #1

We could say this approach fits the best, but we could leave it to the integrator.

If the fans are only start/stop, they could choose the #1 but I like the concept of keeping it separate equips, no matter what. This way tags are coherent between equips of same type and different projects.

To simplify :

* If the equip might have a vfd, choose #2

* If the equip will never have a vfd, choose #1

Great conversation guys, awesome input by everyone.

Couple of comments.

I'm going to vote for Option #2 to keep consistency in the modelling. It's hard enough to keep models consistent as is, so even for simple cases I would prefer to keep it with an extra level of abstraction in the model.

However....I am concerned with the idea of modelling an AHU fan as a separate piece of equipment, mainly due to the fact that it does add an extra level abstraction.

Now, I know I've just contradicted myself (and you don't want to know how long I went back and forth on this one for!!) but it's down to the real world experience of flatter models being easier to work with when dealing with large and complex data sets.

Funnily enough I don't have the same concern with pumps. Pumps in a plant room definitely seem like their own piece of equipment, and we have extensive experience modelling them this way in PlantPRO.

Maybe it has something do with the fact that the fan sits inside of the AHU so to me (being a non-mechanical person) I see a box with everything related to the equip being self-contained, therefore it appears as one piece of equipment.

The more levels in the "equip" tree you have the more you have to worry about traversing the tree when dealing with a Haystack database implementation (like SkySpark).

So I'm voting to go ahead with Option #2 but just wanted my comments noted as part of the conversation.

@Brian - Yes, all of the points above are also re-used in our vfd pump tagging standard. This is one of the benefits of using the equip object for pumps/fans as we can re-use the same navName property and just inherit the equipment name to further define the point.

It was probably clear in my text above, but my formal vote is for #2 in all cases, even for very simple fans.

Primary Reasons:

• Point Grouping
• Code Simplicity (query is always: point and equipRef->fan and equipRef->equipRef == @targetId )
• Fan Meta-Data (horsepower, age, etc)

Pumps

I agree with Brian's option #2, pumps should always be their own equipment.

As for fans...

Option #2 seems to make sense for complex fan arrays and for systems where you have every VFD point known to man. In the case of a simple constant-speed AHU, it may be overkill, but worth it to maintain consistency. For fan-powered VAV's, I'm not convinced.

I think we should draw the line at AHU's. Meaning, if an equip has an ahu tag, it is defined as having at least one nested fan equip (option #2), which is where VFD points would live. Everything else with a fan (VAV's, unit ventilators, leaf-blowers, etc.) we leave as option #4, for now.

I am going to suggest move this discussion to 166 to get finalization

Something that seems to be missing in the fan discussion is modeling a fixed multi-speed fan. I have a number of FCUs with fans that operate at three speeds, low, medium and high. What is the correct tagging for this type of fan control? Should I use the speed tag even though that typically represents a value of 0-100% on a VFD? Should the speed definition be expanded to indicate either a 0-100% or an enum of fixed levels? Is there some other tag I should be using?

Speed feels like the right tag if it's type can be overloaded.

Should I use the speed tag even though that typically represents a value of 0-100% on a VFD? Should the speed definition be expanded to indicate either a 0-100% or an enum of fixed levels?

My opinion: even when you have fixed speeds, they should be mapped to percentages:

slow= 50%
fast = 100%

Or if three speed:

low = 33%
med = 66%
fast = 100%

The advantage there is that everything is normalized to percentages which seems a lot easy to work with the data regardless of how the speed was controlled.

I agree, enumerated speeds should be expressed as percentages.

However, we should consider that the terms slow/fast or low/med/high are often used as a fan's status instead of on/off.

In response to the use of % speed for low/med/high does it make sense to try to match the % as closely to what the % of full CFM would be? I'm specifically thinking about PTAC/PTHP applications where low would map to ~60% of high.