HVAC

Suggestions

1. Adding the point levelCo2. Important to decide minimum fresh air policy
2. Adding the point outdoorTemp. Sensor used for freecooling
3. Adding the point status, for simple On_Off state

Questions

1. There is the point minOutsideDamper that refers to a secondary damper point to ensure proper level of fresh air. Is that for the setting of minimum fresh air, or do we need another point for that?
2. In many cases like network thermostats, the zoneTempSp is separate for cooling and heating. How do you deal with that?
3. Currently there is cool and heat as separate binary points. Again many units have one point like "mode" returning cool, heat and sometimes dead zone etc.

Elec

Suggestions

1. Adding the powerFactor point

Questions

1. We usually log also voltage and current values. Should those points also get on the list?

Please note that the waterMeterLoad point is missing from the list in the TAG page.

This is great feedback Thanos!

Adding the point levelCo2. Important to decide minimum fresh air policy

Is this point commonly found on AHUs?

Adding the point outdoorTemp. Sensor used for freecooling

We have weatherTemp which associates a site with current weather conditions including temperature. So the question is how often a sensor is dedicated to a single (or multiple) AHUs? Should we model this differently as a point associated only with one AHU?

Adding the point status, for simple On_Off state

Do you mean the state of the overall AHU unit? I think the issue with that is determining what it means. Often you say a unit is "on" if the Fan or any of its cooling/heating elements are active. Or maybe this is some soft point in the controller which is the current desired mode?

There is the point minOutsideDamper that refers to a secondary damper point to ensure proper level of fresh air. Is that for the setting of minimum fresh air, or do we need another point for that?

The intention of minOutsideDamper was the actual position of the damper 0% to 100%. I think the actual target min fresh air might be something separate, but what is that exactly? Is that a configuration soft point in the controller? Just a design spec on the unit?

In many cases like network thermostats, the zoneTempSp is separate for cooling and heating. How do you deal with that?

This is a good point, I am not familiar with this model. Are these stats actually different physical devices and points? Or do you just mean that we have different target SP for cooling and heating modes? Which sort of leads into your next point...

Currently there is cool and heat as separate binary points. Again many units have one point like "mode" returning cool, heat and sometimes dead zone etc.

We've gone back on forth on this one ourselves. In general there is an actual actuator for cooling and heating which is always separate (maybe not modeled in the control device). So I think it makes from an analytics perspective to model cool and heat separately even if this must be derived from the mode point. Which then leads to the question does "target mode" deserve to be a first class point? My understanding is that this is often really just a real-time calculation of the control unit and isn't necessarily consider a real "point". Can others describe how the view the target mode?

Adding the powerFactor, voltage, current

Yes we need these but I am not qualified to fully define them. Can someone take a stab and formal definitions of these points under an elecMeter including a) what units should be used and b) description of exactly what the point should mean?

Great site, love what you're doing here!

Wouldn't be better to use the terms zoneCO2 and returnCO2 as these match the syntax used for the temperature tags? AHU's will typically use these inputs to reset the minimum amount of outdoor air the unit is bringing in (vs. return air).

In regards to the outdoorTemp/weatherTemp points, I've typically seen a single outdoor temperature/humidity sensor used globally for all AHU's within a building and/or campus. Packaged rooftop units would typically be where you'd see individual outdoor temperature sensors.

The term status is a bit ambiguous when used on an AHU as there are multiple modes it could be running in such as: Heating, Cooling, Economizer, Fan-only, Off, etc. Perhaps ahuMode instead?

For HVAC equipment that can run in a more binary fashion, such as fans and pumps, a status indicator could be statusOnOff

Depending on the additional sensors/equipment installed on the AHU, it may be able to read the outdoor air CFM coming into the unit in addition to the damper position. minOutsideCFM would be a good tag to add for this situation.

Zone Temp: The physical thermostat may be the same, it's just the programming that's different. There would typically either be a single setpoint with a variable amount of bias or separate heating and cooling setpoints. Tags for the second scenario could be zoneTempHtgSp and zoneTempClgSp'

Great input on AHU related stuff. I have a question though. regarding:

"Depending on the additional sensors/equipment installed on the AHU, it may be able to read the outdoor air CFM coming into the unit in addition to the damper position. minOutsideCFM would be a good tag to add for this situation."

To me minOutsideCFM would be a setpoint I was trying to achieve. Would't the sensor measuring outside air CFM be better tagged as something like outsideCFM?

Yep, I see your point. How about minOutsideCFMSp for the setpoint and outsideCFM (as you suggested) for the sensor value.

I think those work well. We need them both.

heatWheel What do you think for a tag for heat wheel so we can compare supply return temps when the heat wheel is on? It would be like an occupancy tag.

I agree with the use of the tag "statusOffOn" It should be used specifically in association with a fan or pump (as opposed to commanded value) and as a feedback from the equipment.There are many pieces of equipment that are controlled from local thermostats or equivalent sensors. Similarly items such as freeze-stats or high limit sensors may be observed by using a similar status point "ststusNmlAlM" Status normal or alarm. In addition too heat-wheels there are other types of auxiliary sub-systems that accomplish equivalent energy recovery measures, such as heat pipes or run around systems using or water/glycol to transfer energy from exhaust to entering sir. The run around systems typically have a coil circulator therefore the pump status would serve as the operational state of the run around system.

We have a need to identify the type of load on an elecMeter for SkySpark rule writing (HVAC, Plug & Light Load, Exterior Lights, Tenant, etc.) We want to include only meters with a specific load type in certain rules. My question is whether this should be a marker or a string field with enumerated values? In either case, should we have standard names for the different types of load?

We will have a similar need for a waterMeter (Irrigation, Domestic, Cooling Tower, etc.)

My question is whether this should be a marker or a string field with enumerated values? In either case, should we have standard names for the different types of load?

Great comments. I think these would be additional marker tags on the load equip itself. We already have hvac and lighting tags to indicate equip associated with the HVAC and lighting systems respectively.

We have not standardized more refinement in lighting such as interior, exterior although that seems like a pretty obvious direction to go.

No work has been done to standardize tags on the water systems like irrigation or chilled water systems.

But I think the key take away is that those sub-categories are really further modeling in the appropriate vertical domain: hvac, lighting, irrigation, chillers, etc. They aren't necessarily associated with the energy model per se.