Introduction

In the US and many other countries around the world, the daily peak load experienced is frequently much higher than the daily average load. This low load factor causes inefficient operation of generation, transmission and distribution resources. To avoid system stress conditions due to increasing demand [1] and to use power system resources more efficiently, demand response (DR) can serve as an effective tool to reduce peak demand through demand-side load curtailment [2]. A fully automated DR program [3] is one that can provide load management to meet electric utility needs without direct customer intervention. With an increasing interest in DR programs for residential customers in recent years, various automated DR approaches have been developed [4–15, 17–23, 25].

To enable DR implementation, different communication technologies for load control have been implemented, i.e., ZigBee [9], power line carrier (PLC) [10], ZigBee and PLC [11], infrared-based remote controls with ZigBee communication [12], and BACnet [13]. Different methodologies have been applied. For example, authors in [14] implemented a dynamic priority based scheduling scheme; authors in [15] employ a convex programming based solution, whereas authors in [17, 25] employed dynamic programming based approaches. Authors in [18] proposed implementation for a green home with built-in PV and motorized blinders. Most work in the literature relies on real-time/dynamic pricing-based scheduling schemes [19, 20]. In spite of being less common than priced-based DR programs, tremendous untapped DR potentials lie in incentive-based DR programs that can provide up to 80 % peak load reduction potential in US according to FERC [21]. In existing literature, most works provide simulation results for proposed algorithms [19, 20, 22], with very few papers focusing on real experiments in smart house [23].

We have developed an intelligent Energy Management algorithm [24], which is an automated incentive-based DR algorithm for residential customers. The initial hardware demonstration of the algorithm was conducted in a laboratory environment at the Advanced Research Institute of Virginia Tech (VT-ARI). Communication failures and data errors were observed during the laboratory experiment. This led the system to read erroneous power consumption data from appliances causing flawed DR decisions. The building energy management (BEM) algorithm presented in this paper is more robust against communication failures and data errors, which surfaced during previous laboratory experiments. This algorithm can be applied to homes, offices and industrial buildings. This paper focuses on the validation of this improved algorithm in field implementation, by designing realistic case study scenarios in the smart house located at Yildiz Technical University (YTU)—Davutpasa campus in Istanbul, Turkey. The paper reports the methodology of designing the case scenario, modification of the algorithm to suit the deployment environment, and experimental results from the deployment to show the usefulness and pragmatism of the designed algorithm. The contribution also includes identifying lessons learned from the field demonstration.

The rest of the paper is structured as follows: “The Building Energy Management (BEM) Algorithm” section discusses the BEM algorithm, especially focusing on the improvements made based on learnings from previous laboratory experiments. Then, “YTU Smart House and Its Integration with the BEM Algorithm with Further Modification” section describes the deployment environment: the YTU smart house and modification of the BEM algorithm to integrate it with the smart house. After that, “Design of Realistic Case Scenarios” section discusses the design methodology of the case scenarios for implementation. Later, “Discussions of Case Studies” section presents the case studies, discussion of the results from smart house implementation, and the lessons learned. Finally, “Conclusion” section concludes the paper.

The Building Energy Management (BEM) Algorithm

This section briefly describes the improved energy management algorithm to add robustness against communication failures and data errors faced during laboratory experiments.

During laboratory experiments with our previously developed algorithm, we faced issues of communication failures and data errors. We had used ZigBee based communication between a central energy management unit and the load controllers to collect sensor data and transmit DR decisions. The reasons underlying the occurrence of communication failures/data errors were found to be either communication errors from failure to communicate between the central unit and load controllers due to package drop or corrupted frames; or data errors due to microcontroller read errors. The laboratory experiment indicated that the communication failure/data error rates of these load controllers are in the range of 0.5–3.8 %.

To avoid errors in operation, the VT’s energy management algorithm was improved to incorporate robustness against communication failures and data errors by incorporating a popular method used in communication networks: automatic repeat request (ARQ) [26, 27]. Although another popular method named forward error correction (FEC) is very effective in fixing bit errors by adding redundancy bits and error correction codes, it cannot be implemented in our case, as it compromises throughput due to limited resources in the smart plugs. On the other hand, ARQ methods [28] are simple to implement in sensor networks with low resources, and achieve reasonable throughput. We implemented a combination of the stop-and-wait (SW) and selective repeat (SR) ARQ schemes [26, 27] with some modifications of our own. In SW, sender waits for acknowledgement after transmitting packets, and in case of negative acknowledgement or no response time-out, re-sends the packet. In the basic SW scheme, this re-transmission continues until a positive acknowledgement is received. But for our case, we cannot indefinitely continue retransmission as that will stop the BEM from making decisions.

Fig. 1
figure 1

Improved BEM algorithm to handle communication failures/data errors

Full size image

Therefore, in our modified algorithm, the BEM sends data request to each smart plug, and stops and waits for its response for a time-out of 5 s. If no/erroneous response is detected, the BEM uses the last recorded correct data for that smart plug and goes forward to send data request to the next one. At each cycle, the BEM keeps a counter of failed communications for each smart plug, and in case of three consecutive failures with a particular smart plug, it announces a warning signal indicating communication lost with that smart plug. The improved algorithm is shown in Fig. 1. This improvement, in spite of its simplicity, successfully prevents BEM from using incorrect appliance data for calculations, thereby making it more resilient to handle communication failures/data errors. This discussion of modification is presented here to report the update from our last algorithm before going into the discussion of field demonstration.

The algorithm in Fig. 1 is the BEM algorithm for residential applications. It focuses on power-intensive loads commonly available at households: water heater (WH), space cooling/heating unit (AC), clothes dryer (CD) and electric vehicle (EV). The demand response is implemented through DR events designed by utilities. A DR event is defined as a period of time during which the total power consumption of a household is to be limited within a demand limit specified by the utility. This is similar to ‘scenario power’ in [29, 30], but in the Virginia Tech model, the demand limit is imposed only during the DR event to ensure peak load curtailment. Another variation of this implementation is possible where the utility specifies the amount of power (kW) to curtail instead of the demand limit. The customer can be motivated to participate in DR events through monthly or annual monetary incentives, besides savings due to less consumption during peak-pricing period. To implement this, the utility sends a signal to the customer with demand limit and DR event duration prior to the DR event. Also, the customer selects the priorities and comfort level settings for the power-intensive loads. These settings can also be factory-preset considering load types, as in [29]. The BEM algorithm starts by collecting customer inputs of load priority and comfort level settings and utility inputs of demand limit and DR event duration. Then it starts collecting data from the sensors and the smart plugs/smart appliances. While collecting data, it employs the improvement just discussed. Once data from all appliances have been collected, the algorithm checks if the current ON/OFF status of appliances violates any comfort level settings or the demand limit. If no demand limit has been imposed, the algorithm turns ON/OFF the appliances to maintain the comfort level settings with efficient energy usage. On the other hand, during DR event, the algorithm restricts the total power consumption within the specified demand limit. In this case, it uses the preset/customer-defined priority settings with the comfort level settings to decide which loads to interrupt in case of demand limit violation. This is discussed in more details in [24]. The decisions are then conveyed to the smart appliances/smart plugs to implement changes in load status.

Although the algorithm shown in Fig. 1 is for residential customers, this can be applied to commercial/industrial buildings as well. For example, for commercial buildings, Heating, Ventilation and Air Conditioning (HVAC) loads, lighting loads, office plug-loads and Electric Vehicle chargers can be considered for full/partial load curtailment using this BEM algorithm. Similarly, different sets of power-intensive loads can be chosen in industrial buildings for DR.

The following sections present the validation of the BEM algorithm for residential applications through field implementation in a smart house environment.

YTU Smart House and Its Integration with the BEM Algorithm with Further Modification

The test-bed was a pilot smart house project at Yildiz Technical University (YTU) Davutpasa Campus, Istanbul, Turkey, which is financially supported by Istanbul Development Agency (ISTKA) [31].

Loads in the YTU Smart House

The 35 square meter smart house prototype was built inside a research laboratory building at the YTU Davutpasa campus. The prototype consists of a living room with a kitchen, a study room and a bathroom. It is equipped with typical household appliances. An electric vehicle (EV) charging station is also a part of the smart house. Note that both solar and wind electricity available from the building roof-top can be integrated into the smart house, together with a power conditioning system and a battery bank. The smart house network is shown in Fig. 2.

Fig. 2
figure 2

General concept of the YTU smart home project

Full size image

4-Noks\(\textregistered \) Smart Plugs for Load Monitoring and Control

In the smart house, 4-noks\(\textregistered \) smart plugs are used as load control devices [32]. Each appliance is connected to an addressable 4-noks\(\textregistered \) smart plug that uses ZigBee wireless communication to allow its monitoring and control from the central computer. While power-intensive loads are to be controlled by the smart plug, all critical loads are only monitored. In addition to smart plugs, smart temperature sensors are also installed in the smart house, which provide room temperature data to the central computer. The EV charging station can also be turned ON/OFF from the main computer using a 4-noks\(\textregistered \) ZR-HMETER.D-M [33].

Integration of the BEM to the YTU Smart House

To allow our BEM algorithm to control appliances in the smart house, the improved BEM algorithm discussed in “The Building Energy Management (BEM) Algorithm” section is embedded in the main computer that communicates with all other devices. The central computer collects electrical consumption data from all appliances and implements control decisions by communicating with selected smart plugs that provide necessary interface between appliances and electrical outlets.

In order to enable the implementation of BEM algorithm in a smart house, some other modifications in the algorithm were necessary to control the smart house loads and smart plugs, as discussed below.

Modification of the BEM Algorithm Taking into Account Deferrable, Non-Interruptible Loads

Some selected loads in a smart house environment do not fall into the categories discussed in “The Building Energy Management (BEM) Algorithm” section. These are deferrable/non-interruptible loads, which include a washing machine and a dishwasher. These loads are not suitable for interruption by the BEM during a DR event. This is because, for some washing machine and dishwasher models, if their operation is interrupted, the whole washing cycle must be restarted. Hence, the BEM algorithm has been modified to defer the start time of load cycle in this category until the end of a DR event.

Modification of BEM Algorithm Taking into Account Data Collection of 4-noks\(\textregistered \) Smart Plugs

In our laboratory experiments, each load controller was sent data requests once every minute, hence if there was a communication failure during a single communication request/response, it resulted in missed data for that particular minute only. On the other hand, in the YTU smart house, data was collected from the 4-noks\(\textregistered \) smart plugs several times during 1 min intervals. Hence, even one successful communication with a smart plug during a minute was sufficient for BEM to make decisions. Due to this fact, the BEM algorithm was further modified to ignore communication failures with a smart plug during a given minute, if there was at least one successful communication with that smart plug during that minute. The field implementation is reported in “Design of Realistic Case Scenarios” section below.

Design of Realistic Case Scenarios

In this section, assumptions and data used in the formation of case studies are discussed, including surveys of appliance usage, customer preferences and load priorities, assumptions for a DR event and load profiles of different appliances.

Survey of Appliance Usage in Turkish Households

In order to design valid case studies, the consumption profile of typical Turkish customer building is required. A survey was conducted among 10 Turkish customers to build such a profile. Customers were asked to provide the time and duration of usage of each appliance, including water usage, on a regular work day. All participants had working hours from 09:00 to 17:00 regardless of the season. Based on the cumulative survey results, average usage profiles of all smart house appliances were generated to represent typical appliance usage profiles of Turkish customers. Figure 3 depicts typical usage times and durations of selected appliances on a regular weekday in summer and winter.

Fig. 3
figure 3

Appliance usage time for an average Turkish household, determined from the survey, for summer and winter

Full size image

Notice a minimal appliance usage during customers’ absence from home (08:00–18:00 including travel time to and from work), and sleeping hours (midnight to 06:00) where partial lighting, i.e. porch/corridor lighting, is ON. Most appliances are used either in the morning from 06:00 to 08:00, or in the evening from 18:00 to midnight. The hot water usage profile from the survey was used to determine the operation of an electric water heater during both summer and winter seasons. Lighting was used for shorter duration during summer due to extended daytime.

Survey of Customer Preference and Load Priorities

A separate survey was conducted on the same group of customers to determine typical load priority and preference settings for the four power-intensive loads to be controlled by the BEM. For priority settings, most customers responded with the following priority sequence: \(\hbox {WH}>\hbox {AC}>\hbox {CD}>\hbox {EV}\). The average preference setting for a water heater (WH) from the survey was to maintain the hot water temperature within 43–46 \(^{\circ }\)C (\(\sim \)110–115 \(^{\circ }\)F) range. And the room temperature set point was preferred to be 23 \(^{\circ }\)C (\(\sim \)74 \(^{\circ }\)F) during winter and 24 \(^{\circ }\)C (\(\sim \)76 \(^{\circ }\)F) during summer. The customer preference was for the clothes dryer (CD) to finish its job by midnight. Also, both its maximum OFF time and minimum ON time was specified to be 30 min. An electric vehicle (EV) was preferred to finish its job by 08:00 in the morning with a minimum charging time of 30 min before any interruption could occur.

Assumptions for DR Events

To design the demand limit and duration of a DR event for the case studies, the total household consumption without DR event was generated using the appliance usage profiles from the above surveys. Figure 4 shows the total household consumption during morning and evening hours for summer and winter when customers are at home.

Fig. 4
figure 4

Total household consumption profiles without DR for summer and winter

Full size image

The morning peak demand was observed between 06:00 and 08:00 both in the summer and winter, with the summer peak being 3.6 kW and winter peak being 3.8 kW. The evening peak demand was observed between 18:00 and 21:00, with a summer peak of 10.8 kW and winter peak of 10.2 kW. Morning peak loads are much lower than evening peak loads, hence a morning peak period is not a candidate for a DR event. Since typical evening peaks occur between 18:00 and 21:00, this study considers that a local utility imposes a demand reduction target to limit the peak demand of residential customers from 18:00–21:00.

Both in winter and summer, a demand limit of 6.7 kW (or, approx. 33 % load reduction) is imposed during a DR event. This value of demand limit is selected for the case studies based on our simulation results to avoid the rebound of peak demand (i.e., demand restrike) during an off-peak period after a DR event ends.

Load Profiles

Water Heater

A space heater with the same power rating as a typical electric water heater in Turkey was used to represent the electric water heater in the smart house. The measured load profile of this space heater is shown in Fig. 5a. It was placed outside the smart house during the experiment so that the additional heat generated did not affect the room temperature inside smart house. It is considered the highest priority load.

Space Cooling/Heating Unit

The space cooling/heating unit was operated in the heating mode for winter case studies with the room temperature set point of 23 \(^{\circ }\)C (\(\sim \)74 \(^{\circ }\)F) and a dead-band of 1 \(^{\circ }\)F. For summer case studies, it was operated in the cooling mode with the set point of 76 \(^{\circ }\)F (\(\sim \)24 \(^{\circ }\)C). From the measured load profiles in Fig. 5b, c, it can be seen that the unit consumed 1.14 kW in its heating mode and 0.7 kW in its cooling mode. The space cooling/heating unit is considered the second highest priority load for the case study demonstration.

Fig. 5
figure 5

Measured load profiles of selected appliances

Full size image

Clothes Dryer

As a clothes dryer is unavailable in the YTU smart house environment, it was represented by a hair dryer to conduct our case studies. The hair dryer has a similar load profile (Fig. 5d) as a clothes dryer, but has lower power consumption. Hence, a scale factor of 2.0 was used to scale-up the consumption of the hair dryer to represent the consumption of a clothes dryer. The unit is set with a load priority just below the space cooling/heating unit.

Electric Vehicle

Due to the limited availability of EV for our experiments, a one-time measurement was conducted to determine the power consumption of an EV at the YTU smart house. The EV was charged from 45 to 85 % state-of-charge and it had an almost constant consumption throughout the experiment. The recorded EV consumption profile (Fig. 5e) was used for case studies instead of its real-time operation. The EV is considered the lowest priority load in the house.

Deferrable, Non-Interruptible Loads

These loads, for example a washing machine, are not interrupted during their operation, but will be deferred if a homeowner starts their operation during a DR event. Figure 5f shows the measured power consumption profile of a washing machine.

Table 1 summarizes the power-intensive load representations, their power consumption (kW), scale factors, and their priority and preference settings used during our case study demonstration.

Table 1 Load representations, scale factors, priority and preference settings
Full size table

Discussions of Case Studies

This section presents the description of case studies, basis for temperature adjustments in the smart house, results and discussions, as well as lessons learned from the field experiment.

Case Study Description

To observe the impact of the proposed BEM algorithm in a real-world smart house environment, four different case studies were conducted:

  1. a)

    Summer season with no DR event;

  2. b)

    Summer season with a DR event from 18:00–21:00;

  3. c)

    Winter season with no DR event; and

  4. d)

    Winter season with a DR event from 18:00–21:00.

For all these cases, the BEM program was run for 4 h to observe the impact of DR on total household loads during the 3 h DR event and the impact of load restrike for one hour after the DR event ends.

Basis for Temperature Adjustments in the Smart House

As the smart house is built inside the YTU Electrical Engineering building and all experiments (including both winter and summer case studies) were conducted in winter, the temperature profile outside the smart house had to be manipulated to represent typical temperature profiles for winter/summer cases of a real house.

For winter cases, building zone heaters were turned OFF, and windows were left open so that the environment outside the smart house (but inside the building) represents ambient conditions during the winter in Turkey.

For summer cases, building zone heaters were kept ON, keeping the building temperature at around 24 \(^{\circ }\)C (\(\sim \)76 \(^{\circ }\)F), and an additional space heating unit was used outside the smart house to increase the ambient temperature, representing a hot summer day in Turkey. The additional space heating was kept constantly ON during the whole duration of the summer case.

Results and Discussions

Results of the four different case studies are discussed as follows:

Case 1: Winter Case—No DR Event

This case was run in the afternoon on Jan 11, 2013. This is the base case for winter season without any DR event in effect. Figure 6a shows the power consumption of different appliances. Temperature profiles for this case are also shown. Critical loads include uninterruptible loads, such as lighting, TV, refrigerator, PC, etc. Deferrable/uninterruptible loads include a washing machine and a dishwasher. As there is no DR event, all appliances are turned ON and OFF based only on their preset comfort settings as specified earlier. The space cooling/heating unit functioned in the heating mode to maintain the room temperature within \(\pm 1{\,}^{\circ }\hbox {F}\) around the set point of \(74{\,}^{\circ }\hbox {F}\). As can be seen from the power consumption profile, the operation cycle of the space cooling/heating unit is different between 18:00–20:00 and 20:00–22:00. This is attributable to the fact that there were more people present in the smart house between 18:00–20:00. This caused the duration of both the heating and cooling functions to be longer than those during 20:00–22:00. The other loads were operated according to schedule derived from the Turkish survey. The peak consumption of almost 10.4 kW occurred from 20:16 to 20:21 when all the appliances were ON simultaneously. The critical load profile is also shown at the bottom-most subplot of Fig. 6a, together with the total household power consumption.

Fig. 6
figure 6

Demand response demonstration results: a winter case without DR event; and b winter case with a DR event between 18:00 and 21:00

Full size image

Case 2: Winter Case—with DR Event

This case was run in the evening on Jan 11, 2013. As can be seen in Fig. 6b—the bottom-most subplot, a demand limit of 6.7  kW was imposed between 18:00 and 21:00. During the DR event, the BEM algorithm continuously tried to maintain the total consumption below the demand limit. In order to do so, it shed lower priority loads if the total consumption exceeded the demand limit. For example, from 18:15 to 18:45, the EV was turned OFF a number of times to allow critical loads to run. It was also turned OFF from 20:16 to 21:00 in order to keep the clothes dryer ON, which has higher priority than the EV. In short, the BEM algorithm ensured that the demand limit was not surpassed at any time during the DR event. The deferrable loads: washing machine and dishwasher were deferred until after 21:00 when the DR event was over. Due to load curtailments and deferrals during the DR event, load restrike was observed for almost 15 min after the DR event ended, where peak consumption reached the value of almost 10.4 kW. A comparison between Fig. 6a, b clearly demonstrates the efficacy of the BEM algorithm to control total household consumption during a DR event.

Case 3: Summer Case—No DR Event

The base case for summer season is the case without any DR event. See Fig. 7a. This case was run in the afternoon on Jan 15, 2013. The space cooling/heating unit operated in the cooling mode, with a set point temperature of 76 \(^{\circ }\)F. As mentioned earlier, an additional space heater was turned ON to increase the temperature inside the smart house, representing summer season. Usage schedules of appliances were modified according to the result of the survey conducted. When comparing Figs. 6 and 7, it can be seen that the water heater was operated for shorter periods in summer cases than those in winter cases. Without a DR event, the BEM algorithm operated appliances inside the smart house to maintain preset customer comfort level. The total household consumption reached a peak value of 10.5 kW between 20:16 to 20:20.

Fig. 7
figure 7

Demand response demonstration results: a summer case without DR event; and b summer case with a DR event between 18:00 and 21:00

Full size image

Case 4: Summer Case—with DR Event

A demand limit of 6.7 kW was applied for this case for 3 h from 18:00 to 21:00, as shown in Fig. 7b. The case was run in the late evening on Jan 15, 2013. To keep the total consumption below demand limit, the BEM algorithm turned OFF and ON the EV a number of times from 18:00 to 18:45 to allow critical loads to operate. The EV was also turned OFF during the clothes dryer operation from 20:15 to 21:00. An irregularity in the operation cycle of the space cooling/heating unit was observed around 19:00. This is because the door of the smart house was open during that time, causing the additional space heater (used for representing summer case) to take longer than usual to warm up the room. Overall, the demonstration shows that the BEM algorithm keeps the total household consumption below the demand limit of 6.7 kW between 18:00 and 21:00. The washing machine and the dishwasher were deferred until the end of DR event. This resulted in 15 min load restrike after the DR event ended at 21:00, with a peak consumption of about 10.2 kW.

Summary of Results

To summarize the results from the four cases discussed above, the BEM algorithm was able to successfully control the household consumption below demand limit while maintaining customer priority and comfort settings, for both winter and summer cases. Although, winter and summer cases do not offer significant differences in terms of implementation results, both are presented here for sake of completeness of the study and proof of year-round effectiveness. Another point to note from the results is: in both cases, the rebound peak after DR event was almost equal to the original peak without DR. This shows that the imposed demand limit (i.e., 6.7 kW) is the marginal value for this specific smart house and a lower value of demand limit would have resulted in a higher restrike peak than original peak. This marginal value is important to consider for a utility before choosing a demand limit for a particular household.

Lessons Learned from Field Implementation

From the field implementation of BEM in a smart house environment, the following issues and associated mitigation approaches are worth mentioning: issues of different data collection rates of 4-noks\(\textregistered \) and handling of communication failures and data errors.

Data Collection of 4-noks\(\textregistered \)

The 4-noks\(\textregistered \) smart plugs used in the smart house communicate with the centralized PC in a request-response type protocol. That is, these smart plugs provide sampled data in response to a request from the PC. If the communication channel was busy for any reason, a 10 s delay will be imposed before a new request is issued. Due to this reason, the number and timing of data collected by a particular smart plug within a particular minute varied highly from data within another minute and also from data collected by other smart plugs. As we use data in one-minute intervals for our analysis, this issue is resolved by averaging all data collected by a smart plug within a 60 s time window, and using the average as the representative data for that minute. There is at least one data collected during each minute by each smart plug, therefore the solution is deemed sufficient to resolve the data collection rate variation issue.

Handling of Communication Failures and Data Errors

As can be expected, communication failures and data errors with smart plugs existed during the case studies. The failure rates for smart plugs connected to loads ranged from a minimum of 0 % to maximum 2.11 %. The experiment shows that given the smart plug failures, our revised algorithm is able to make correct decisions based on the sampled data. This proves the robustness of the algorithm and its suitability for application in regular households that may have variety of appliances to monitor/control.

Conclusion

This paper presents the validation of the improved Building Energy Management (BEM) algorithm in a smart house environment. As the smart house environment used in this study is in Istanbul, Turkey, load profiles of typical Turkish customers have been developed from a conducted survey and have been used in the case study demonstrations. Load priority and preference settings are also derived from the outcome of the survey. Also, the experimental set-up consists of using either real loads or representative loads with profiles similar to real loads and temperature adjustments to represent seasonal profiles. Hence, the study closely resembles real-life scenarios in a real smart building environment. The paper focuses on field implementation issues and discusses solution approaches. Results demonstrate how the BEM algorithm can be useful for residential automated load management with an incentive-based demand response program. The work is expected to serve as a guide for widespread use of automated demand response applications in smart buildings using a building energy management system.