Haystack uses the “mode” concept with the vavMode tag.

I found an ahuMode tag useful on a current project that reports enumerated strings such as Auto, Heat, Morning Warmup, Cool, Night Purge, Pre-Cool, Off, Test, Emerg Heat and Fan Only. Has anyone considered expanding the vavMode concept to include other points reporting Enumerated Strings such as boilers, chillers and air handlers?

• boilerMode
• chillerMode
• ahuMode

Good idea, but a group would need to put together a proposal for those enumerations which we think were used across all AHUs, chillers, etc. I would think that part might be kind of hard to standardize

It will be hard to find something that fits every manufacturers... Some will use different terms... others will choose different enum values for the same state... (ex. occupied = 0 for some, = 1 for others...)

I would suggest taking the "custom" approach... where someone could create "facets" based on the specific controller being monitored. Then those facets could be used by haystack to give a name to the different enum states.

I agree that a standard enum list is not feasible. Even a simple fcu may have different enumerations between manufacturers.

Maybe the most efficient way to handle enumerated points is with a "flag" pointing to a "facet" instead of creating a mode "tag".

The terminology and enum value used by every manufacturer is no boudt very different, however often the actual definition of the modes are very similar. I wonder if we could make a standardized list of modes and provide a tag that contains the information to translate the point facet mode to the standardized mode?

As I look at the different manufacturer's "objects" and descriptions of enumerations, it appears that they use the terms "status", "state" and "mode" interchangeably. Am I missing something? Is there a technical difference between these terms?

I had additional thoughts on this thread after thinking about the proposed alarm and status tags.

Enumerated strings that cross all manufacturers is not a currently realistic goal for me, but using state and mode and status in a common way is.......and this is what I am currently experimenting with:

• status - tag associated with a boolean point used to indicate an alarm is on/off, true/false, etc
• mode - an Enumerated String which specifies an operating mode such as occupied, standby, bypass, prepare to heat, prepare to cool, prepare to dehumidify, dehumidification, fan only, reheating etc
• state - an Enumerated String which describes a condition. As example we may currently receive alarm conditions reported as (1) Compressor #1 High Pressure, (2) Compressor #2 Low Pressure, (3) Room Temp Sensor Fail, etc.

As Christian suggested folks could use facets to standardize across different manufacturers if they found it beneficial.

I would be great to hear anyone else's experience with this subject.

I've imported points from building control systems from over 200 buildings programmed by over 2 dozen controls contractors. Manufacturers and contractors are anything but consistent in how they name points and the semantic use of points.

I think we have to be careful with the terms and potential tags "status" or "state". They are nebulous terms at best. Status points are very commonly used in conjunction with command points to indicate "proof of run". Being able to identify these "proof of run" points is critical to many rules. I use the tags "run" and "cmd" to indicate points that command equipment on/off. I use the tags "run" and "sensor" to indicate "proof of run" points. I use the tags "run" and "enable" to indicate software points the logically take equipment out of service for maintenace or repair. Some contractors use this technique to bypass equipment in lead/lag logic.

I would not be in favor of using the "status" tag to indicate alarm status. I think an "alarm" tag on a Boolean point would be an effective way to indicate a point that represents an alarm. An "alarm" and "sensor" tag combination just doesn't feel right for an alarm. In my mind, sensors relate to hardware points, not logical conditions. The point would require other tags to identify the alarm context. I would suggest using tags like ("high", "pressure") or ("low", "temp"), etc. like any other point that requires multiple tags to define its context.

I've tried to deal with enumerated strings and find them to be very difficult when it comes to importing into SkySpark. They typically come in as number values that need to be translated to their string value for human consumption in SkySpark. The only effective way I have found to do this is at data acquision time, either through the connector curConvert or hisConvert or onHisWrite. It would be much more convenient if the enums could be brought into SkySpark as their raw values and converted to string values in real time during the hisRead. I'm not sure what the performance hit would be for this, but the late binding of text strings to enum numeric values would make importing cleaner and provide a lot of flexibility post import implementation. Could this be accomplished with an enumDef tag on a point? Or an enumDefRef to an enumDef in the enumMeta record? Or a hisReadConvert that works like hisConvert?

I would like to make a strong argument for a "mode" tag that is a marker, not an enumerated string. Converting enumerations should be left to the enumDef functionlity. I think manufacturer enums that are a fixed list and are mutually exclusive modes should be tagged as cmd points. In essence, they are commanding a piece of equipment to only one condition at any given point in time. I see this as no different than a fan speed command that commands a fan to a numeric percentage. It can only be at one percentage at a given point in time. The same logic applies to contractor created, mutually exclusive enums.

I would like a "mode" marker tag to use on a Boolean point to tag points that don't command specific equipment on/off but indicate current intent within a larger system. I work with some high end buildings where the air handler can be in several modes simultaneously. For example, an air handler might be in de-humidification mode and IAQ mode at the same time. A building could be in economizing mode and IAQ mode at the same time. A building could be in economizing and humidification mode at the same time. These simultaneous conditions cannot be modeled in a single mode enum. Some of our contractors are adding these points on new buildings to better facilitate SkySpark rules for commissioning. (Like why are the heating and cooling valve open at the same time? It's ok if we are in dehumidification mode. Or why is the outside air damper open if we are not in economizing mode? It's ok if we are in IAQ mode.) Bringing these points in from the building controller eliminates the need to duplicate the logic in SkySpark to derive the mode. (which probably wouldn't be consistent from contractor to contractor and I may not have all the points in SkySpark that I need) I've been modeling these points as "cmd" and "mode" to distinguish them from "cmd and "run" points. Adding "mode" as a standard dictionary tag would help standardize this concept in the industry.

Sorry for the long post. I've struggled with these issues trying to get it to work within the standard tagging model. I think adding "alarm" to the current basic list of "cmd", "sensor" and "sp" would be a great expansion of the tagging model. I would avoid adding "status" and "state" as standard dictionary tags. I think they are just too nebulous.

Paul, Thanks for your insight.

I have had good luck with the run cmd and run sensor tags. I haven't used run and enable together yet, but I see benefits to using them.

I agree the alarm sensor doesn't feel right.

Most of the work that I do is NOT SkySpark related, so I am not fluent in the all of the SkySpark references, but it is good feedback.

Your reference to fan speed makes me think the cmd and mode tags could be used together like damper cmd to represent either a boolean position or a % open/closed position...............which makes me think a collection of tags such as heatPump alarm can be either boolean or enumerated.