Closed connorjcantrell closed 2 months ago
I like the additional refinement, even though I prefer a shallow hierarchy rather than a deeper one, and the new names are better.
I think of deadband as an additional parameter to a threshold calculation, so in the case where a deadband is manipulated to allow for "tight" or "loose" control there might be some additional range that the deadband is expected to vary between, but is there going to be an alarm when the deadband exceeds some value?
I thought Time Setpoints where things like minimum/maximum on/off time, but looking at the version 1.3 hierarchy they are something different.
Hi @gtfierro,
I'd like to move forward with this PR, but want to get your feedback first. Here are a few options we could consider:
In this approach, we would avoid restructuring existing class hierarchies and add one of the following classes as a parent:
setpoints = {
"Setpoint": {
"subclasses": {
"Target_Setpoint": {},
"Threshold_Setpoint": {
"subclasses": {
"Upper_Threshold_Setpoint": {},
"Lower_Threshold_Setpoint": {},
}
},
"Pressure_Setpoint": {
BRICK.hasQuantity: BRICK.Pressure,
"parents": [
BRICK.Target_Setpoint,
],
"subclasses": {}
},
"Cooling_Temperature_Setpoint": {
BRICK.hasQuantity: BRICK.Temperature,
"tags": [TAG.Point, TAG.Temperature, TAG.Setpoint, TAG.Cool],
"parents": [
BRICK.Upper_Threshold_Setpoint,
],
"subclasses": {}
},
"Heating_Temperature_Setpoint": {
BRICK.hasQuantity: BRICK.Temperature,
"tags": [TAG.Point, TAG.Temperature, TAG.Setpoint, TAG.Heat],
"parents": [
BRICK.Lower_Threshold_Setpoint,
],
"subclasses": {},
},
# etc.
}
}
}
setpoints = {
"subclasses": {
"Pressure_Setpoint": {
BRICK.hasQuantity: BRICK.Pressure,
"tags": [TAG.Target, TAG.Pressure, TAG.Setpoint],
"subclasses": {}
},
"Cooling_Temperature_Setpoint": {
BRICK.hasQuantity: BRICK.Temperature,
"tags": [TAG.Upper_Threshold, TAG.Point, TAG.Temperature, TAG.Setpoint, TAG.Cool],
"subclasses": {}
},
"Heating_Temperature_Setpoint": {
BRICK.hasQuantity: BRICK.Temperature,
"tags": [TAG.Lower_Threshold, TAG.Point, TAG.Temperature, TAG.Setpoint, TAG.Heat],
"subclasses": {},
},
# etc.
}
}
}
Existing class hierarchies are altered, but nearly all class names remain. (See notes below)
Though this approach requires the most changes, it addresses the issue of incorrect semantics by clearly defining each class within its respective Setpoint type. This eliminates ambiguity and ensures that each class accurately represents its intended function.
.
├── target_setpoint
│ ├── pressure_setpoint
│ ├── humidity_setpoint
│ ├── temperature_setpoint
│ └── ...
└── threshold_setpoint
├── lower_threshold_setpoint
│ ├── heating_setpoint
│ ├── humidification_setpoint
│ └── ...
└── upper_threshold_setpoint
├── co2_setpoint
├── cooling_setpoint
├── dehumidification_setpoint
└── ...
Some superclasses such as
Temperature_Setpoint
currently contain both Target and Threshold Setpoints. I propose repurposingTemperature Setpoint
to be exclusively for "(Target) Temperature Setpoints". Alternatively, we could deprecateTemperature_Setpoint
and replace it withTarget_Temperature_Setpoint
.
cc @jbkoh
Options 1 and 3 feel like duals. They both organize the setpoints along 2 dimensions: by quantity (e.g., Temperature) and by the setpoint type (e.g., Threshold). The difference between them is whether we organize the Python files by quantity or by setpoint type. Do I understand this right?
Option 1 adds new parent classes while keeping the existing hierarchy. This means some classes will still have mixed setpoint types as subclasses (e.g., Zone Air Temperature Setpoint has both target and threshold subclasses). For example, Zone Air Temperature Setpoint currently has the following subclasses:
Option 3 completely reorganizes the hierarchy, grouping classes by setpoint type first (target, lower threshold, upper threshold), then by quantity (temperature, pressure, etc.). This ensures all superclasses share the same setpoint type. Continuing with the previous example, it would look something like this:
.
├── lower_threshold_setpoint
│ └── lower_threshold_temperature_setpoint
│ └── heating_temperature_setpoint
│ └── air_heating_temperature_setpoint
│ └── zone_air_heating_temperature_setpoint
├── target_setpoint
│ └── target_temperature_setpoint
│ └── target_air_temperature_setpoint
│ └── target_zone_air_temperature_setpoint
│ ├── effective_zone_air_temperature_setpoint
│ ├── occupied_zone_air_temperature_setpoint
│ └── unoccupied_zone_air_temperature_setpoint
└── upper_threshold_setpoint
└── upper_threshold_temperature_setpoint
└── cooling_temperature_setpoint
└── air_cooling_temperature_setpoint
└── zone_air_cooling_temperature_setpoint
The primary focus with Option 3 is to prioritize setpoint type (target, upper threshold, lower threshold) over the when (i.e. Occupied, Unoccupied), substance (i.e. Air, Water), and measurement (i.e. Temperature, Pressure).
This issue has served its purpose in guiding the implementation of the setpoint-restructure PR
How do we define setpoint? I personally like Wikipedia's definition:
Let's call this a "Target Based Setpoint"
Target-Based
These are values that is the desired target for a process variable (PV). Examples include:
However, there are many terms used to describe different types of setpoints, such as:
These setpoints are an attempt to describe something else.. and it doesn't fit into the definition mentioned above. So how do we distinguish these types of setpoints? I would like to propose a term, "Threshold Setpoint".
Threshold-Based
These values initiates a specific action when a process variable crosses a certain threshold. They can be further categorized into upper and lower thresholds:
Upper Thresholds
Initiates a specific action when the process variable exceeds specified value.
Lower Thresholds
Initiates a specific action when the process variable falls below specified value.
Example
Let's compare "Effective Cooling/Heating Setpoint" to "Effective Target Setpoint" as an example:
Key Takeaway
Clearer setpoint classification is essential for understanding the nature of a setpoint. The distinction between target-based and threshold-based setpoints enhances our ability to represent all types of setpoints observed in building systems.
Action items
We could introduce some variation of the following:
Next, we can categorize all existing setpoint classes under the following superclasses.
Discussion