I am working on a site design and my brain keeps getting caught in circular logic.
We have several points that are tied to occupancy.
We have an Occupancy point, that indicates if the HVAC systems are treating the zone as Occupied or not.
We also have Heating and Cooling Setpoints we want monitored for the Occupied states as well as Unoccupied states.
The occupied tag seems fine for the Occupancy point, just identifying it as the Occupancy Command, but for the 4 Heating/Cooling Occupied/Unoccupied points, how should I identify them? Should I just treat occupied as a bool in this instance instead of a marker and just use true or false?
Brian FrankSun 27 Jan 2013
Really the occupied tag was designed for the actual schedule occupancy - true when occupied and false when unoccupied.
To be honest, I'm not sure how to best model the four "setpoints" of a zone. We have
zone air temp cooling sp
zone air temp heating sp
Would you have combinations of those with occupied and unoccupied? Or would it just be simpler to trend when those setpoints transition their setpoint value from occupied to unoccupied? In that case the configuration might just be tags on the points.
Probably a nasty modeling problem to iron you...
Tommy FarleyMon 28 Jan 2013
It's something that needs to be monitored for this site. The data is going into SkySpark and they want the ability to create sparks around those setpoints ever changing.
Am I also correct in reading that occupied would not be well suited for an Occupancy Mode Command?
Brian FrankWed 30 Jan 2013
Am I also correct in reading that occupied would not be well suited for an Occupancy Mode Command?
I think if you had a command to set mode to occupied to unoccupied that tag would be perfect by combining occupied sp.
Or were you thinking of some enumerated mode string?
Chris VintinnerWed 15 May 2013
Does the occupied tag refer specifically to the schedule? I have run into confusion with these terms within our own systems. A space can be "occupied" per the schedule but may be "unoccupied" based on a occupancy sensor in the space.
Brian FrankWed 15 May 2013
Right now the occupied tag refers to the schedule occupancy mode and occupancyIndicator refers to an actual sensor in the space.
Christian TremblayWed 15 May 2013
We handle this situation this way. When schedule is occupied, space become standby. If occupancy sensor detects someone, space become occupied. If schedule is unoccupied, space is unoccupied.
You can also deal with temporary occupancy when schedule is unoccupied and space become occupied.
This allow us to deal with 3 setpoints. Unoccupied,standby,occupied. Standby will be about 1degC from occupied setpoint so it will be easier for the system to get back to setpoint when sensor detects occupancy.
Tommy Farley Sun 27 Jan 2013
I am working on a site design and my brain keeps getting caught in circular logic.
We have several points that are tied to occupancy.
We have an Occupancy point, that indicates if the HVAC systems are treating the zone as Occupied or not.
We also have Heating and Cooling Setpoints we want monitored for the Occupied states as well as Unoccupied states.
The occupied tag seems fine for the Occupancy point, just identifying it as the Occupancy Command, but for the 4 Heating/Cooling Occupied/Unoccupied points, how should I identify them? Should I just treat occupied as a bool in this instance instead of a marker and just use true or false?
Brian Frank Sun 27 Jan 2013
Really the
occupied
tag was designed for the actual schedule occupancy - true when occupied and false when unoccupied.To be honest, I'm not sure how to best model the four "setpoints" of a zone. We have
Would you have combinations of those with
occupied
andunoccupied
? Or would it just be simpler to trend when those setpoints transition their setpoint value from occupied to unoccupied? In that case the configuration might just be tags on the points.Probably a nasty modeling problem to iron you...
Tommy Farley Mon 28 Jan 2013
It's something that needs to be monitored for this site. The data is going into SkySpark and they want the ability to create sparks around those setpoints ever changing.
Am I also correct in reading that
occupied
would not be well suited for an Occupancy Mode Command?Brian Frank Wed 30 Jan 2013
I think if you had a command to set mode to occupied to unoccupied that tag would be perfect by combining
occupied sp
.Or were you thinking of some enumerated mode string?
Chris Vintinner Wed 15 May 2013
Does the occupied tag refer specifically to the schedule? I have run into confusion with these terms within our own systems. A space can be "occupied" per the schedule but may be "unoccupied" based on a occupancy sensor in the space.
Brian Frank Wed 15 May 2013
Right now the occupied tag refers to the schedule occupancy mode and occupancyIndicator refers to an actual sensor in the space.
Christian Tremblay Wed 15 May 2013
We handle this situation this way. When schedule is occupied, space become standby. If occupancy sensor detects someone, space become occupied. If schedule is unoccupied, space is unoccupied.
You can also deal with temporary occupancy when schedule is unoccupied and space become occupied.
This allow us to deal with 3 setpoints. Unoccupied,standby,occupied. Standby will be about 1degC from occupied setpoint so it will be easier for the system to get back to setpoint when sensor detects occupancy.