We haven't actually defined Occ and UnOcc Setpoints yet. We only have a zone and temp and sp, or a zone and temp and effective sp.

zone temp effective sp

Should be used for the current active setpoint

zone temp occ cooling sp

Should be used for the Occ Cooling setpoint

zone temp occ heating sp

Should be used for the Occ Heating Setpoint

zone temp UnOcc cooling sp

Should be used for the UnOcc Cooling Setpoint

zone temp UnOcc heating sp

Should be used for the UnOcc Heating Setpoint

So basically I think you should never just have a zone temp sp, you must also add effective or ( Occ / UnOcc and/or cooling ). Doing it this way would make sure that you never search for zone and temp and sp, and actually find something else.

Would like to nail this down asap, so please give a vote or no vote soon.

Thanks

+1 Looks clean and simple

I think it should be unocc, not UnOcc. But other than that I like that. That will up the zone temp setpoint points listed under AHU and VAV. Might be good to create a special zone setpoint section somewhere to fully document how it all works.

I like the occ/unocc tag addition, but I do believe we need to add a third tag to the proposal to indicate a point that does not represent just occ or unocc. Just as we have a heating | cooling | effective setpoint, where the effective point moves between heating and cooling modes, there is the possibility for a single data point for a setpoint to move between occupied and unoccupied modes.

In our standard, we have selected active to indicate a point that changes value based on occupied or unoccupied mode. See the following document from thread `http://project-haystack.org/forum/topic/101`, for how we had tagged up zone points: https://docs.google.com/document/d/1szo5tQEmUS6CCbH141RVSZ5YB9qIdJzHBTJAejjZoOo/edit#

In our standard, we had selected occupied and unoccupied, but the abbreviated versions suggested above would function just as well.

Examples:

zone temp active effective sp

Should be used for the current active setpoint (always active, heat/cool occ/unocc)

zone temp occ cooling sp

Should be used for the Occupied Cooling setpoint (only active during occupancy and cool mode)

zone temp occ effective sp

Should be used for the Occupied Effective setpoint (switches between heat/cool, only active during occupancy)

stanby should be included.

Stanby is the setpoint a room goes into when schedule is occupied but nobody is in the room. (Wait for real occupancy with a movement detector for example).

Typical transition : Room is unoccupied...goes in stanby in the morning. If someone's detected, goes in occupied.

@Christian +1 for standby to be included. This was a good catch.

@Nicholas I think effective is what you are describing as active. I think we are saying there will only ever be 1 effective sp at a time. So doesn't effective make it so you don't need active.

@Jason +1 for word correction :) standby

@Jason The case for a separate tag comes into effect when you have a point that represents the following:

A cooling setpoint that is active whether the system is occupied or unoccupied.

Without the active tag, this point would be tagged:

zone temp sp cooling

Per the current definition of effective, we couldn't use effective in conjunction with cooling.

Effective Definition: Used to indicate the effective setpoint which takes into account if a unit is operating in cooling or heating mode.

Therefore, if we wanted to find this tag in a system that also contained occ/unocc specific points, we would need to use exclusionary filters:

zone and temp and sp and cooling and not occ and not unocc

I also like the addition of standby suggested by Christian above. The possible tags to indicate a setpoint's schedule dependency would then be one of the following: occ | unocc | standby | active

From what I understand from the active tag, it's a way to tell that this is the setpoint / no schedule used.

zone temp cooling sp tells us everything for simple systems running 24h/7d... adding more tags will just add unneeded layers of complexity

effective should be used on read only setpoints that are resulting from an internal sequence that choose between different writable setpoints (based on a schedule for example)

Adding active to occ | unocc | standby is not required I think.

I don't particularly like the complexity of active either, nor do I really like using such a key term for that use case. At some point you have to know if scheduling is involved, plus you always have effective for the actual setpoint in effect. So pending further discussion on active, if we include a standby to occ and unocc, then you end up with:

effective zone temp sp
occ cooling zone temp sp
occ heating zone temp sp
unocc cooling zone temp sp
unocc heating zone temp sp  
standby cooling zone temp sp
standby heating zone temp sp

Note that the reason I suggested to Jason we use occ instead of occupied is so that occupied is left as the primary tag to identify the schedule itself. Same principle applies to cool and cooling.

I understand the desire to remove complexity where possible and the name of the tag can certainly be changed. However, my only remaining question on this standard is how would you tag the following data points that doesn't result in exclusionary lookup filters:

Zone Cooling Setpoint Zone Heating Setpoint

Example data from a live site:

@ Nicholas

If I understand what you are demonstrating with the data capture is two different things.

1- Mode of operation(state of the equip operation): (Cooling, Heating, Off, Standby(base on a motion sensor), override, Auto)

2-Which sp is taking precedence("effective") base on "state of occupancy"(maybe by a schedule or motion sensor ...): "standby" (this means it is inside the occ schedule but the zone sensor indicates no motion for a time period), "occ" or "unocc".

For me the occ & unocc proposal in this blog works for #2.

What needs to be defined is #1 to cover your suggestion, and I do not think it was fully nailed down by topic #8. I agree with Brian in that "xxxMode" should apply to ahu or rtu(any other?), but it should be more than a boolean because it uses different values:(cooling, heating, off, standby, override, auto).

What you all think about this? suggestions!!!

@ Nicholas I think you are using the active tag to do something on the server side. I think that can be handled without having to define a tag.

zone temp occ sp Would be the cooling setpoint when you are Occuppied.

zone temp UnOcc sp Would be the cooling setpoint when you are UnOcc.

So in your case I think you are saying you would either have 6 points, or you would only bring in the 2 points that are called active. I do understand what you are getting at. I'm thinking though this is something that is custom, and not on every job. Other than some rules being built on this I don't think that it is used for other things like control or alarms etc... I'm just concerned that if we try and tag every single possible point ever, that we will make things too confusing.

That's just my vote. But again I totally see where you are coming from

There are two additional tags that we also use:

vacant cooling temp sp

vacant heating temp sp

for buildings that are "mothballed" for various times of the year.

We typically use this as a "building" level set point and not a "zone" level set point. I don't recall any discussions that differentiate between the "building" level set points and "zone" level set points. I would be interested to see how folks handle this along with "corporate" mandated set points. There are three categories of space temperature set points that we report on (1) corporate, (2) building level and (3) zone level.

It has been quite a while since we have had any discussion on the zone set points.

I would like to propose that we move forward with zone set points as discussed in this post with the addition of the "air" tag to be consistent with what is already formalized in the docs.

These points are fairly universal for VAV and other terminal unit type equipment.

zone air temp effective sp
zone air temp occ cooling sp
zone air temp occ heating sp
zone air temp unocc cooling sp
zone air temp unocc heating sp  
zone air temp standby cooling sp
zone air temp standby heating sp

+1

From what I gather after reading this post, it sounds like we should eradicate active from the standard and stick with using effective to describe an effective heating/cooling setpoint based on effective occupancy (and all other factors such as bias, local warmer/cooler relative adjustment, or local absolute setpoint) or just one effective setpoint as described by Paul Berquist in his post from Thu 2 Apr 2015.

zone air temp effective sp
zone air temp effective cooling sp
zone air temp effective heating sp
zone air temp occ cooling sp
zone air temp occ heating sp
zone air temp unocc cooling sp
zone air temp unocc heating sp  
zone air temp standby cooling sp
zone air temp standby heating sp

If this is true, can the active tag be removed from both the 3.0 and 4.0 tag definitions to stop the confusion?

They are finalized and have been for many years now - see /doc/Zones#zonePoints.

Note that effective is exclusive to cooling and heating - it means the setpoint in effect right now.

Also active has a very specific meaning with regard to energy meters (to distinguish between active, reactive, and apparent power. It is not used with setpoints.

Brian, I appreciate your clarification. Could you please update the definition of active here: https://project-haystack.dev/doc/lib-phIoT/active

I was confused since active is currently defined as "Working, operative, effective" here: https://project-haystack.dev/doc/lib-phIoT/active. I now see that active is define as "Applied to an electrical power point to indicate active power or real power, typically measured in "kW"." here: https://project-haystack.org/tag/active. If it is described to be used only with energy meters and should not be used with heating/cooling setpoints, I don't think there will be any confusion going forward. Thank you!