Looking at the current Haystack 4 docs I'd like to verify if I interpret the use of these tags correctly, and I have a few questions.

For many kinds of equips we can use the run cmd point to model the on/off Bool command sent to the equip and run sensor point to model the actual or measured status (also on/off Bool). Optionally the enable cmd point to model a secondary condition for the system to run.

Q1: If an equip has separate heat and cool commands, I assume the equip gets two points: heat run cmd point and cool run cmd point. Is this correct?

Q2: Haystack 4 defines both run and enable as "quantity of state". Is state then a required tag on all these points as well, or implicitly applied?

Some systems provide a status as a binary or numeric value that indicates different modes of operation. That can be 1-10 or 2/4/8/16 or something else entirely. We like to store this data in a point as well, and translate it to the run points above to have Haystack-compatible points.

Q3: Storing the "raw" data as provided by the BMS, could we use state cmd point (without the run or enable) to model this? I deduced this from the definition of state in Haystack 4: "This phenomenon is used as a catch-all for points which don't directly sense or control physical phenomenon." (btw I read there was some discussion about the state tag before: https://project-haystack.org/forum/topic/785)

If an equip has separate heat and cool commands, I assume the equip gets two points: heat run cmd point and cool run cmd point. Is this correct?

Take a look at the children points under coolingCoil and heatingCoil respectively. You can also see these points expanded out in the prototypes such as discharge coolingCoil equip.

Specifically the two points would be for cooling would be:

// if its a valve control
chilled water cool valve cmd point

// if its a boolean control
stage:1 cool enable cmd point

However, now that you have asked the question I think that is incorrect. We should prefer the run tag to the enable tag if we wanted to be consistent with how motors are defined. So unless I hear objects, I'll make that change.

Haystack 4 defines both run and enable as "quantity of state". Is state then a required tag on all these points as well, or implicitly applied?

I've remove that for 3.9.10. We never had it in Haystack 3, and in Haystack 4 it was an attempt to try and model control points similar to substance sensors and setpoints. But I think it was awkward and didn't really add much value. So at the moment its pretty much like we've always had it, just using run and enable without a state tag.

Thanks Brian. For my example I'm searching for the correct tags that apply to an equip as a whole.

For example a heatPump may be controlled in heating or cooling mode with 2 Bool points. I expect a heat run cmd point and cool run cmd point that model the command and optionally a heat enable cmd point and cool enable cmd point as secondary condition before the system is considered "on".

For me, the current definitions of run and enable are very useful as they are (assuming I interpret this correctly).

The state tag I agree is not really necessary. Although I am looking for a way to store the "raw" data I mention in my Q3 and it seems like a good candidate.

I expect a heat run cmd point and cool run cmd point that model the command and optionally a heat enable cmd point and cool enable cmd point as secondary condition before the system is considered "on".

Exactly, I think that is perfectly in line with how we defined those points for VFDs.

Storing the "raw" data as provided by the BMS,

So what exactly do you mean by "raw" data?

The "raw" data is any kind of data that is supplied by the BMS that details the operating mode of an equip. This can be an ahu, heatPump or many other types of equips. The source data can be numbers or strings, and we have seen systems with these kinds of data:

• 1/2/3/4/5/6.../n
• 0/2/4/8/16/32.../n
• "on","off","automatic","manual override","emergency", etc

Of course we can convert this data directly to run and enable compatible data and only store that in our platform, but then we lose quite some information. So I'm looking for a way to properly tag these kinds of points.

Hope this makes sense.

I have always found the "state" tag to be ambiguous and confusing and avoid it. Does state mean proof of run, alarm, available, not available?

For feedback data or proof of run points I always use "sensor". For example:

fan run cmd
fan run sensor (proof of run, typically Boolean)
fan speed cmd
fan speed sensor (speed feedback)

xxx valve cmd
xxx valve sensor (position feedback)

Ideally, "enable" should be used as you define above, enabling the equipment but not necessarily commanding it to run. (although many contractors name points "enable" that are actually commanding the unit to run.)

boiler enable cmd  (Boiler can be commanded or should managing itself)
boiler run cmd     (Boiler being explicitly commanded to run)
boiler run sensor  (feedback the boiler is actually running, could be Bool or fire rate)

To finish out this topic of interfacing with equipment, I think it would be very useful to have an "alarm" tag to track alarm points. I have clients who want sparks at the analytics level when alarms are happening frequently.

For example:

fan alarm sensor
xxx valve alarm sensor
boiler alarm sensor

This facilitates bringing in the alarm and not needing to duplicate the run cmd and run sensor mismatch logic in SkySpark. It also allows you to verify the contractor implemented alarming by comparing all three points in SkySpark.

For feedback data or proof of run points I always use "sensor". For example:

Paul's write-up is exactly how it was designed - to pair the cmd with a sensor point for the feedback/status.

To finish out this topic of interfacing with equipment, I think it would be very useful to have an "alarm" tag to track alarm points.

There are several efforts to beef up the point prototypes and alarm is one of the tags identified we really need since fan alarm is so common (and other cases).

Thank you both for clarifying, this makes a lot of sense and helps us along. And I very much support the idea for an alarm definition. That will be very useful indeed.

For a situation where an equip can be either off/heat/cool I conclude that there are two options to model the on/off state:

1. With two points: heat run sensor and cool run sensor that are both Bool
2. With one point: run sensor that may store data e.g. 0/1/2 with an enum to off/heat/cool

The "raw" data I referred to has no Haystack-compatible solution for now. So I think we will resolve this in using a custom conjunct tag that identifies it as a raw version of a point (e.g. runRaw). If we simply add another tag any references to the run sensor are ambiguous, so that's my reason to model it this way. Any thoughts on this matter are very welcome of course.