- 1 Behavior
- 2 Actors
- 3 Properties
- 3.1 thermostat_mode and last_mode
- 3.2 resolve_mode
- 3.3 setup_mode
- 3.4 bid_mode
- 3.5 ramps
- 3.6 ranges
- 3.7 names
- 3.8 last_mode_timer
- 3.9 heat_set_base
- 3.10 heat_setpoint
- 3.11 cool_set_base
- 3.12 cool_setpoint
- 3.13 market
- 3.14 market_period
- 3.15 bids and demand
- 3.16 load
- 3.17 total
- 3.18 last_price
- 3.19 temperature
- 3.20 price
- 3.21 avg_price
- 3.22 stdev_price
- 4 Functions
- 5 See also
NOTE: This object and page are deprecated. Its functionality has been folded into the Controller object.
The double-setpoint controller is used to specifically control demand-responsive thermostats that have price-responsive cooling and heating systems.
The double_controller was originally created after it was observed that using two normal controllers could create implausible setpoint combinations given low prices and both pre-heating and pre-cooling, and could improperly bid the sum of both the heating and cooling power demands to the same cycle. The double controller is thus designed to specifically determine what the proper bid price and quantity is for a given temperature when both the heating and cooling systems are bidding to preheat and precool at the same time. It will also properly adjust setpoints to better facilitate whether the controller is currently heating or cooling a house, and prevent setpoint overlap.
The double_controller object is meant to attach itself to another object to control two setpoints to maintain a given observation between those two point. It is implicitly assumed with the initial version that it is meant to control an HVAC thermostat in order to keep the observed air temperature within a certain range.
The double_controller's parent is the source of temperature and setpoint observations, and is the affected by the setpoint determinations from the double_controller. The parent's setpoints are completely overwritten during the simulation process, and control of the base setpoint is done by writing values to heat_set_base and cool_set_base, rather than heating_setpoint and cooling_setpoint for the house, for example.
The market object referenced is both used for input price signals and to post bids for power demand. The controller will sync up as frequently as the market does, updating the setpoints as the market clears and posts new prices. If the controller does not post bids, the market will only be used to calculate the setpoints for the next cycle in the same fashion that it would had it posted a bid that would have 'purchased' power.
thermostat_mode and last_mode
These two enumerations store the current and previous 'desire' of the thermostat. The current state, as determined by temperature and the bid price is in 'thermostat_mode'. This current state will be copied to 'last_state' between timesteps, and will be either HEAT or COOL during both the period of time that the thermostat is demanding heating or cooling, but will also persist for up to six hours afterwards if neither is demanded or activated for a period of time.
This is the initial state for both modes, and is replaced by another state as soon as possible. It may be used in the future to indicate that the thermostat controller as a whole has an invalid configuration.
The thermostat is neither heating nor cooling.
The thermostat is operating as if the device it is attached to needs more heat.
The thermostat is operating as if the device it is attached to needs to shed heat.
This enumeration determines the strategy to resolve any conflicts or potential conflicts between the heating and cooling setpoints. If the setpoint changes sufficiently, it is possible for one or both sides of the controller to preempt the bid and remain inactive.
By default, the controller will resolve every conflict in favor of additional cooling, adjusting the heating setpoint downwards as far as the base heating setpoint. If the adjusted heating setpoint is below the base heating setpoint, the cooling setpoint will be adjusted upwards slightly.
This strategy resolves conflicts by finding the average setpoint temperature and setting both setpoints equally distant from that average.
The previous thermostat state is used to determine which setpoint is favored in conflicts. The thermostat will keep the heating setpoint if the thermostat is in a heating mode, and will keep the cooling setpoint if the thermostat is in a cooling mode.
This enumeration is used for convenience to reduce the complexity of connection to specific devices.
No assumptions will be made about the parent object that is being controlled.
The parent object is assumed to be a residential module house object.
The bid mode determines if the controller will bid its price and quantity to its associated market.
The controller will post a bid price and power demand to the associated market (in dollars and kilowatts). Should the posted market clearing price be greater than the bid price, the thermostat's setpoints will be set to those at which it is no longer price-responsive.
The controller will operate solely on the input price signal, and determines its setpoints independently of the internal temperature.
The ramp values determine the number of standard deviations in the price signal are required before the thermostat will place a setpoint at the maximum of its allowed range. Cooling ramps must be positive, heating ramps must be negative.
The number of standard deviations for the thermostat to maximize its precooling price exploitation.
The number of standard deviations for the thermostat to maximize its cooling deferral.
The number of standard deviations for the thermostat to maximize its heating deferral.
The number of standard deviations for the thermostat to maximize its preheating price exploitation.
The range determines the 'width' of the thermostat's price-responsive band. The inner edge of the ranges represent the extent to which the thermostat will allow its precool or preheat. The outer edge of the ranges represents the point at which the thermostat will become unresponsive to price signals, and will run regardless of external data. Low ranges must be negative. High ranges must be positive. Ranges are measured in degrees Fahrenheit from the base setpoint.
The number of degrees the thermostat will precool, given below-average prices.
The number of degrees the thermostat will allow cooling to slip, given above-average prices.
The number of degrees the thermostat will allow heating to slip, given above-average prices.
The number of degrees the thermostat will preheat, given below-average prices.
The name properties reference the properties in the parent object that will be used for inputs and outputs with the controller.
The name of the temperature observation property.
The name of the cooling setpoint property, read at the initial timestep to determine the base cooling setpoint, and later used to post the controller's desired cooling setpoint.
The name of the property that posts the power demand of the cooling system, in kW.
The name of the heating setpoint property, read at the initial timestep to determine the base heating setpoint, and later used to post the controller's desired heating setpoint.
The name of the property that posts the power demand of the heating system, in kW.
The name of the property that contains the current controllable power load within the parent object.
The name of the property with the currently uncontrollable power load within the parent. Needed for bidding reasons.
The number of seconds until last_state will 'forget' whether it was heating or cooling in the recent past.
The base heating setpoint that is used to determine the price response interval. Can be externally controlled.
The current heating setpoint, calculated based on the temperature observation, the price signal, and the controller's ramp and range values.
The base cooling setpoint that is used to determine the price response interval. Can be externally controlled.
The current cooling setpoint, calculated based on the temperature observation, the price signal, and the controller's ramp and range values.
The market object reference to post bids to and retrieve price signals from.
The number of seconds between market clearing cycles. The controller defers price updates until the market has cleared.
bids and demand
Both the heating and cooling sides of the thermostat have independent price and quantity demands, which are separately calculated in parallel. If the thermostat has bid prices for both the heating and cooling systems, the controller will use the resolve_mode to determine whether the heating or cooling bid should be posted.
The price the thermostat is willing to pay per kilowatt-hour of energy to run the cooling system.
The price the thermostat is willing to pay per kilowatt-hour of energy to run the heating system.
The power draw, in kilowatts, that the cooling system will consume if it runs.
The power draw, in kilowatts, that the heating system will consume if it runs.
The per-kilowatt price that the controller submitted in its bid to the market.
The number of kilowatts of power that the controller submitted in its bid to the market.
The controllable power consumption of the attached parent.
The total of the controllable and uncontrollable power consumption of the attached parent.
The price sent to the market for the previous auction session.
The current temperature observation inside the parent.
The most recently received current price signal.
The most recently received average price signal.
The most recently received price standard deviation signal.
The double_controller has no published functions.