Devices, systems, and methods for controlling electrical load in water heaters

Abstract

Systems, devices and methods for controlling water heater electrical loads may include a method including requesting, via a user interface and from a remote application programming interface (API), forecasted electrical demand data for water heaters; receiving the forecasted electrical demand data from the remote API; identifying a future demand reduction time window when the forecasted electrical demand data exceeds a threshold electrical demand; executing an electrical load shift event simulation for the water heaters for the future demand reduction time window, wherein the electrical load shift event simulation estimates an amount of increase to setpoint temperatures of the water heaters during a future preheating time and estimates times for the future preheating time; and remotely controlling the water heaters to decrease their setpoints to the first setpoint temperature during the future demand reduction time window and to increase their setpoints to a second setpoint temperature during the preheating time.

Description

DEVICES, SYSTEMS, AND METHODS FOR CONTROLLING ELECTRICAL LOAD IN WATER HEATERSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to and the benefit of US provisional application No. 63 / 746,147, filed January 16, 2025, which is hereby incorporated by reference herein in its entirety.FIELD

[0002] The present disclosure is generally related to water heating devices and more particularly related to controlling the amount of electricity consumed by water heaters.BACKGROUND

[0003] At peak demand times, electrical grids may experience demand that approaches available electrical supply. Appliances such as water heaters may contribute to electrical demand, and the amount of electricity drawn by water heaters may vary based on hot water demand and set point temperatures at a given time. Electrical grids may benefit from management of water heater demand.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a schematic diagram illustrating a water heater load control system for water heaters in accordance with one or more embodiments of the present disclosure.

[0005] FIG. 2 is an example of the system of FIG. 1 showing an example of the forecasting system 104 in accordance with one or more embodiments of the present disclosure.

[0006] FIG. 3 shows example demand response models available via the user portal of FIG. 1 in accordance with one or more embodiments of the present disclosure.

[0007] FIG. 4 is an example process for a load shifting model algorithm in accordance with one or more embodiments of the present disclosure

[0008] FIG. 5A shows an example plot showing a load shift model output in accordance with one or more embodiments of the present disclosure.

[0009] FIG. 5B shows an example plot showing a load shed model output in accordance with one or more embodiments of the present disclosure.

[0010] FIG. 5C shows an example plot of a pre-heating simulation and corresponding demand reduction, in accordance with one or more embodiments of the present disclosure.

[0011] FIG. 5D shows an example plot of a forecasted power demand, a load shift simulation result, and a corresponding demand reduction, in accordance with one or more embodiments of the present disclosure.

[0012] FIG. 6A is an example flow for a process for controlling water heater electrical demand in accordance with one or more embodiments of the present disclosure.

[0013] FIG. 6B is an example flow for a process for controlling water heater electrical demand in accordance with one or more embodiments of the present disclosure.

[0014] FIG. 7 is a diagram illustrating an example of a computing system of one embodiment of the present disclosure.

[0015] FIG. 8 shows an example plot of water heater forecast demand data using given coefficients for a forecast model, in accordance with one or more embodiments of the present disclosure.

[0016] FIG. 9A shows an example user interface for simulating or scheduling a load shift (watts) event, in accordance with one or more embodiments of the present disclosure.

[0017] FIG. 9B shows an example user interface for simulating or scheduling a load shift (setpoint) event, in accordance with one or more embodiments of the present disclosure.DETAILED DESCRIPTION

[0018] The amount of electricity used by water heaters depends on their type, hot water usage / demand, and setpoint temperatures. At certain times during a given day, an aggregate demand of water heaters in a given geographic area may be higher than other times. For example, a neighborhood of homes with water heaters may experience higher hot water demand in the morning as people wake up than in the afternoon.

[0019] Electrical grids supply electricity to many locations, buildings, and appliances. At certain times, electrical demand may be higher than other times, such as when aggregate water heater usage in a given area is high. To ensure that electrical demand does not exceed electrical grid supply, it may be beneficial to reduce electrical demandfrom appliances such as water heaters at peak demand times. However, water heater users should still be able to have hot water even during high electrical demand times.

[0020] For users who opt in, load shedding and load shifting are techniques that reduce electrical demand of water heaters. In load shedding, a water heater's set point temperature may be lowered to reduce electrical draw of the water heater. In load shifting, water heaters may pre-heat water before forecasted hot water demand occurs when the water heaters are capable of storing thermal energy. In some embodiments, a load shift may be limited to certain types of water heaters (e.g., those including an internal or external mixing valve). A load shed or a load shift event at a single water heater at a given time may provide negligible electrical savings for a grid, but a load shed or a load shift of multiple water heaters in a given area at a given time may achieve significant electrical grid demand reduction. However, identifying when a load shed or load shift event should occur, and for which water heaters, can be challenging. In addition, implementing a load shed or load shift event for water heaters should ensure that the water heaters in the event are still able to meet hot water demand from their users.

[0021] In one or more embodiments, to enable load shed and load shift events for water heaters, users may opt into programs that allow their water heaters to be controlled remotely to reduce electrical grid demand while still being able to produce hot water to meet user demand. A utility provider or aggregator, for example, may identify times and water heaters for a load shed or load shift event based on demand forecast data. For example, water heaters from an original equipment manufacturer (OEM) may provide their usage data to a remote (e.g.. cloud-based) system, which may perform periodic demand forecasting on aggregate groups of water heaters. The OEM may use one or more application programming interfaces (APIs) to expose water demand forecasts to utility7providers or aggregators, who may use the forecast data to schedule and initiate load shed and load shift events for selected water heaters at given times to reduce electrical grid demand. In this manner, the present disclosure enables fleet-wide water heater demand forecasting and load shed and shift events for users who opt in (in accordance with required laws and with proper user permissions). By using forecast demand, the load shed and load shift operations may be proactive rather than reactive, avoiding scenarios when electrical demand reaches grid supply7.

[0022] In one or more embodiments, input parameters for the demand forecast may include a volume dictionary, which creates a mapping of each ty pe of water heater to thegeneralized tank volume for each type. Alternatively or in addition, tank volumes for each device may be collected by the aggregator. The volume in a tank may be used to calculate the mass of water in the tank that is subjected to the heating process of the water heater, and the mass of water is used to calculate the heat energy added during the water heating process. Additional system parameters used for a load shed operation may include water heater tank volumes, specific heat of water, density' of water, demand reduction window temperature, ambient temperature (e.g., at the locations of the water heaters), and time interval between each data instance (e.g., fifteen minute intervals). Event parameters used for a load shed operation may include a program identifier (e.g., selected in an event simulation window), an event name, an event type, a product type (e.g., type of water heater), an event start time, an event end time, a location type (e.g., groups, entire grid, zip code, etc., selected in an event simulation window), zip codes for the selected program, an event setpoint temperature for the demand reduction event, and an event mode (e.g., defaulted to energy saver / enabled mode, depending on the selected product type). The load shed operation may calculate powerwatt prediction data as described herein, possible demand reduction (e.g., in units of energy), and a simulation curve of the reduced demand.

[0023] In one or more embodiments, a temperature change function may be used to model the temperature change of water during a demand reduction event. The temperature change function captures the change from current setpoint temperature to the pre-heating setpoint temperature. The rate of change of temperature is modeled using Newton’s law of cooling.

[0024] In one or more embodiments, a demand / power / load change function may be used to model the demand / power / load change in a water heater during the demand reduction event. The function captures the change in demand during the demand reduction event window. The instantaneous demand / power is calculated using the thermodynamic equation that captures the change in enthalpy of a mass of water when experiencing a temperature change.

[0025] In one or more embodiments, some assumptions applied in the event may include the following: (1) The minimum power consumption considered as power demand = 40 Watts: (2) temperature drop rate = 2 degrees F / hour during non-usage: (3) temperature drop rate = 5 degrees F / hour temperature drop rate during usage; (4) storage capacity of heat pump water heater ty pe 1 = first capacity in gallons; (5) storage capacity of heat pump water heater type 2 = second capacity in gallons; (6) storage capacity of water heatertype 3 = third capacity in gallons; (7) storage capacity of other water heater types = fourth capacity in gallons; and (8) initial temperature of water in water heater tank at the start of a demand reduction event = 125 degrees F.

[0026] In one or more embodiments, an output dictionary may be used to store the simulation results (e.g., calculated parameters) of the load shed model along with the event parameters. The calculated parameters may include: (1) forecasted demand - data points that represent the forecasted demand by the forecasting model, filtered for the specific event criteria and demand reduction window, calculated every 15 minutes (or another time interval); (2) simulated demand - datapoints that represent the simulated demand by the load shed model, filtered for the specified event criteria and demand reduction window, calculated every’ 15 minutes (or another time interval); (3) demand reduction - datapoints that represent the demand reduction, which is the difference between the forecasted demand and the simulated demand at any point during the demand reduction window, calculated every’ 15 minutes (or another time interval).

[0027] In one or more embodiments, the system / event parameters for a load shift event may include volume of the water heater tank, specific heat of water, density of water, overall connective heat transfer coefficient, maximum pre-heating temperature, ambient temperature (e.g., at the water heater locations), and pre-heating initial temperature of water. Event parameters used for a load shift operation may' include a program identifier (e.g., selected in an event simulation window), an event name, an event type, a product type (e.g., ty pe of water heater), an event start time, an event end time, a location type (e.g., groups, entire grid, zip code, etc., selected in an event simulation window), zip codes for the selected program, an event setpoint temperature for the demand reduction event, an event mode (e.g., defaulted to energy’ saver / enabled mode, depending on the selected product type), a pre-heating setpoint temperature, and a pre-heating mode (e.g., selected by a user).

[0028] In one or more embodiments, the calculated parameters for a load shift event may’ include: (1) enrolled devices for the selected demand reduction program; (2) qualified devices (e.g., enrolled water heaters having a forecasted demand greater than a threshold wattage during the demand reduction window and matching the demand reduction event criteria); (3) possible demand reduction in units of energy; (4) pre-heating start time; (5) pre-heating setpoint temperature; and (6) pre-heating mode (e.g., suggested by the model to achieve the possible demand reduction, which may be derived by evaluating each modein an iterative process - the modes including energy saver, heat pump, electric, and high demand).

[0029] In one or more embodiments, the energy to be reduced in the demand reduction window is calculated with the event setpoint entered by the user as the basis for the calculation. The set point of each participating water heater is reduced to the event setpoint during the demand reduction (DR) window. The temperature change is modelled using Newton's law of cooling. The temperature datapoints are calculated at every 15 minutes interval in the DR window. This continuous temperature drop in the demand reduction window leads to a continuous load change / drop, which is also calculated at every 15 minutes interval. Plotting the load drop during the demand reduction window generates the demand reduction simulation curve.

[0030] In one or more embodiments, the temperature change function may be used to model the water temperature change during the demand reduction event. The demand reduction function may be used to model the demand / power / load reduction during the demand reduction event. The energy added during pre-heating may be calculated for each qualified device for the entire duration of the demand reduction window, and may be calculated every 15 minute interval using the respective average power values logged every 15 minutes and aggregated over the entire demand reduction window duration for a given geographic region where the event is applied. For example: energypreheating{15 minutes= poweravg 15 minutes* 15 * 60. The maximum possible energv addition in a pre-heating window may be calculated for load shift events, referring to calculating the energy added by pre-heating each qualified device to the maximum possible pre-heat setpoint. For example, for each device: maximum_energypreheating= (volumedevice* densitywater) * specif icheat* (Tempmax-preheat Temppreheat.nitial). The maximum pre-heat setpoint may be the upper limit of a setpoint for a selected product type. The water may be assumed to be at the initial setpoint temperature at the start of the pre-heating process (e.g., whatever the setpoint temperature is prior to raising the set point to the pre-heating set point). By heating the water from the lower limit to the upper limit of setpoints, the maximum possible energy that can be added to the system during the pre-heating window may be calculated.

[0031] In one or more embodiments, the pre-heating time for load shifting may be calculated for each qualified device. The maximum pre-heating time is needed whenadding the maximum energy to the system. For each device, the maximum pre-heat time jnaximum_enerqyrirpi1pntinn-.is: pre _heat_timemax= ( - - - -) / 3600.POWe7 at,5pre / ieatmg

[0032] In one or more embodiments, the change in temperature of water in tank-type heaters during a heating process may be modeled using an energy balance equation: Eln— Eout+ Eg — Est, where Einis the rate of energy transfer from the surrounding to the system, Eoutis the rate of energy transfer from the system to the surrounding, Egis the rate of energy' generated within the system, and Estis the rate of energy' stored within the system. By replacing the individual components of the energy balance equation in terms of temperature, the temperature T(t) at any point of time t during the heating process may be modeled as:T (t) = Tw iexp f - UAtVCp} + (Ta+ 777) [1 - e%p(-UXt FCp)].,where P is power consumption, Tw iis pre-heating initial temperature, U is overall convective heat transfer coefficient, A is total surface area of the water heater tank, Q is density of water, V is volume of water heater tank, Cpis specific heat of water, and Tais temperature of ambient air.

[0033] In one or more embodiments, the output dictionary' from the load shift simulation may include the following parameters: qualified MAC addresses, calculated pre-heating start time, pre-heating setpoint, preheating mode, detailed information (e.g.. simulation output datapoints used to plot the graphs), error message (e.g., a field to store an error message of an exception case that caused a failed simulation), and is success (a Boolean value of true / false for the status of the simulation run). Exception cases may include an invalid simulation identifier, both powerwatt values and demand reduction window do not have required data, pre-heating window does not have required data, demand reduction window does not have required data, demand reduction window is insufficient to reduce temperature to the required setpoint, pre-heating mode selected by user is insufficient, no qualified devices for the program, selected program not compatible for load shift events, simulation datapoints not generated by the model, and insufficient pre-heating time.

[0034] In one or more embodiments, the load shift event duration indicates the demand reduction window duration. The event start time refer to the start and end times for the demand reduction window. The input criteria entered by the aggregator may be used to filter out devices currently enrolled to the demand reduction window. The short-termforecast data (e.g., next seven days forecast) of each enrolled device may be used to identify the subset of enrolled devices qualified to participate in the load shift demand reduction program. Pre-heating pre-heats the qualified water heaters to a temperature above their normal setpoint, and stores the additional thermal energy in the water heaters during the pre-heating window, resulting in reduction in demand during the demand reduction window. Participation in load shifting may be limited to water heaters that include an internal or external mixing valve, for example. The pre-heating process may pre-heat the water to an increased setpoint, ensuring that the water heaters are at a preheated state at the start of the demand reduction window. The load shed event may occur during the demand reduction window when the temperature starts dropping from the increased setpoint to the normal setpoint.

[0035] In one or more embodiments, the energy to be reduced in the demand reduction window may be calculated using a target demand reduction value entered by the user (e.g., in an event simulation window of a user interface). The target demand reduction (e.g., in watts) may be represented in terms of energy (e.g., Joules) by calculating the target demand reduction rate across the demand reduction event duration. For example:Target DR (Joules) = Target DR (watts) * DR Event Duration (seconds). The energy added during pre-heating may be calculated for each qualified device for the entire duration of the demand reduction window. The energy may be calculated for each 15- minute interval using the respective average power values logged every 15 minutes, and aggregated over the entire demand reduction window duration. For each device: energypreheating^5mins) P^^ avg(15 mins) * 5 * 60.

[0036] In one or more embodiments, the energy added by preheating each qualified device to the maximum possible preheat setpoint may be calculated as such: maximum jmergypreheating= (volumnedevice* densitywater) * specif icheatwater* (Tempmaxpreheat ~ Temppreheatlnitlal). The volume of each qualified device may be obtained from the volume dictionary. Density and specific heat of water are constants. The maximum preheat setpoint may be the upper limit setpoint for the selected product type.

[0037] In one or more embodiments, pre-heating time for each qualified device may be calculated as the maximum pre-heat time as such: pre_heat_timemax(secs) = maximum_energypreheatingpower avq,preheating

[0038] In one or more embodiments, for thermal modeling, the change in temperature of water in the water heater tanks during the heating process may be modeled using the energy balance equation above.

[0039] In one or more embodiments, for load shift / preheating model execution, for each MAC address in a population / sample that represents an entire population of water heaters, the pre-heating temperature curves may be modeled at the time of event scheduling, considering the preheat setpoint to be the temperature at the end of the preheating zone. To perform this modeling, the rate of change of temperature for each mode of heating may be needed, and a linear function may be assumed for the rate of change of temperature. For each MAC address in a population / sample that represents an entire population of water heaters, the energy required to pre-heat the water heater to the preheat setpoint may be calculated based on the energy reduction achieved for all MAC addresses in the event, the energy reduction per device, the forecasted mean setpoint temperature in the preheating zone for each MAC address, and the preheating temperature curves in the preheating zone for each MAC address. The energy required to pre-heat the water heater at each datapoint may be aggregated to provide the total energy required to pre-heat the specific MAC address to the preheat setpoint. The total energy required to pre-heat for each MAC address may be aggregated to provide the total energy required to pre-heat all the water heaters in the event to the preheat setpoint. The total energy required to pre-heat all the water heaters in the event to the preheat setpoint may be used to plot the load shift simulation curve for a current event setup. For each datapoint, the forecasted demand may be added to the load shift simulation curve to provide the load shift simulated demand at the given datapoint. The load shift simulation curve may be a plot of the aggregated forecasted demand and the load shift simulation curve for each datapoint.

[0040] In one or more embodiments, for load shift (watts) event simulation, the target demand reduction watts may be subtracted from the forecast curve in the demand reduction event window. The energy between the forecast curve and the reduced curve may be calculated, and the same area (energy) may be replicated in the preheating zone. Using the calculated energy', the load shift curve may be plotted.

[0041] In one or more embodiments, water heater demand forecast data used by the forecast model may include water heater device medium access control (MAC) address, product type (e.g., model), timestamp for the data, state, zip code, ambient temperaturedata, lower tank temperature, upper tank temperature, power (e.g., watts) consumed, water heater configuration data, water heater setup data, and the like.

[0042] To calculate energy input for any recording, the power may be converted from watts to kilowatts, and the operational time of the water heater may be calculated in hours (e.g., time difference in hours = timestamp_i - timestamp_i-l / 3600). The energy input may be as follows: energy _input = power _kw * time_difference_hours.

[0043] To calculate the energy output, the energy output for each recording may be calculated using the temperature difference, specific heat capacity of water, and mass of water in the water heater (e.g., for tank-type water heaters). The temperature difference is the difference between average tank temperature at time i and average tank temperature at time i — 1 or the difference between upper tank temperature and lower tank temperature at a given time. The specific heat capacity of water is 4.186 J / g°C (a constant). The mass of water = volume of tank * 3.785* density of water. The density of water at 100 °C is 0.9584 gm / ml. The energy output = mass_water * specif ic_heat_capacity * temperature _dif f er ence.

[0044] In one or more embodiments, the forecast model may be trained using a timeseries of a power watt attribute (POWRWATT), which is an instantaneous energy unit (e.g., in kilowatts). In this manner, the data collected from a given water heater unit may include the instantaneous amount of kilowatts used by the water heater unit at the given time. In addition to the power watt attribute, other training data may include water heater unit information such as zip code (or other location) of the water heater unit and weather data (on a unit-by-unit basis). The weather data may train the model for different seasons (e.g., winter, spring, summer, fall) or weather patterns (e.g., based on local ambient temperature, humidity, cloud cover, etc.). Because energy usage and weather may vary by location, the water heater zip code (or other location data) may be used to train the model to forecast demand for devices in given areas.

[0045] In one or more embodiments, the forecast model may use a seasonal autoregressive integrated moving average with eXogenerous factors (SARIMAX model), which may be linear and may allow for use of historical data in a sliding time window to predict future values according to the following equation:0p(L)^P(Ls)AdA?yt= 4(t) + 6q(L)6Q(Ls)et,where < >p(L) is the non-seasonal autoregressive lag polynomial, <>P(Ls~) is the seasonal autoregressive lag polynomial, AdA ytis the time series differenced d times, andseasonally differenced D times, A(t) is the trend polynomial (including the intercept), is the non-seasonal moving average lag polynomial, and 6Q(LS) is the seasonal moving average lag polynomial. The non-seasonal data is data collected from the individual water heaters. The seasonal data supports the non-seasonal aspects (e g., POWRWATT data). For example, the seasonal data may indicate what the weather was for corresponding POWRWATT data at a given time and location.

[0046] In one or more embodiments, the forecast model may use different coefficients for different water heater models. There may be different coefficients for season and non-seasonal auto regression, seasonal and non-seasonal difference of time-series, and seasonal and non-seasonal moving average. The larger the coefficients, the more impact the corresponding variables have on the model’s output (e g., the POWRWATT data). For a given set of water heater units of a same type, the model may identify the water heater type, apply the corresponding coefficients, and predict future POWRWATT power demand for the set at a given time. As a result, load shedding and shifting events may be triggered based on the predicted power demand, which may be used to predict power demand savings that may be achieved by a load shed or load shift event. The POWRWATT value for one or more water heaters may be predicted as an average over a time window, a minimum over the time window, or a maximum over the time window. The maximum POWRWATT over the time period may provide a preferred indicator of demand savings for a load shed or load shift event.

[0047] In one or more embodiments, water heaters may have control circuitry to send their data to the remote system periodically (e g., every 30 seconds). The remote system may include a database in which to store the historical telemetry data received from the water heaters. An ingestion pipeline may run every minute (or some other interval) based on the ingested data from the water heaters, and may trigger instantiation of a cloud storage object bucket for data retention and management. The bucket may call a serverless data integration service, which may receive raw JavaScript Object Notation (JSON) data converted to a structured parquet in a data preparation step. The serverless data integration service may instantiate another cloud storage object bucket, which may call a machine learning model training service to train the forecasting model based on the ingested data from the water heaters. The model’s trained output data (e.g., forecasted power demand for a group of water heaters in a given geographic area) may be stored in another cloud storage object bucket and made available to an elastic computing service.When a utility or aggregator calls an API of the remote system, the elastic computing service may make the forecast data available to the utility or aggregator through the API. In this manner, the enhanced architecture herein facilitates sharing of the forecast data to requesting utilities and aggregators for use in setting and controlling load shed and load shift events.

[0048] In one or more embodiments, when an aggregator or uti 1 i ty receives water heater forecast data, the aggregator or utility may use the forecast data to estimate electrical demand reduction that may occur at a given time period if a load shed or load shift event were triggered. The aggregator or utility may receive and maintain lists of water heaters whose users have opted into the data collection and load shed and / or load shift events. The aggregator or utility may filter non-participating water heaters from the list of water heaters in a given geographic area when analyzing whether a load shift or load shed event would achieve significant demand reduction. In this manner, there are multiple filters that may be applied: One filter for water heaters opted into the load shed or load shift operations, one filter for geographic area, one filter for water heaters forecasted to have actual demand during a demand reduction window, one filter for water heaters for which the amount of energy available to be stored from the preheating window satisfies the energy needed to be offset in the demand reduction window, and one filter for water heaters that can be sufficiently preheated within the preheating window (e.g., how much time it takes to preheat the water heater). For example, there may be no reason to pre-heat water for water heaters not predicted to experience demand during a demand reduction window, so those water heaters not projected to experience demand during a time window may be excluded from consideration of a load shift operation.

[0049] In one or more embodiments, a load shift event may include a pre-heating time window during which the water of a water heater is preheated to provide additional thermal energy that the water heater may store for use during the subsequent demand reduction window. How long the pre-heating time window begins before the demand reduction window may vary. For example, the pre-heating time window may be a default time of six hours, but may be shorter depending on the demand pattern of the water heaters participating in the event. For example, water heaters participating in the event may be forecast to have demand four hours before the demand reduction window. The preheating time window may begin at a calculated time prior to the demand reduction window when an amount of time that a participating water heater needs to pre-heat islargest. That is, the water heater that may require the longest amount of time to pre-heat within the maximum time window may dictate that start of the pre-heating time window for all of the participating water heaters. All of the participating water heaters then start pre-heating at the calculated pre-heating time. The amount of time needed to pre-heat may depend on predicted demand usage of the participating water heaters, the type of water heater (e.g., size, power level, etc.), and the maximum pre_heat_timemax(secs) = (maximum_energypreheating / poweravg_preheating) / 3600, where maximum_energypreheating=preheating (volumnedevice* densitywater) * specificheat_water* (Tempmax_preheat− Temppreheat_initial) and energypreheating(15 mins)= poweravg(15 mins)* 15 * 60.

[0050] In one or more embodiments, using the forecast data, the utility or aggregator may perform a load shift simulation to predict, for a given pre-heating time window and set point temperature, an amount of electrical power shifted away from a demand reduction window. For the demand reduction window, the utility or aggregator may determine the difference between the forecasted demand and the simulated demand. The difference represents the demand reduction that may be achieved by the load shift operation. A load shift model may be run for each individual water heater, and preheating energy' and time may be calculated for each water heater. The pre-heating may be scheduled considering the earliest pre-heating start time for water heaters that are forecasted to experience hot water demand during a demand reduction window. The load shift operation may shift electrical demand for hot water production to a time preceding the demand window by pre-heatpre-heating applicable water heaters (e.g., by increasing the set point temperatures to 145 °C or another setpoint temperature higher than a normal set point) during the pre-heating window. As a result, the demand increases during the pre-heating window, but reduces during the demand reduction window, allowing for a shift in energy demand to avoid a time (e.g., corresponding to the demand reduction window) when a power grid may experience higher demand.

[0051] A load shed event occurs during the demand reduction window of a load shift event when the set point temperature is lowered from the load shift set point (e.g., 145 °C) to a load shed set point (e.g., 110 °C). The load shed set point is a set point that is lower than the normal set point temperature (e.g., 120 °C). Therefore, even if there is nonforecasted hot water demand during the demand reduction window, less energy is needed to heat the water to the load shed set point than the normal set point. A load shed eventmay occur at the same time as a load shift event (e.g., during the demand reduction window). However, in some implementations, a load shift event may occur without a load shed event.

[0052] In one or more embodiments, the load shift model may determine the start time of the load shift window. For a given set of water heaters to which the load shift event is to apply, the start time may correspond to the water heater which needs the longest time to heat to the pre-heatpre-heating set point to ensure that all the water heaters in the load shift event are pre-heated to the pre-heatpre-heating set point temperature before the demand reduction window. Such information may be included in the forecast data or determined based on the forecast data, such as taking into account forecast demand during the load shift window.

[0053] In one or more embodiments, the load shift model may address water heaters with a forecasted demand during a demand reduction window and no demand outside of the demand reduction window (e.g., six hours prior to the demand reduction window) and water heaters with a forecasted demand both during the demand reduction window and outside of the demand reduction window (e.g., six hours prior to the demand reduction window).

[0054] In one or more embodiments, the demand response models used to analyze and trigger load shed and load shift operations may include a load shed setpoint model, a load shed watts model, a load shift set point model, and a load shift watts model. The load shed setpoint model may input an event setpoint temperature and an event duration, and may generate an event simulation result. The load shed watts model may input a target demand reduction (e.g., an amount of power / watts a utility or aggregator wants to save) and an event duration, and may generate event simulation options and an event simulation result. The load shift setpoint model may input a pre-heat setpoint temperature, an event setpoint temperature, and an event duration, and may generate an event simulation result. The load shift watts model may input a target demand reduction (e.g., an amount of power / watts a utility or aggregator wants to save) and an event duration, and may generate an event simulation result. The inputs to the demand reduction models may be provided by a user (e.g., utility or aggregator) via one or more graphical user interfaces through which the user may schedule or trigger a load shed and / or load shift event. In this manner, the user interfaces may have access to the demand response models and the forecast data to perform demand reduction simulations and assess the forecasted demand reduction basedon the input parameters of the simulations and the forecasted demand during demand reduction windows.

[0055] In one or more embodiments, for a load shifting model and a given temperature curve in a demand reduction window and a given demand reduction curve, the load shifting model may predict an energy reduction in the demand reduction window. Using the demand reduction curve, a demand addition curve in the pre-heating window, and a temperature curve in the pre-heating window, the load shifting model may predict the added energy during a pre-heating window. Using the energy addition in the pre-heating window and the power input for a heating mode in a pre-heating window (e.g., the power mode corresponding to a set point temperature), the load shifting model may generate the pre-heating time for the load shift event.

[0056] In one or more embodiments, when a load shed or load shift event is predicted to achieve a threshold demand reduction, the utility or aggregator may send, via the graphical user interfaces, one or more instructions to an OEM system for the water heaters selected for inclusion in the load shed or load shift event, to remotely control the selected water heaters. For example, the instructions may include the MAC addresses of the selected water heaters, location information with which to identify the selected water heaters, set point temperatures at which to set the selected water heaters, and the respective times for events and pre-heating. The OEM system may receive the event instructions and may translate them into commands for the respective water heaters. The OEM system may issue the commands to the water heaters to perform the load shed or shift operations by setting the set point temperatures at the respective times. The commands may be sent using one or more wired or wireless protocols to various local nodes (e g., Wi-Fi access points, cellular radio access nodes, etc.) proximal to the water heaters in a selected area for a load shift or load shed event so that the commands are routed to the water heaters and implemented by the individual water heaters using their control systems.

[0057] Turning now to the drawings, FIG. 1 is a schematic diagram illustrating a water heater load control system 100 for water heaters 102 in accordance with one or more embodiments of the present disclosure.

[0058] The water heaters 102 (e.g., 1-N water heaters) may be of one or more types and may be installed in one or more geographic locations. For example, the water heaters 102 may include tank electric, tankless electric, heat pump, combined electric and heat pump, hybrid gas and electric or gas and heat pump water heaters, variations of each (e.g.,different sizes, power levels, etc ), and the like. The system 100 may include a forecasting system 104 for forecasting electrical demand of the water heaters 102. Utilities and / or aggregators 106 (e.g., utility / aggregator 1 - utility / aggregator M) may access a user portal 108 to simulate, schedule, and trigger load shed and load shift events for any of the water heaters 102 based on the forecasting provided by the forecasting system 104. When the utilities / aggregators 106 schedule or trigger a load shed or load shift event, the user portal 108 may send event instructions 116 to one or more water heater control system 110 to specify which water heaters are to perform a load shed or load shift event, when, and using which operational parameters. The water heater controls systems 110 may be translate the event instructions 116 into event commands 118, and may transmit the event commands 118 to the water heaters included in a load shed or load shift event so that the water heaters may configure their settings to perform the load shed or load shift event.

[0059] In one or more embodiments, to enable load shed and load shift events for water heaters, users may opt into programs that allow their water heaters to be controlled remotely to reduce electrical grid demand while still being able to produce hot water to meet user demand. The utilities / aggregators 106 may identify times, geographic areas (e.g., zip codes or groups of zip codes), and types of water heaters for a load shed or load shift event based on the forecast data 114. For example, any of the water heaters 102 from an OEM may provide their usage data (e.g., the water heater data 112) to a remote system (e.g., the forecasting system 104), which may perform periodic demand forecasting on aggregate groups of the water heaters 102.

[0060] In one or more embodiments, the water heater data 112 may include water heater device MAC address, product type (e.g., model), timestamp for the data, state, zip code, ambient temperature data, lower tank temperature, upper tank temperature, power (e.g., watts) consumed, water heater configuration data, water heater setup data, and the like.

[0061] In one or more embodiments, the forecast model of the forecasting system 104 may use different coefficients for different water heater models. There may be different coefficients for season and non-seasonal auto regression, seasonal and non-seasonal difference of time-series, and seasonal and non-seasonal moving average. The larger the coefficients, the more impact the corresponding variables have on the model’s output (e.g., the POWRWATT data). For a given set of water heater units of a same type, the model may identify the water heater type, apply the corresponding coefficients, and predict future POWRWATT power demand for the set at a given time. As a result, load shedding andshifting events may be triggered based on the predicted power demand, which may be used to predict power demand savings that may be achieved by a load shed or load shift event. The POWRWATT value for one or more water heaters may be predicted as an average over a time window, a minimum over the time window, or a maximum over the time window. The maximum POWRWATT over the time period may provide the best indicator of demand savings for a load shed or load shift event.

[0062] In one or more embodiments, the water heaters 102 may have control circuitry to send the water heater data 112 to the forecasting system 104 periodically (e.g., every 30 seconds). The forecasting system 104 may include a database in which to store the historical telemetry data (e.g., the water heater data 112) received from the water heaters 102. The model’s trained output data (e.g., the forecast data 114) may made available to the utility or aggregator through the user portal 108 (e.g., via an API, as shown in FIG. 2).

[0063] In one or more embodiments, when an aggregator or utility receives the forecast data 114, the aggregator or utility may use the forecast data 114 to estimate electrical demand reduction that may occur at a given time period if a load shed or load shift event were triggered. The aggregator or utility may receive and maintain lists of the water heaters 102 whose users have opted into the data collection and load shed and / or load shift events. The aggregator or utility may filter non-participating water heaters from the list of water heaters in a given geographic area when analyzing whether a load shift or load shed event would achieve significant demand reduction. In this manner, there are three filters that may be applied: One filter for water heaters opted into the load shed or load shift operations, one filter for geographic area, and one filter for water heaters forecasted to have actual demand during a demand reduction window.

[0064] In one or more embodiments, using the forecast data 114, the utility or aggregator may perform a load shift simulation using the user portal 108 to predict, for a given pre-heating time window and set point temperature, an amount of electrical power shifted during a demand reduction window. For the demand window, the utility or aggregator may determine the difference between the forecasted demand and the simulated demand. The difference represents the demand reduction that may be achieved by the load shift operation. A load shift model may be run for each individual water heater, and preheating energy and time may be calculated for each water heater. The pre-heating may be scheduled considering the earliest pre-heating start time for water heaters that are forecasted to experience hot water demand during a demand reduction window. The loadshift operation may shift electrical demand for hot water production to a time preceding the demand window by pre-heating applicable water heaters (e.g., by increasing the set point temperatures to 145 °C or another temperature higher than a normal set point) during the pre-heating window. A load shed event occurs during the demand reduction window of a load shift event when the temperature is changed from the load shift set point (e.g., 145 °C) to a load shed set point (e.g., 110 °C). As a result, the demand increases during the pre-heating window, but reduces during the demand reduction window, allowing for a shift in energy demand to avoid a time (e.g., corresponding to the demand reduction window) when a power grid may experience higher demand.

[0065] In one or more embodiments, the load shift model may determine the start time of the load shift window. For a given set of water heaters to which the load shift event is to apply, the start time may correspond to the water heater which needs the longest time to heat to the pre-heat set point for the pre-heating to ensure that all the water heaters in the load shift event are pre-heated to the pre-heat set point temperature before the demand reduction window. Such information may be included in the forecast data 114.

[0066] In one or more embodiments, the load shift model may address water heaters with a forecasted demand during a demand reduction window and no demand outside of the demand reduction window (e.g., six hours prior to the demand reduction window) and water heaters with a forecasted demand both during the demand reduction window and outside of the demand reduction window (e.g., six hours prior to the demand reduction window).

[0067] In one or more embodiments, the demand response models used to analyze and trigger load shed and load shift operations may include a load shed setpoint model, a load shed watts model, a load shift set point model, and a load shift watts model. The load shed set point model may input an event setpoint temperature and an event duration, and may generate an event simulation result. The load shed watts model may input a target demand reduction and an event duration, and may generate event simulation options and an event simulation result. The load shift setpoint model may input a pre-heat setpoint temperature, an event setpoint temperature, and an event duration, and may generate an event simulation result. The load shift watts model may input a target demand reduction and an event duration, and may generate an event simulation result. The inputs to the demand reduction models may be provided by a user (e.g., utility or aggregator) via one or more graphical user interfaces of the user portal 108 through which the utilities / aggregators 106may schedule or trigger a load shed and / or load shift event. In this manner, the user portal 108 may have access to the demand response models and the forecast data 114 to perform demand reduction simulations and assess the forecasted demand reduction based on the input parameters of the simulations and the forecasted demand during demand reduction windows.

[0068] In one or more embodiments, for a load shifting model and a given temperature curve in a demand reduction window and a given demand reduction curve, the load shifting model may predict an energy reduction in the demand reduction window. Using the demand reduction curve, a demand addition curve in the pre-heating window, and a temperature curve in the pre-heating window, the load shifting model may predict the added energy during a pre-heating window. Using the energy addition in the pre-heating window and the power input for a heating mode in a pre-heating window (e.g., the power mode corresponding to a set point temperature), the load shifting model may generate the pre-heating time for the load shift event.

[0069] In one or more embodiments, when a load shed or load shift event is predicted to achieve a threshold demand reduction, the utility or aggregator 106 may send, via the user portal 108, the event instructions 116 to the water heater control systems 110 for the water heaters selected for inclusion in the load shed or load shift event, to remotely control the selected water heaters. For example, the event instructions 116 may include the MAC addresses of the selected water heaters, location information with which to identify the selected water heaters, set point temperatures at which to set the selected water heaters, and the respective times for events and pre-heating. The water heater control systems 110 may receive the event instructions 116 and may translate them into the event commands 118 for the respective water heaters. The water heater control systems 110 may issue the commands to the water heaters 102 to perform the load shed or shift operations by setting the set point temperatures at the respective times. The event commands 118 may be sent using one or more wireless protocols to various local nodes (not shown) proximal to the water heaters 102 in a selected area for a load shift or load shed event so that the event commands 118 are routed to the water heaters 102 and implemented by the individual water heaters 102 using their control systems.

[0070] FIG. 2 is an example of the system 100 of FIG. 1 showing an example of the forecasting system 104 in accordance with one or more embodiments of the present disclosure.

[0071] Referring to FIG. 2, the forecasting system 104 may include an Internet of Things (loT) cloud 202 through which the water heater data 112 may be transmitted from the water heaters 102. The loT cloud 202 may provide the water heater data 112 to data ingestion resources 203, including a document database 204 for storing the water heater data 112 as historical telemetry data. Ingestion functions 206 may run periodically and / or anytime the water heater data 112 is ingested, and its functions may instantiate an object storage bucket 208 for data retention policy and data management. The object storage bucket 208 may call a serverless data integration service 212, which may receive hourly job data in a structured parquet (or other data format such as SQL or CSV) from a workflow service 214 (e.g., which may convert raw JSON data into the structured parquet or other structured format). The serverless data integration service 212 may instantiate an object bucket 216 for processing and preparation of data to be used in the forecasting.

[0072] Still referring to FIG. 2. the object bucket 208 may provide the structured data to model training resources, including an object bucket 220 for storing model scripts, and to a model platform 222 for training and using the forecasting and degradation models for inferencing. The outputs of the model platform 222 may be stored in an object bucket 224. The forecasting system 104 may include an elastic computing service 226, which may receive the predicted water heater data 228 (e.g., predicted POWRWATT demand from the forecasting model). The model outputs (e.g., the forecast data 114) may be available to the utilities / aggregators 106 (e.g., via the user portal 108) when the user portal 108 makes API calls to an API gateway 230 of the forecasting system 104 for the forecast data 114.

[0073] FIG. 3 shows example demand response models available via the user portal 108 of FIG. 1 in accordance with one or more embodiments of the present disclosure.

[0074] Referring to FIG. 3, the demand response models may include a load shed (setpoint) model 302, a load shed (watts) model 304. a load shift (setpoint) model 306, and a load shift (watts) model 308. Inputs to the load shed (setpoint) model 302 may include an event setpoint 310 (e.g., setpoint temperature for the load shed event, entered by a user) and an event duration 312 (e.g., a time duration for the load shed event, entered by the user). The output of the load shed setpoint model 302 may include an event simulation result 314 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shed event using the event setpoint 310 and the event duration 312. The event simulation result 314 may include plots of the forecasted demandfor water heaters participating in the event and of the reduced demand for those water heaters as a result of the load shed event using the event setpoint 310 and the event duration 312. By aggregating the demand reduction for each of the participating water heaters during the event, the total demand reduction for the load shed event may be shown by the event simulation result 314.

[0075] Inputs to the load shed (watts) model 304 may include a target reduction 316 (e.g., electrical demand reduction) and an event duration 318 for the load shed event. Outputs of the load shed (watts model 304) may include an event simulation result 320 based on the target reduction 316 and the event duration 318, and based on which event options 322 for the event are selected by the user to achieve the target reduction 316. Unlike the load shed (setpoint) model 302, the user does not enter the event setpoint 310 and the event duration 312 for the load shed (watts) model 304. Instead, the user enters the target reduction 316 to be achieved during the load shed event and the event duration 318 for the load shed event. The load shed (watts) model 304 may use the minimum acceptable setpoint for a participating water heater during the load shed (e.g., to provide hot water during the load shed). The event options 322 may include optional parameters to achieve the target reduction 316 for the event duration 318, such as the start and end times for the event, of which there may be multiple options available to achieve the target reduction 316 for the event duration 318. The event simulation result 320 may depend on which of the event options 322 are selected for the simulation. The event simulation result 320 may show how the target reduction 316 for the event duration 318 may be achieved, what that would include (e.g., the timing of the load shed event), and what the maximum demand reduction achieved would be).

[0076] Inputs to the load shift (setpoint) model 306 may include a pre-heat setpoint 324 temperature (entered by a user), an event setpoint 326 temperature (entered by the user), and an event duration 328 (entered by the user) for the load shift. An output of the load shift (setpoint) model 306 may include an event simulation result 330 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shift event using the inputs. The event simulation result 330 may include plots of the forecasted demand for water heaters participating in the event and of the reduced demand for those water heaters as a result of the load shift event using the event setpoint 326 and the event duration 238. By aggregating the demand reduction for each of the participating water heaters during the event, the total demand reduction for the load shift event may beshown by the event simulation result 330. The event simulation result 330 also may include plots of the forecasted demand for the participating water heaters during the preheating window, along with the start and end times of the preheating window.

[0077] Inputs to the load shift (watts) model 308 may include a target reduction 332 (entered by a user) in water heater electrical demand and an event duration 334 (entered by the user) for the load shift event. An output of the load shift (watts) model 308 may include an event simulation result 336 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shift event using the inputs. The load shift (watts) model 308 may use the minimum acceptable setpoint for a participating water heater during the load shed (e.g., to provide hot water during the load shed). The event simulation result 336 may include plots of the forecasted demand for water heaters participating in the event and of the reduced demand for those water heaters as a result of the load shift event using the target reduction 332 and the event duration 334. The start and end times of the preheating window may be shown, and they may be selected to achieve the target reduction 332 for the event duration 334 based on the factors described above for the participating water heaters. For example, the preheating window selected by the event simulation result 336 may depend on the longest time needed for any of the participating water heaters to achieve the necessary energy storage for the load shed that occurs after the preheating window. The event simulation result 336 may show how the target reduction 332 for the event duration 334 may be achieved, what that would include (e.g., the timing of the preheating window and the load shed), and what the maximum demand reduction would be.

[0078] For each of the models, the event simulation results may show the energy usage of the participating water heaters at respective times. When a load shift event occurs, the energy usage may be shown for both the preheating window and the load shed (e.g., demand reduction window). As noted above, the variable inputs of a user for load shift models may include the demand reduction program, the device (water heater) type, the event start and end times, the group / location of participating water heaters, the target demand reduction, the preheating setpoint and mode, and the event setpoint (e.g., load shed setpoint).

[0079] FIG. 4 is an example process 400 for a load shifting model algorithm in accordance with one or more embodiments of the present disclosure. The process 400 shows multiple respective stages for setting the preheating time for a load shift based: theenergy reduction in the demand reduction window 406, the energy addition in the preheating window 412, and the pre-heating time 416. For the energy reduction in the demand reduction window 406 section of the load shift algorithm, the main calculations may include the temperature curve in the demand reduction window 408 and the demand reduction curve 410. For the energy addition in the pre-heating window 412 section of the load shift algorithm, the main calculations may include the temperature curve in the preheating window 412 and the demand addition curve 414. For the pre-heating time 416 section of the load shift algorithm, the main calculations may include the energy addition to the pre-heating window 404 and the power input for the heating mode in the pre-heating window 416.

[0080] FIG. 5 A shows an example plot 500 showing a load shift model output in accordance with one or more embodiments of the present disclosure.

[0081] Referring to FIG. 5A, a pre-heat window 502 from time tO to time tl precedes a demand reduction window 504 from time tl to time 12. A forecast demand curve 506 and simulated demand curve 508 are shown. The forecast demand curve 506 may be based on the forecast data 114 of FIG. 1 for any water heaters selected for the load shift event. The simulated demand curve 508 shows what the demand would look like during the pre-heat window 502 and during the demand reduction window 504. As shown in FIG. 5A, the power demand (e.g., watts) during the pre-heat window 502 may increase (e.g., with respect to the forecast demand curve 506) in response to increasing the setpoint temperatures of the selected water heaters to pre-heat their water and store thermal energy before the demand reduction window 504. However, a demand reduction 510 (e.g., the area below the forecast demand curve 508 and above the simulated demand curve 506) may be achieved during the demand reduction window 504 as a result of the load shift event in which the setpoint temperatures of the selected water heaters may be reduced after the pre-heating. It should be noted that the load shift event in the demand reduction window 504 includes a load shed event in that the setpoint temperatures of the water heaters are decreased during the demand reduction window 504.

[0082] FIG. 5B shows an example plot 550 showing a load shed model output in accordance with one or more embodiments of the present disclosure.

[0083] Referring to FIG. 5B, the load shed event may occur between time tO and time tl, and may include a decrease in the selected w ater heaters’ setpoint temperatures. A forecast demand curve 552 (e.g., from the forecast data 114 of FIG. 1) and a simulateddemand curve 554 for the load shed event are shown. As a result of the load shed event, the power demand of the selected water heaters may decrease, resulting in a demand reduction 556 (e.g., the area above the simulated demand curve 554 and below the forecast demand curve 552).

[0084] Referring to FIGS. 1, 5 A, and 5B, when a demand reduction exceeds a threshold (e.g., zero or greater than zero), the utilities / aggregators 106 may issue the event instructions 116 via the user portal 108. Alternatively or in addition, the user portal 108 may automatically issue the event instructions 116 when event conditions (e.g., a threshold demand reduction) would be achieved based on the forecast data and the simulation for a load shed or load shift event.

[0085] FIG. 5C shows an example plot 560 of a pre-heating simulation and corresponding demand reduction, in accordance with one or more embodiments of the present disclosure.

[0086] Referring to FIG. 5C, the plot 560 shows a pre-heat window 562 and a load shed window 564 for a load shift event, including actual demand 566 for water heaters included in the event, baseline demand 568 (e.g., forecasted) for the water heaters included in the event, target demand 570 for the event, and the corresponding demand reduction 572 (e.g., from the baseline demand 568 to the actual demand 568 during the load shed window 564). In this manner, during the load shed window 564, the actual demand 566 is reduced from the baseline demand 568 to achieve the demand reduction 572. To ensure that the target demand 570 is satisfied for the participating water heaters during the load shed window 564, the pre-heat window 562 includes pre-heating the participating water heaters to provide thermal energy storage, resulting in the actual demand 566 increasing with respect to the baseline demand 568 during the pre-heat window 562.

[0087] FIG. 5D shows an example plot 580 of a forecasted power demand, a load shift simulation result, and a corresponding demand reduction, in accordance with one or more embodiments of the present disclosure.

[0088] Referring to FIG. 5D, the plot 580 shows a pre-heat window 582 and a DR window 584 (e.g., load shed window) for the load shift event, power demand 586 (e.g., forecasted), and power shifted demand 588 (e.g., simulation result) for the load shift event. As a result, a demand reduction 590 may be achieved, represented by a difference between the power demand 586 and the power shifted demand 588. As shown in FIG. 5D, the demand is increased during the pre-heat window 582 when the power shifted 588increases for the pre-heating of the participating water heaters with respect to the power demand 586, and the demand is decreased during the DR window 584 with respect to the power demand 586.

[0089] FIG. 6A is an example flow for a process 600 for controlling water heater electrical demand in accordance with one or more embodiments of the present disclosure.

[0090] At block 602, a device (or system, e.g., the user portal 108, the control devices 807 of FIG. 7) may request and receive forecasted electrical demand data for water heaters (e.g., the forecast data 114 for the water heaters 102 of FIG. 1). The device may issue one or more API calls (e.g., to the API gateway 230 of FIG. 2) requesting the forecast data, which may be generated by the forecasting system 104 and made available to the device via the API gateway 230.

[0091] At block 604, the device may identify a future demand reduction time window during which the forecasted electrical demand data exceed a threshold electrical demand (e.g., when electrical demand for a grid, or the water heaters in particular, is high). Such high electrical demand times may be candidates for demand reduction windows during which a load shed and / or load shift event for the water heaters may be implemented.

[0092] At block 606, the device may execute an electrical load shed event simulation for the future demand reduction time window. The simulation may be for a load shed setpoint event, a load shed watts event, a load shift setpoint event, or a load shed watts event (e.g., as shown in FIG. 3). Inputs to the load shed (setpoint) model 302 may include an event setpoint 310 (e.g., setpoint temperature for the load shed event) and an event duration 312 (e.g., a time duration for the load shed event). The output of the load shed setpoint model 302 may include an event simulation result 314 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shed event using the event setpoint 310 and the event duration 312.

[0093] Inputs to the load shed (watts) model 304 may include a target reduction 316 (e.g., electrical demand reduction) and an event duration 318 for the load shed event. Outputs of the load shed (watts model 304) may include an event simulation result 320 based on the target reduction 316 and the event duration 318, and may include event options 322 for the event to achieve the target reduction 316.

[0094] Inputs to the load shift (setpoint) model 306 may include a pre-heat setpoint 324 temperature, an event setpoint 326 temperature, and an event duration 328 for the load shift. An output of the load shift (setpoint) model 306 may include an event simulationresult 328 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shift event using the inputs.

[0095] Inputs to the load shift (watts) model 308 may include a target reduction 332 in water heater electrical demand and an event duration 334 for the load shift event. An output of the load shift (watts) model 308 may include an event simulation result 328 showing a forecast demand (e.g., from the forecast data 114 of FIG. 1) and a demand reduction caused by the load shift event using the inputs.

[0096] At block 608, the device may remotely control the water heaters (e.g., with proper user permissions and in accordance with relevant laws) to perform the load shed event (and optional load shift event) during the future demand reduction time window. The remote controlling may include generating and transmitting the event instructions 116 to signal which water heaters are to perform the event, and using which parameters (e.g., setpoint temperatures and times, etc.). There are three filters that may be applied to the selection of water heaters to include in the event: One filter for water heaters opted into the load shed or load shift operations, one filter for geographic area, and one filter for water heaters forecasted to have actual demand during a demand reduction window. In this manner, the water heaters may be remotely controlled via transmitted instructions that cause the water heaters to reduce their electrical use during the demand reduction time window, optionally in conjunction with a pre-heating operation as part of a load shift event.

[0097] In one or more embodiments, because the forecast data may include individual water heater forecasts, additional selection criteria for the water heaters to include the load shed and / or load shift event may be applied. For example, the water heaters to include in the event may be forecasted to have a threshold electrical demand during the demand reduction time window. In this manner, water heaters without sufficient demand during that time may be excluded.

[0098] In one or more embodiments, to determine the time window for pre-heating as part of a load shift event, the start time of the pre-heating window may be set as far back as to allow the water heating requiring the most time to heat its water to the setpoint temperature. Because the forecast data may include individual water heater data, this information may be identified so that the pre-heat window may be set to be long enough to allow all the selected water heaters for a load shift event to achieve the necessary pre-heating prior to a load shed during the demand reduction window to ensure hot water availability during the demand reduction window.

[0099] FIG. 6B is an example flow for a process 650 for controlling water heater electrical demand in accordance with one or more embodiments of the present disclosure.

[0100] At block 652, one or more water heaters (e.g., the water heaters 102 of FIG. 1) may provide their water heater data 112 to a forecasting system (e.g., forecasting system 104), in accordance with user opt-in and relevant laws. The water heater data 112 may include water heater device MAC address, product type (e g., model), timestamp for the data, state, zip code, ambient temperature data, lower tank temperature, upper tank temperature, power (e.g., watts) consumed, water heater configuration data, water heater setup data, and the like.

[0101] At block 654, the one or more water heaters may receive event commands (e.g., the event commands 118) for a load shed and / or load shift event. The event commands may signal to the one or more water heaters that a load shed and / or load shift event is scheduled, the start and end times for demand reduction windows, the start and end times for preheating windows (e.g., for a load shift event), operating modes, setpoint temperatures, and MAC addresses of water heaters included in the event.

[0102] At block 656, the one or more water heaters may set their operating parameters at the respective times for load shed and / or load shift events as signaled by the event commands. The preheating and / or demand reduction window7times may dictate when the water heaters are to set their temperatures to increased or decreased setpoints, which may be selected by the user requesting the events in the case of the load shed (setpoint) model 302 and the load shift (setpoint) model 306 of FIG. 3, or may be based on the minimum and maximum setpoints of respective operating modes of the water heaters in the cases of the load shed (watts) model 304 and the load shift (watts) model 308. By setting the operating parameters according to the event commands, the demand reduction may be achieved across the aggregated water heaters participating in the load shed and / or load shift event.

[0103] It is understood that the above descriptions are for purposes of illustration and are not meant to be limiting.

[0104] FIG. 7 is a block diagram illustrating an example of a computing device or computer system 700 which may be used in implementing the embodiments of the components in the previous figures. For example, the computing system 700 of FIG. 7may represent a control system for the water heaters 102 of FIG. 1, which may be integrated into the water heaters or may be implemented remotely from the water heaters, and may include components to facilitate the functions of the forecasting system 104, the user interfaces and communication capabilities of the user portal 108, and the demand reduction modeling of FIG. 3. The computer system (system) includes one or more processors 702-706, and control devices 707 (e.g., capable of performing the modeling, communications, user interfaces, and controls of FIGs. 1-3, generating and presenting the graphs of FIGs. 5 A and 5B. 7 and the processes 600 of FIG. 6A and 650 of FIG. 6B, including controls for the water heaters 102 to set their operating parameters). Processors 702-706 may include one or more internal levels of cache (not shown) and a bus controller 722 or bus interface unit to direct interaction with the processor bus 712. Processor bus 712, also known as the host bus or the front side bus, may be used to couple the processors 702-706 with the system interface 724. System interface 724 may be connected to the processor bus 712 to interface other components of the system 700 with the processor bus 712. For example, system interface 724 may include a memory controller 718 for interfacing a main memory 716 with the processor bus 712. The main memory 716 typically includes one or more memory cards and a control circuit (not shown). System interface 724 may also include an input / output (I / O) interface 720 to interface one or more I / O bridges 725 or I / O devices with the processor bus 712. One or more I / O controllers and / or I / O devices may be connected with the I / O bus 726, such as I / O controller 728 and I / O device 730, as illustrated.

[0105] I / O device 730 may also include an input device (not shown), such as an alphanumeric input device, including alphanumeric and other keys for communicating information and / or command selections to the processors 702-706. Another type of user input device includes cursor control, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processors 702-706 and for controlling cursor movement on the display device.

[0106] The system 700 may include one or more sensors 732 when the system 700 represents control circuitry of the water heaters 102. The one or more sensors 732 may include temperature sensors for water in one or more locations of the water heaters (and their optional tanks) and ambient temperature sensors, flow sensors, and the like.

[0107] System 700 may include a dynamic storage device, referred to as main memory 716, or a random access memory (RAM) or other computer-readable devices coupled tothe processor bus 712 for storing information and instructions to be executed by the processors 702-706. Main memory 716 also may be used for storing temporary variables or other intermediate information during execution of instructions by the processors 702-706. System 700 may include a read only memory (ROM) and / or other static storage device coupled to the processor bus 712 for storing static information and instructions for the processors 702-706. The system outlined in FIG. 7 is but one possible example of a computer system that may employ or be configured in accordance with aspects of the present disclosure.

[0108] According to one embodiment, the above techniques may be performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 716. These instructions may be read into main memory 716 from another machine-readable medium, such as a storage device. Execution of the sequences of instructions contained in main memory 716 may cause processors 702-706 to perform the process steps described herein. In alternative embodiments, circuitry may be used in place of or in combination with the software instructions. Thus, embodiments of the present disclosure may include both hardware and software components.

[0109] A machine readable medium includes any mechanism for storing or transmitting information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). Such media may take the form of, but is not limited to, non-volatile media and volatile media and may include removable data storage media, non-removable data storage media, and / or external storage devices made available via a wired or wireless network architecture with such computer program products, including one or more database management products, web server products, application server products, and / or other additional software components. Examples of removable data storage media include Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc Read-Only Memory (DVD-ROM), magneto-optical disks, flash drives, and the like. Examples of non-removable data storage media include internal magnetic hard disks, SSDs, and the like. The one or more memory devices 806 may include volatile memory' (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and / or non-volatile memory (e.g., read-only memory (ROM), flash memory, etc.).

[0110] Computer program products containing mechanisms to effectuate the systems and methods in accordance with the presently described technology may reside in mainmemory 816, which may be referred to as machine-readable media. It will be appreciated that machine-readable media may include any tangible non-transitory medium that is capable of storing or encoding instructions to perform any one or more of the operations of the present disclosure for execution by a machine or that is capable of storing or encoding data structures and / or modules utilized by or associated with such instructions. Machine-readable media may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more executable instructions or data structures.

[0111] FIG. 8 is an example plot 800 of water heater forecast demand data using given coefficients for a forecast model, in accordance with one or more embodiments of the present disclosure.

[0112] Referring to FIG. 8, the plot 800 may show water heater forecast demand using the POWRWATT forecast model described herein (e.g., for the forecasting system 104 to generate the forecast data 114 of FIG. 1). The forecast model may use seasonal data 802, and a moving average window 804 (e.g., three days as shown, but can be another time window ) as time series data. The seasonal data 802 and the moving average window 804 data may be used to train the model for multiple device types (e.g., by including the data from multiple device types in the training data).

[0113] Once the model has a seasonal period 806 worth of data (e.g., 24 hours or another time period), the model may predict a forecast value 808 based on the training data, non-seasonable data 810, and a moving average window 812 (e.g., four days or another period). The forecast value 808 may be for any one or more types of devices, as the model may use the corresponding coefficients for the device type(s) being forecasted and from the training data.

[0114] The model may use an average POWRWATT sum, a minimum POWRWATT sum, or a maximum POWRWAT sum. For example:avg(POWRWATT)15_minMACaddressmin(POWRWATT)15_minMACaddressmax (POWRW ATT)15_min.MACaddressFor every time interval (e.g., 15 minutes or another interval), for one or more devices (e.g., indicated by their MAC addresses), the average, minimum, or maximum POWRWATT value may be used for the one or more devices. In this manner, rather than the model relying on every instantaneous POWRWATT value for each included device, the minimum, maximum, or average POWRWATT value for the one or more devices over the time interval may representative of the one or more devices during the interval. In some use cases, the maximum POWRWATT value may be preferable so that demand below the maximum POWRWATT value is consistent with a demand reduction goal.

[0115] Ion one or more embodiments, the forecast model may use a seasonal autoregressive integrated moving average with eXogenerous factors (SARIMAX model), which may be linear and may allow for use of historical data in a sliding time window to predict future values according to the following equation:<ppmPc^d^yt= Adt) + eq(L)6Q(Lsyt,where cppL) is the non-seasonal autoregressive lag polynomial, p Ls) is the seasonal autoregressive lag polynomial, AdA°ytis the time series differenced d times, and seasonally differenced D times, A(t) is the trend polynomial (including the intercept), Sq(L) is the non-seasonal moving average lag polynomial, and 6Q(LS) is the seasonal moving average lag polynomial. The non-seasonal data is data collected from the individual water heaters. The seasonal data supports the non-seasonal aspects (e.g., POWRWATT data). For example, the seasonal data may indicate what the weather was for corresponding POWRWATT data at a given time and location.

[0116] FIG. 9 A shows an example user interface 900 for simulating or scheduling a load shift (watts) event, in accordance with one or more embodiments of the present disclosure.

[0117] Referring to FIG. 9A, the user interface 900 may be accessible to the user portal 108 of FIG. 1, and may allow a user (e.g., the utilities and / or aggregators 106) to schedule or simulate a load shift event using the load shift (watts) model 308 of FIG. 3. The user interface 900 may allow the user to provide / select multiple inputs for the load shift event, such as the program 902 (e.g., program identifier), an event name 904, an event type 906 (e.g., load shift (watts) in this example, but other event types include load shift (setpoint), load shed (setpoint), and load shed (watts) as shown in FIG. 3), an event start date 910, an event start time 912, an event end date 914, an event end time 916, an event frequency 918 (e.g., whether the event is to repeat and how often), event participants such as a group / location 920 of devices and a location type 922 for the group / location 920. Basedon the selected group / location 920, the qualifying number of devices targeted 924 may be identified and displayed. The load shift (watts) event type may allow the user to input a target demand reduction 926 for the water heaters (e.g., in megawatts, kilowatts, or another energy unit). The user interface 900 may allow the user to simulate the event 928 and / or schedule the event 930 based in the input parameters.

[0118] 9B shows an example user interface 950 for simulating or scheduling a load shift (setpoint) event, in accordance with one or more embodiments of the present disclosure.

[0119] Referring to FIG. 9B, the user interface 950 may be accessible to the user portal 108 of FIG. 1, and may allow a user (e.g., the utilities and / or aggregators 106) to schedule or simulate a load shift event using the load shift (setpoint) model 306 of FIG. 3. The user interface 950 may allow the user to provide / select multiple inputs for the load shift event, including at least a portion of the inputs of the user interface 900 of FIG. 9A, and including a device type 951 input for the target devices. Instead of the target demand reduction 926 for the load shift (watts) event, the user interface 950, when a load shift (setpoint) event is selected, may allow the user to input a pre-heating setpoint 952, a preheating mode 954 for the water heaters (e.g., energy saver, high demand, etc.), an event setpoint 956, and an event mode 956 for the water heaters (e.g., energy saver, high demand, etc.). The user interface 900 may allow the user to simulate the event 928 and / or schedule the event 930 based in the input parameters.

[0120] Referring to FIGs. 1, 2, 9A, and 9B, when the user simulates a load shift event in FIGs. 9A and 9B, the user input parameters may determine the event simulation result for the load shift (watts) or load shift (setpoint) event. The event simulation result 330 of FIG. 3 for load shift (setpoint) may include plots of the forecasted demand for water heaters participating in the event and of the reduced demand for those water heaters as a result of the load shift event using the event setpoint and the event duration. By aggregating the demand reduction for each of the participating water heaters during the event, the total demand reduction for the load shift event may be shown by the event simulation result 330. The event simulation result 330 also may include plots of the forecasted demand for the participating w ater heaters during the preheating window, along with the start and end times of the preheating w indow.

[0121] The event simulation result 336 may include plots of the forecasted demand for water heaters participating in the event and of the reduced demand for those water heaters as a result of the load shift event using the target reduction 332 and the event duration 334.The start and end times of the preheating window may be shown, and they may be selected to achieve the target reduction 332 for the event duration 334 based on the factors described above for the participating water heaters. For example, the preheating window selected by the event simulation result 336 may depend on the longest time needed for any of the participating water heaters to achieve the necessary energy storage for the load shed that occurs after the preheating window. The event simulation result 336 may show how the target reduction 332 for the event duration 334 may be achieved, what that would include (e g., the timing of the preheating window and the load shed), and what the maximum demand reduction would be.

[0122] Embodiments of the present disclosure include various steps, which are described in this specification. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software and / or firmware.

[0123] Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations together with all equivalents thereof.

[0124] The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0125] Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and / or operations. Thus, such conditional language is not generally intended to imply that features, elements, and / or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input orprompting, whether these features, elements, and / or operations are included or are to be performed in any particular implementation.

[0126] Many modifications and other implementations of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

[0127] In this specification, terms denoting direction, such as vertical, up, down, left, right etc. or rotation, should be taken to refer to the directions or rotations relative to the corresponding drawing rather than to absolute directions or rotations unless the context require otherwise.

[0128] Wherever it is used, the word '‘comprising” is to be understood in its “open” sense, that is, in the sense of “including”, and thus not limited to its “closed” sense, that is the sense of “consisting only of’. A corresponding meaning is to be attributed to the corresponding words “comprise”, “comprised” and “comprises” where they appear.

[0129] It will be understood that the invention disclosed and defined herein extends to all alternative combinations of two or more of the individual features mentioned or evident from the text. All of these different combinations constitute various alternative aspects of the invention.

[0130] While particular embodiments of this invention have been described, it will be evident to those skilled in the art that the present invention may be embodied in other specific forms without departing from the essential characteristics thereof. The present embodiments and examples are therefore to be considered in all respects as illustrative and not restrictive, and all modifications which would be obvious to those skilled in the art are therefore intended to be embraced therein.

[0131] The term “cloud computing” or “cloud” at least in some examples refers to a paradigm for enabling network access to a scalable and elastic pool of shareable computing resources with self-service provisioning and administration on-demand and without active management by users. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities offered via cloud computing that are invoked using a defined interface (e.g., an API or the like).

[0132] The term ‘’compute resource” or simply “resource” at least in some examples refers to an object w ith a type, associated data, a set of methods that operate on it, and, if applicable, relationships to other resources. Additionally or alternatively, the term “compute resource” or “resource” at least in some examples refers to any physical or virtual component, or usage of such components, of limited availability within a computer system or network. Examples of computing resources include usage / access to, for a period of time, servers, processor(s), storage equipment, memory' devices, memory areas, networks, electrical power, input / output (peripheral) devices, mechanical devices, network connections (e.g., channels / links, ports, network sockets, and the like), operating systems, virtual machines (VMs), software / applications, computer files, and / or the like. A “hardware resource” at least in some examples refers to compute, storage, and / or netw ork resources provided by physical hardware element(s). A “virtualized resource” at least in some examples refers to compute, storage, and / or network resources provided by virtualization infrastructure to an application, device, system, and the like. The term “network resource” or “communication resource” at least in some examples refers to resources that are accessible by computer devices / systems via a communications network. The term “system resources” at least in some examples refers to any kind of shared entities to provide services, and includes computing and / or network resources. System resources may be considered as a set of coherent functions, netw ork data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0133] The term “cloud service provider” or “CSP” at least in some examples refers to an organization that operates or otherwise provides cloud resources including, for example, centralized, regional, and / or edge data centers and / or the like. In some examples, the term “cloud computing” refers to computing resources and services offered by a CSP.

[0134] The term “data center” at least in some examples refers to a purpose-designed structure that is intended to house multiple high-performance compute and data storage nodes such that a large amount of compute, data storage and netw ork resources are present at a single location. This often entails specialized rack and enclosure systems, suitable heating, cooling, ventilation, security, fire suppression, and power delivery systems. The term may also refer to a compute and data storage node in some contexts. A data centermay vary in scale between a centralized or cloud data center (e.g., largest), regional data center, and edge data center (e.g., smallest).

[0135] The term “application programming interface” or “API” at least in some examples refers to a set of subroutine definitions, communication protocols, and tools for building software. Additionally or alternatively, the term “application programming interface” or “API” at least in some examples refers to a set of clearly defined methods of communication among various components. In some examples, an API may be defined or otherwise used for a web-based system, operating system, database system, computer hardware, software library, and / or the like.

[0136] The terms “instantiate,” “instantiation,” and the like at least in some examples refers to the creation of an instance. In some examples, an “instance” also at least in some examples refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0137] The term “feature” at least in some examples refers to an individual measureable property7, quantifiable property, or characteristic of a phenomenon being observed.Additionally or alternatively, the term “feature” at least in some examples refers to an input variable used in making predictions. At least in some examples, features may be represented using numbers / numerals (e.g., integers), strings, variables, ordinals, real-values, categories, and / or the like.

[0138] The term “mathematical model” at least in some examples refer to a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs including governing equations, assumptions, and constraints. The term “statistical model” at least in some examples refers to a mathematical model that embodies a set of statistical assumptions concerning the generation of sample data and / or similar data from a population; in some examples, a “statistical model” represents a data-generating process.

Claims

CLAIMSThat which is claimed is:

1. A method for controlling water heater electrical loads, the method comprising: identifying, by at least one processor, a future demand reduction time window within a time window during which forecasted electrical demand data for water heaters exceeds a threshold electrical demand;executing, the at least one processor, an electrical load shift event simulation for the water heaters for the future demand reduction time window, wherein the electrical load shift event simulation comprises:estimating, by the at least one processor, based on the forecasted electrical demand data and an amount of increase to setpoint temperatures of the water heaters during a future preheating time that precedes the future demand reduction time window, an amount of energy needed to preheat water in the water heaters during the future preheating time; andestimating, by the at least one processor, a start time for the future preheating time and an end time for the future preheating time based on the amount of increase to the setpoint temperatures; andremotely controlling, by the at least one processor, based on the electrical load shift event simulation being estimated to reduce electrical demand of the water heaters with respect to the forecasted electrical demand data during the future demand reduction time window, the water heaters to decrease their setpoint temperatures to a first setpoint temperature during the future demand reduction time window and to increase their setpoint temperatures to a second setpoint temperature during the future preheating time.

2. The method of claim 1, wherein executing the electrical load shift event simulation comprises generating an event simulation result estimating electrical demand of the water heaters based on user inputs, via the user interface, comprising the first setpoint temperature and a duration of the future demand reduction time window.

3. The method of claim 1, wherein executing the electrical load shift event simulation comprises generating an event simulation result estimating electrical demand of the water heaters and options based on user inputs, via the user interface, comprising a targetelectrical demand reduction for the water heaters and a duration of the future demand reduction time window.

4. The method of claim 1, further comprising:receiving, via the user interface, user inputs comprising the second setpoint temperature, the first setpoint temperature, and a duration of the future demand reduction time window; andgenerating an event simulation result of the electrical load shift event based on the user inputs,wherein the second setpoint temperature is greater than the first setpoint temperature.

5. The method of claim 1, further comprising:receiving, via the user interface, user inputs comprising a target electrical demand reduction for the water heaters and a duration of the future demand reduction time window; andgenerating an event simulation result of the electrical load shift event based on the user inputs,wherein the event simulation result indicates the second setpoint temperature, and wherein the second setpoint temperature is greater than the first setpoint temperature.

6. The method of claim 1, further comprising:generating user interface data comprising the forecasted electrical demand data and an event simulation result comprising an estimated electrical demand of the water heaters based on the electrical load shift event simulation; andcausing presentation of the user interface data using the user interface.

7. The method of claim 1, further comprising:identifying a first subset of the water heaters in a selected geographic area whose users have opted into load shift events;identifying a second subset of the first subset of the water heaters for which the forecasted electrical demand data indicate no hot water demand during the future demand reduction time window; andgenerating a third subset of the first subset of the water heaters by removing the second subset from the first subset of the water heaters,wherein remotely controlling the water heaters comprises remotely controlling the third subset of the water heaters instead of the second subset and instead of additional water heaters outside of the selected geographic area.

8. The method of claim 1, wherein the forecasted electrical demand data is based on a maximum, minimum, or average instantaneous power usage of the water heaters during a time interval.

9. The method of claim 8, wherein the forecasted electrical demand data is further based on a seasonal auto-regressive integrated moving average model using seasonal data of the water heaters, non-seasonal data of the water heaters, and respective coefficients for respective types of the water heaters.

10. A non-transitory computer-readable medium comprising instructions that, when executed by at least one processor, cause the at least one processor to:identify a future demand reduction time window within a time window during which forecasted electrical demand data for water heaters exceeds a threshold electrical demand;execute an electrical load shift event simulation for the water heaters for the future demand reduction time window, wherein the electrical load shift event simulation comprises to:estimate, based on the forecasted electrical demand reduction during the future demand data and an amount of increase to setpoint temperatures of the water heaters during a future preheating time that precedes the future demand reduction time window, an amount of energy needed to preheat water in the water heaters during the future preheating time; andestimate a start time for the future preheating time and an end time for the future preheating time based on the amount of increase to the setpoint temperatures remotely control, based on the electrical load shift event simulation being estimated to reduce electrical demand of the w ater heaters with respect to the forecastedelectrical demand data during the future demand reduction time window, the water heaters to decrease their setpoint temperatures to a first setpoint temperature during the future demand reduction time window and to increase their setpoint temperatures to a second setpoint temperature during the future preheating time.

11. The non-transitory computer-readable medium of claim 10, wherein to execute the electrical load shift event simulation comprises to generate an event simulation result estimating electrical demand of the water heaters based on user inputs, via the user interface, comprising the first setpoint temperature and a duration of the future demand reduction time window.

12. The non-transitory computer-readable medium of claim 10, wherein to execute the electrical load shift event simulation comprises to generate an event simulation result estimating electrical demand of the water heaters and options based on user inputs, via the user interface, comprising a target electrical demand reduction for the water heaters and a duration of the future demand reduction time window.

13. The non-transitory computer-readable medium of claim 10, wherein the execution of the instructions further causes the at least one processor to:receive, via the user interface, user inputs comprising the second setpoint temperature, and a duration of the future demand reduction time window; and generate an event simulation result of the electrical load shift event based on the user inputs,wherein the second setpoint temperature is greater than the first setpoint temperature.

14. The non-transitory computer-readable medium of claim 10, wherein the execution of the instructions further causes the at least one processor to:receive, via the user interface, user inputs comprising a target electrical demand reduction for the water heaters and a duration of the future demand reduction time window; andgenerate an event simulation result of the electrical load shift event based on the user inputs,wherein the event simulation result indicates the second setpoint temperature, and wherein the second setpoint temperature is greater than the first setpoint temperature.

15. The non-transitory computer-readable medium of claim 10, wherein the execution of the instructions further causes the at least one processor to:generate user interface data comprising the forecasted electrical demand data and an event simulation result comprising an estimated electrical demand of the water heaters based on the electrical load shift event simulation; andcause presentation of the user interface data using the user interface.

16. The non-transitory computer-readable medium of claim 10, wherein the execution of the instructions further causes the at least one processor to:identify a first subset of the water heaters in a selected geographic area whose users have opted into load shift events;identify a second subset of the first subset of the water heaters for which the forecasted electrical demand data indicate no hot water demand during the future demand reduction time window: andgenerate a third subset of the first subset of the water heaters by removing the second subset from the first subset of the water heaters,wherein to remotely control the water heaters comprises to remotely control the third subset of the water heaters instead of the second subset and instead of additional water heaters outside of the selected geographic area.

17. The non-transitory computer-readable medium of claim 10, wherein the forecasted electrical demand data is based on a maximum, minimum, or average instantaneous power usage of the water heaters during a time interval.

18. The non-transitory computer-readable medium of claim 17, wherein the forecasted electrical demand data is further based on a seasonal auto-regressive integrated moving average model using seasonal data of the water heaters, non-seasonal data of the water heaters, and respective coefficients for respective types of the water heaters.

19. A system for controlling water heater electrical loads, the system comprising: memory coupled to at least one processor, wherein the at least one processor is configured to:identify a future demand reduction time window during a time window during which forecasted electrical demand data for water heaters exceeds a threshold electrical demand;execute an electrical load shift event simulation for the water heaters for the future demand reduction time window, wherein the electrical load shift event simulation comprises to:estimate, based on the forecasted electrical demand reduction data and an amount of increase to setpoint temperatures of the water heaters during a future preheating time that precedes the future demand reduction time window, an amount of energy needed to preheat water in the water heaters during the future preheating time; andestimate a start time for the future preheating time and an end time for the future preheating time based on the amount of increase to the setpoint temperatures;remotely control, based on the electrical load shift event simulation being estimated to reduce electrical demand of the water heaters with respect to the forecasted electrical demand data during the future demand reduction time window, the water heaters to decrease their setpoint temperatures to a first setpoint temperature during the future demand reduction time window and to increase their setpoint temperatures to a second setpoint temperature during the future preheating time.

20. The system of claim 19. wherein to execute the electrical load shift event simulation comprises to generate an event simulation result estimating electrical demand of the w ater heaters based on user inputs, via the user interface, comprising the first setpoint temperature and a duration of the future demand reduction time window.

21. The system of claim 20, wherein to execute the electrical load shift event simulation comprises to generate an event simulation result estimating electrical demand of the water heaters and options based on user inputs, via the user interface, comprising atarget electrical demand reduction for the water heaters and a duration of the future demand reduction time window.

22. The system of claim 20. wherein the at least one processor is further configured to:receive, via the user interface, user inputs comprising the second setpoint temperature, the first setpoint temperature, and a duration of the future demand reduction time window; andgenerate an event simulation result of the electrical load shift event based on the user inputs,wherein the second setpoint temperature is greater than the first setpoint temperature.

23. The system of claim 20. wherein the at least one processor is further configured to:receive, via the user interface, user inputs comprising a target electrical demand reduction for the water heaters and a duration of the future demand reduction time window; andgenerate an event simulation result of the electrical load shift event based on the user inputs,wherein the event simulation result indicates the second setpoint temperature, and wherein the second setpoint temperature is greater than the first setpoint temperature.

24. The system of claim 20. wherein the at least one processor is further configured to:generate user interface data comprising the forecasted electrical demand data and an event simulation result comprising an estimated electrical demand of the water heaters based on the electrical load shift event simulation; andcause presentation of the user interface data using the user interface.

25. The system of claim 20, wherein the at least one processor is further configured to:identify a first subset of the water heaters in a selected geographic area whose users have opted into load shift events;identify a second subset of the first subset of the water heaters for which the forecasted electrical demand data indicate no hot water demand during the future demand reduction time window; andgenerate a third subset of the first subset of the water heaters by removing the second subset from the first subset of the water heaters,wherein to remotely control the water heaters comprises to remotely control the third subset of the water heaters instead of the second subset and instead of additional water heaters outside of the selected geographic area.

26. The system of claim 20, further comprising a remote control system configured to:receive a command, from the at least one processor, signaling first water heaters to be included in an electrical load shift event and operating parameters for the water heaters, the operating parameters comprising the start time and the end time for the future preheating time; andremotely controlling the first water heaters to be included in the electrical load shift event by applying the operating parameters at the first water heaters.

27. The system of claim 20, wherein the forecasted electrical demand data is based on a maximum, minimum, or average instantaneous power usage of the water heaters during a time interval.

28. The system of claim 20, wherein the forecasted electrical demand data is further based on a seasonal auto-regressive integrated moving average model using seasonal data of the water heaters, non-seasonal data of the water heaters, and respective coefficients for respective types of the water heaters.

Images