Ok, I've gone thru the various outstanding proposals and had several phone conversations to try and get things nailed down. The following is summary which I would like to incorporate into the official documentation next week:

Meter Types

We will deprecate the use of tags such as elecMeter in favor of elec meter. New list of meter types:

domestic water meter 
chilled water meter
condenser water meter
hot water meter
makeup water meter
blowdown water meter
condensate water meter
steam meter
elec meter
gas meter

Meter Points

If we take a chilled water meter, it is typical that it will measure both thermal energy and also liquid flow. So what we'd like to do is standardized the tags used for energy usage across the board in elec meters, thermal meters, internal chiller measurements, etc. The new proposed points for meters:

power   unit: kW, BTU/h, tonref
energy  unit: kWh, BTU, tonrefh, m³_gas
flow    unit: gal/min, m³/s
volume  unit: gal, m³, ft³ 

This new design deprecates the following tags:

kw -> power
kwh -> energy
flowRate -> flow  // consistent w/ AHU air flow
flowConsumption -> volume

Run/Enable/Status Standardization

One thing not discussed indirectly, which we have never actually standardized is the point tags used for equipment level on/off state. Based on various conversations I would like to propose:

run cmd     // primary on/off state of an equip such as VFD or chiller
run sensor  // primary on/off status sensor/feedback
enable cmd  // optional 2nd digital input used in addition to run cmd

VFDs/Fans/Pumps

Based on discussions:

• pumps are always modeled as separate equip entity
• fans may be modelled as simple point or equip entity

Point example:

fan cmd point   // Bool or % Number

VFD Equip example:

fan vfd equip
run cmd point
run sensor point
enable cmd point
speed cmd unit:"%" point 
freq cmd unit:"Hz" point 

Chiller Enhancements

Standardize the following point additions to chillers from above:

run cmd point
run sensor point
enable cmd point
load cmd unit:"%" point  // load limit command
load sensor unit:"%" point
power sensor unit:"tonref" point
energy sensor unit:"tonrefh" point

Or we could potentially use speed instead of load, but don't think that really works with established terminology?

I've run this design by a bunch of people on the phone and there seems to be good consensus, but want to post on forum to get any final feedback. Barring any significant discussion on this proposal, then my plan is to update docs late next week.

After talking all day with Brian, I think you got my vote.

+1 for me.

Brian,

couple of small points.

• For the specified list of power units can you please add kWr (kilowatts of refrigeration), for the metric parts of the world (and there's only a few of us I know ;) ) that is a common unit
• For consistency my previous request would indicate that we should also have kWhr (kilowatt hours of refrigeration)
• Really small technicality, but from our experience in chiller plants a chilled water meter will only measure flowRate of water through an evaporator vessel, a thermal energy meter is a different sensing device (and quite expensive for a good quality one!! ) so I just wonder if there needs to be some differentiation so that it doesn't get confused?

Otherwise I think it's a good step forward and a consistent model. I'll let you know if I have any other thoughts.

Cheers, Richard

Per our conversation Brian, +1 from us at the ESI team on the above.

One thing that we have may have overlooked. Is the siteMeter tag going to stay as is? Unfortunately that one we can't just break up due to existing conflicts.

So as not to point out a problem without a potential solution, I'd like to propose main as an alternative tag to siteMeter.

For the specified list of power units can you please add kWr

Yeap, will do

One thing that we have may have overlooked. Is the siteMeter tag going to stay as is?

Yes, I think siteMeter and submeterOf continue to work exactly as they do today, no changes there. I personally think siteMeter is a more accurate and specific term than main, but I would like to hear other opinions

+1. Brian, thank you for putting it all together.

The only point for potential change is with the flow tag. As defined this is volumetric flow rate. The haystack unit file also includes entries for mass flow rate. If we are defining flow as being volumetric, should we have a discussion about how to handle mass flow rate? I don't think we need to go in the direction of volumetric flow and mass flow. With mass flow rate being an oddity in this industry it make sense to maintain the current proposed flow in the interest of simplicity and consider adding mFlow or something similar in the future if the need arises. There probably doesn't need to be a decision made on this side topic in the near future, but with setting this new standard it is important that we cover all of the bases.

If we are defining flow as being volumetric, should we have a discussion about how to handle mass flow rate?

My question would be, is there ever a case where you would be measuring the two at the same time? It seems to me that you would just have a flow point with the appropriate mass or volumetric point.

I don't foresee ever attempting to measure both at the same time. If mass flow rate was needed, it is normally accomplished by density compensating volumetric flow. If this is done in a single meter, the meter would output mass flow and not the component parts.

I understand that the two can be differentiated by the unit tag but if we go down that road, most measurements tags (temp, pressure, etc.) can be inferred by their units.

I raised the question because the above definition is: flow unit: gal/min, m³/s which is a volumetric flow definition. It did not appear "mass flow rate" inclusive but I don't know that it needs to be.