Is see there is a new "state" tag in Haystack 4.0, ie. fan run state point (https://project-haystack.dev/doc/proto/fan-run-state-point). This group of tags which define a point do not include a pointFunctionType (sensor, cmd, sp).

Are points no longer required to have a pointFunctionType or will "state" be a new pointFunctionType (it is not currently listed as one)?

Why not just use sensor? fan run sensor point.

-Jon Schoenfeld

I am not sure about the state tag myself. But the basic idea was that most points are paired with a phenomenon and quantity such as:

air + temp
water + pressure
wind + speed
elec + power

These are captured by the pointSubject and pointQuantity choices.

Then we have some control point that don't fit that model, so I was trying to keep a consistent pattern:

state + enable
state + run
drive + freq
drive + speed

Note that state was never intended to be function choice (peer to sensor, cmd, sp), but rather a peer to the pointSubject choice

Like I said, I don't really love it, but might be good discuss if others have thoughts. That pattern started to breakdown as I got further into the various misc points like heatWheel, freezeStat, etc

I see. We've always addressed this as follow:

chiller + enabled fan + run vfd + freq vfd + speed

chiller, fan and vfd are the subject. So for fan status and command points, we have "fan run sensor" and "fan run cmd".

I have similarly, thought the "drive" tag is redundant as it seems only to be applied to vfd's. If one were modeling the AHU without modeling the sub-equips fan and vfd, they would need fan and vfd on these points anyway.

chiller + enabled fan + run vfd + freq vfd + speed

Currently the chiller and vfd tags shouldn't be used on points and are only used at the equip level. We've supported fan/pump to be either equip or point, but at the moment those are the only ones