A Realistic Dataset for the Smart Home Device Scheduling Problem for DCOPs

1 Introduction

Distributed Constraint Optimization Problems (DCOPs) [11, 15, 18]

have emerged as one of the prominent agent models to govern the agents’ autonomous behavior, where both algorithms and communication models are driven by the structure of the specific problem. Since the research field inception a wide variety of algorithms have been proposed to solve DCOPs and typically classified as being either

complete or incomplete, based on whether they can guarantee the optimal solution or they trade optimality for shorter execution times. In addition, each of these classes can be categorized into several groups, depending on the degree of locality exploited by the algorithms (e.g., partial centralization) [9, 10, 16], the way local information is updated (e.g., synchronous [10, 14, 15] or asynchronous [5, 8, 11]), and the type of exploration process adopted (e.g., search-based [9, 11, 19], inference-based [15, 5], or sampling-based [13, 12, 6]).

While techniques to solve DCOPs are abundant and have matured substantially since the field inception, the number of DCOP realistic applications and benchmarks used to assess the performance of DCOP algorithms is lagging behind. Typical DCOP algorithms are evaluated on artificial random problems, or simplified problems that are adapted to the often unrealistic assumptions made by DCOP algorithms (e.g., that each agent controls exactly one variable, and that all problem constraints are binary). To assess the performance of DCOP algorithms it is necessary to introduce realistic problem benchmark of deployable applications.

Motivated by these issues, we recently introduced the Smart Home Device Scheduling (SHDS) problem [7], which formalizes the problem of coordinating smart devices (e.g., smart thermostats, circulator heating, washing machines) schedules across multiple smart homes as a multi-agent system (MAS). The SHDS problem is suitable to be modeled as a DCOP due to the presence of both complex individual agents’ goals, describing homes’ energy price consumption, as well as a collective agents’ goal, capturing the energy peaks reduction.

In this document we introduce a set of realistic synthetic benchmarks for the SHDS problem for DCOPs. We report the details of the physical models adopted to simulate smart home sensors and actuators, as well as home environments, and describe how the actuator’s actions affects the environments of a home (e.g., home’s temperature, cleanliness, humidity). The datasets, models, and code adopted to generate the SHDS datasets are available at: https://github.com/persoon/SHDS_dataset.

1.0.1 Dcop

A Distributed Constraint Optimization Problem (DCOP) [11, 18] is described by a tuple $⟨ X, D, F, A, α ⟩$ , where: $X = {x_{1}, \dots, x_{n}}$ is a set of variables; $D = {D_{1}, \dots, D_{n}}$ is a set of finite domains (i.e., $x_{i} \in D_{i}$ ); $F = {f_{1}, \dots, f_{e}}$ is a set of utility functions (also called constraints), where $fi:×xj∈\scopefiDi→R+∪{−∞}$ and $\scopefi⊆X$ is the set of the variables (also called the scope) relevant to $f_{i}$ ; $A = {a_{1}, \dots, a_{p}}$ is a set of agents; and $α : X \to A$ is a function that maps each variable to one agent. $f_{i}$ specifies the utility of each combination of values assigned to the variables in $\scopefi$ . A partial assignment $σ$ is a value assignment to a set of variables $X_{σ} \subseteq X$ that is consistent with the variables’ domains. The utility $F(σ)=∑f∈F,\scopef⊆Xσf(σ)$ is the sum of the utilities of all the applicable utility functions in $σ$ . A solution is a partial assignment $σ$ for all the variables of the problem, i.e., with $Xσ\isX$ . We will denote with $\setfx$ a solution, while $\setfxi$ is the value of $x_{i}$ in $\setfx$ . The goal is to find an optimal solution $\setfx∗=\argmax\setfxF(\setfx)$ .

2 Scheduling Device in Smart Homes

A Smart Home Device Scheduling (SHDS) problem is defined by the tuple $⟨\setfH,Z,L,\setfPH,\setfPZ,H,θ⟩$ , where: $\setfH={h1,h2,…}$ is a neighborhood of smart homes, capable of communicating with one another; $Z=∪hi∈\setfH\setfZi$ is a set of smart devices, where $\setfZi$ is the set of devices in the smart home $h_{i}$ (e.g., vacuum cleaning robot, smart thermostat). $L=∪hi∈\setfH\setfLi$ is a set of locations, where $\setfLi$ is the set of locations in the smart home $h_{i}$ (e.g., living room, kitchen); $\setfPH$ is the set of state properties of the smart homes (e.g., cleanliness, temperature); $\setfPZ$ is the set of devices state properties (e.g., battery charge for a vacuum robot); $H$ is the planning horizon of the problem. We denote with $\setfT={1,…,H}$ the set of time points; $θ:\setfT→R+$ represents the real-time pricing schema adopted by the energy utility company, which expresses the cost per kWh of energy consumed by consumers. Finally, we use $Ω_{p}$ to denote the set of all possible states for state property $p∈\setfPH∪\setfPZ$ (e.g., all the different levels of cleanliness for the cleanliness property). Figure 1(right) shows an illustration of a neighborhood of smart homes with each home controlling a set of smart devices.

2.1 Smart Devices

For each home $hi∈\setfH$ , the set of smart devices $\setfZi$ is partitioned into a set of actuators $\setfAi$ and a set of sensors $\setfSi$ . Actuators can affect the states of the home (e.g., heaters and ovens can affect the temperature in the home) and possibly their own states (e.g., vacuum cleaning robots drain their battery power when running). On the other hand, sensors monitor the states of the home. Each device $z∈\setfZi$ of a home $h_{i}$ is defined by a tuple $⟨ ℓ_{z}, A_{z}, γ_{z}^{H}, γ_{z}^{Z} ⟩$ , where $ℓz∈\setfLi$ denotes the relevant location in the home that it can act or sense, $A_{z}$ is the set of actions that it can perform, $γHz:Az→2\setfPH$ maps the actions of the device to the relevant state properties of the home, and $γZz:Az→2\setfPZ$ maps the actions of the device to its relevant state properties. We will use the following running example throughout this paper.

Example 1

Consider a vacuum cleaning robot $z_{v}$ with location $ℓzv=\statefliving_room$ . The set of possible actions is $Azv={\statefrun,\statefcharge,\statefstop}$ and the mappings are:

	$\footnotesizeγHzv$	$:\statefrun→{cleanliness};\statefcharge→∅;\statefstop→∅$
	$γ_{z_{v}}^{Z}$	$:\statefrun→{battery\_charge};\statefcharge→{battery\_charge};\statefstop→∅$

where $\emptyset$ represents a null state property.

Figure 1: Illustration of a Neighborhood of Smart Homes

2.2 Device Schedules

To control the energy profile of a smart home we need to describe the behavior of the smart devices acting in the smart home during time. We formalize this concept with the notion of device schedules.

We use $ξ_{z}^{t} \in A_{z}$ to denote the action of device $z$ at time step $t$ , and $ξtX={ξtz\stz∈X}$ to denote the set of actions of the devices in $X \subseteq Z$ at time step $t$ .

Definition 1 (Schedule)

A schedule $ξ_{X}^{[t_{a} \to t_{b}]} = ⟨ ξ_{X}^{t_{a}}, \dots, ξ_{X}^{t_{b}} ⟩$ is a sequence of actions for the devices in $X \subseteq Z$ within the time interval from $t_{a}$ to $t_{b}$ .

Consider the illustration of Figure 1(left). The top row of Figure 1(left) shows a possible schedule $⟨ R, R, C, C, R, R, C, R ⟩$ for a vacuum cleaning robot starting at time 1400 hrs, where each time step is 30 minutes. The robot’s actions at each time step are shown in the colored boxes with letters in them: red with ‘S’ for stop, green with ‘R’ for run, and blue with ‘C’ for charge.

At a high-level, the goal of the SHDS problem is to find a schedule for each of the devices in every smart home that achieve some user-defined objectives (e.g., the home is at a particular temperature within a time window, the home is at a certain cleanliness level by some deadline) that may be personalized for each home. We refer to these objectives as scheduling rules.

2.3 Scheduling Rules

We define two types of scheduling rules: Active scheduling rules (ASRs) that define user-defined objectives on a desired state of the home (e.g., the living room is cleaned by 1800 hrs), and Passive scheduling rules (PSRs) that define implicit constraints on devices that must hold at all times (e.g., the battery charge on a vacuum cleaning robot is always between 0% and 100%). We provide a formal description for the grammar of scheduling rules in Section 3.4.

Example 2

The scheduling rule (1) describes an ASR defining a goal state where the living room floor is at least 75% clean (i.e., at least 75% of the floor is cleaned by a vacuum cleaning robot) by 1800 hrs:

	living_room cleanliness $\geq$ 75 before 1800		(1)
	$z_{v}$ battery_charge $\geq$ 0 always		(2)
	$z_{v}$ battery_charge $\leq$ 100 always		(3)

and scheduling rules (2) and (3) describe PSRs stating that the battery charge of the vacuum robot $z_{v}$ needs to be between 0 and 100 % of its full charge at all the times:

We denote with $R_{p}^{[t_{a} \to t_{b}]}$ a scheduling rule over a state property $p∈\setfPH∪\setfPZ$ , and time interval $[t_{a}, t_{b}]$ . Each scheduling rule indicates a goal state at a location or on a device $ℓRp∈\setfLi∪\setfZi$ of a particular state property $p$ that must hold over the time interval $[ta,tb]⊆\setfT$ . The scheduling rule goal state is either a desired state of a home, if it is an ASR (e.g., the cleanliness level of the room floor) or a required state of a device or a home, if it is a PSR (e.g., the battery charge of the vacuum cleaning robot).

Each rule is associated with a set of actuators $Φp⊆\setfAi$ that can be used to reach the goal state. For instance, in our Example (2), $Φ_{p}$ correspond to the vacuum cleaning robot $z_{v}$ , which can operate on the living room floor. Additionally, a rule is associated with a sensor $sp∈\setfSi$ capable of sensing the state property $p$ . Finally, in a PSRs the device can also sense its own internal states.

The ASR of Equation (1) is illustrated in Figure 1(left) by dotted red lines on the graph. The PSRs are not shown as they must hold for all time steps.

2.4 Feasibility of Schedules

To ensure that a goal state can be achieved across the desired time window the system uses a predictive model of the various state properties. This predictive model captures the evolution of a state property over time and how such state property is affected by a given joint action of the relevant actuators. We describe the details of the physical predictive models used to generate our benchmark set in Section 3.3.

Definition 2 (Predictive Model)

A predictive model $Γ_{p}$ for a state property $p$ (of either the home or a device) is a function $Γ_{p} : Ω_{p} \times \times_{z \in Φ_{p}} A_{z} \cup {⊥} \to Ω_{p} \cup {⊥}$ , where $⊥$ denotes an infeasible state and $⊥ + (\cdot) = ⊥$ .

In other words, the model describes the transition of state property $p$ from state $ω_{p} \in Ω_{p}$ at time step $t$ to time step $t + 1$ when it is affected by a set of actuators $Φ_{p}$ running joint actions $ξ_{Φ_{p}}^{t}$ :

Γ_{p}^{t + 1} (ω_{p}, ξ_{Φ_{p}}^{t}) = ω_{p} + Δ_{p} (ω_{p}, ξ_{Φ_{p}}^{t})

(4)

where $Δ_{p} (ω_{p}, ξ_{Φ_{p}}^{t})$ is a function describing the effect of the actuators’ joint action $ξ_{Φ_{p}}^{t}$ on state property $p$ . We assume here, w.l.o.g. that the state of properties are numeric—when this is not the case, a mapping to the possible states to a numeric representation can be easily defined.

Notice that a recursive invocation of a predictive model allows us to predict the trajectory of a state property $p$ for future time steps, given a schedule of actions of the relevant actuators $Φ_{p}$ . Let us formally define this concept.

Definition 3 (Predicted State Trajectory)

Given a state property $p$ , its current state $ω_{p}$ at time step $t_{a}$ , and a schedule $ξ_{Φ_{p}}^{[t_{a} \to t_{b}]}$ of relevant actuators $Φ_{p}$ , the predicted state trajectory $π_{p} (ω_{p}, ξ_{Φ_{p}}^{[t_{a} \to t_{b}]})$ of that state property is defined as:

π_{p} (ω_{p}, ξ_{Φ_{p}}^{[t_{a} \to t_{b}]})

= Γ_{p}^{t_{b}} (Γ_{p}^{t_{b - 1}} (\dots (Γ_{p}^{t_{a}} (ω_{p}, ξ_{Φ_{p}}^{t_{a}}), \dots), ξ_{Φ_{p}}^{t_{b - 1}}), ξ_{Φ_{p}}^{t_{b}})

(5)

Consider the device scheduling example in Figure 1(left). The predicted state trajectories of the battery_charge and cleanliness state properties are shown in the second and third rows of Figure 1(left). These trajectories are predicted given that the vacuum cleaning robot will take on the schedule shown in the first row of the figure. The predicted trajectories of these state properties are also illustrated in the graph, where the dark grey line shows the states for the robot’s battery charge and the black line shows the states for the cleanliness of the room.

Notice that to verify if a schedule satisfies a scheduling rule it is sufficient to check that the predicted state trajectories are within the set of feasible state trajectories of that rule. Additionally, notice that each active and passive scheduling rule defines a set of feasible state trajectories. For example, the active scheduling rule of Equation (1) allows all possible state trajectories as long as the state at time step 1800 is no smaller than 75. We use $R_{p} [t] \subseteq Ω_{p}$ to denote the set of states that are feasible according to rule $R_{p}$ of state property $p$ at time step $t$ . More formally, a schedule $ξ_{Φ_{p}}^{[t_{a} \to t_{b}]}$ satisfies a scheduling rule $R_{p}^{[t_{a} \to t_{b}]}$ (written as $ξ_{Φ_{p}}^{[t_{a} \to t_{b}]} ⊨ R_{p}^{[t_{a} \to t_{b}]}$ ) iff:

\forall t \in [t_{a}, t_{b}] : π_{p} (ω_{p}^{t_{a}}, ξ_{Φ_{p}}^{[t_{a} \to t]}) \in R_{p} [t]

(6)

where $ω_{p}^{t_{a}}$ is the state of state property $p$ at time step $t_{a}$ .

Definition 4 (Feasible Schedule)

A schedule is feasible if it satisfies all the passive and active scheduling rules of each home in the SHDS problem.

In the example of Figure 1, the evaluated schedule is a feasible schedule since the trajectories of both the battery_charge and cleanliness states satisfy both the active scheduling rule (1) and the passive scheduling rules (2) and (3).

2.5 Optimization Objective

In addition to finding feasible schedules, the goal in the SHDS problem is to optimize for the aggregated total cost of energy consumed.

Each action $a \in A_{z}$ of device $z∈\setfZi$ in home $hi∈\setfH$ has an associated energy consumption $ρ_{z} : A_{z} \to R^{+}$ , expressed in kWh. The aggregated energy $Eti(ξ[0→H]\setfZi)$ across all devices consumed by $h_{i}$ at time step $t$ under trajectory $ξ[0→H]\setfZi$ is:

Eti(ξ[0→H]\setfZi)=∑z∈\setfZiρz(ξtz)

(7)

where $ξ_{z}^{t}$ is the action of device $z$ at time $t$ in the schedule $ξ[0→H]\setfZi$ . The cost $ci(ξ[0→H]\setfZi)$ associated to schedule $ξ[0→H]\setfZi$ in home $h_{i}$ is:

ci(ξ[0→H]\setfZi)=∑t∈\setfT(ℓti+Eti(ξ[0→H]\setfZi))⋅θ(t)

(8)

where $ℓ_{i}^{t}$ is the home background load produced at time $t$ , which includes all non-schedulable devices (e.g., TV, refrigerator), and sensor devices, which are always active, and $θ (t)$ is the real-time price of energy per kWh at time $t$ .

The objective of an SHDS problem is that of minimizing the following weighted bi-objective function:

		$minξ[0→H]\setfZiαc⋅Csum+αe⋅Epeak$		(9)
	subject to:	$∀hi∈\setfH,R[ta→tb]p∈\setfRi:ξ[ta→tb]Φp⊨R[ta→tb]p$		(10)

where $α_{c}, α_{e} \in R$ are weights, $Csum=∑hi∈\setfHci(ξ[0→H]\setfZi)$ is the aggregated monetary cost across all homes $h_{i}$ ; and $Epeak=∑t∈\setfT ∑\setfHj∈H∑hi∈\setfHj(Eti(ξ[0→H]\setfZi))2$ is a quadratic penalty function on the aggregated energy consumption across all homes $h_{i}$ . Since the SHDS problem is designed for distributed multi-agent systems, in a cooperative approach optimizing $E^{peak}$ may require each home to share its energy profile with each other home. To take into account data privacy concerns and possible high network loads, we decompose the set of homes $\setfH$ into neighboring subsets of homes $H$ , so that $E^{peak}$ can be optimized independently within each subset. These coalitions can be exploited by a distributed algorithm to (1) parallelize computations between multiple groups and (2) avoid data exposure over long distances or sensitive areas. Finally, constraint (10) defines the valid trajectories for each scheduling rule $r∈\setfRi$ , where $\setfRi$ is the set of all scheduling rules of home $h_{i}$ .

2.6 DCOP Mapping

One can map the SHDS problem to a DCOP as follows:

Agents: Each agent $a_{i} \in A$ in the DCOP is mapped to a home $hi∈\setfH$ .

Variables and Domains: Each agent $a_{i}$ controls the following set of variables:

For each actuator $z∈\setfAi$ and each time step $t∈\setfT$ , a variable $x_{i, z}^{t}$ whose domain is the set of actions in $A_{z}$ . The sensors in $\setfSi$ are considered to be always active, and thus not directly controlled by the agent.

An auxiliary interface variable ${^x}_{j}^{t}$ whose domain is the set ${0,…,∑z∈\setfZiρ(\argmaxa∈Azρz(a))}$ , which represents the aggregated energy consumed by all the devices in the home at each time step $t$ .

Constraints: There are three types of constraints:

Local soft constraints (i.e., constraints that involve only variables controlled by the agent) whose costs correspond to the weighted summation of monetary costs, as defined in Equation (8).

Local hard constraints that enforce Constraint (10). Feasible schedules incur a cost of 0 while infeasible schedules incur a cost of $\infty$ .

Global soft constraints (i.e., constraints that involve variables controlled by different agents) whose costs correspond to the peak energy consumption, as defined in the second term in Equation (9).

3 Model Parameters and Realistic Data Set Generation

This section describes the parameters and models adopted in our SHDS datasets generation. We first describe the house structural parameters, which are used in turn to calculate the house predictive models. Next, we report a detailed list of the smart devices adopted in our datasets, discussing their power consumptions and effects on the house environments. We then describe the predictive models adopted to capture changes in the house’s environments and devices’ states. Finally, we report the BNF for the scheduling rules introduced in Section 2.3, and the pricing scheme adopted in our experiments.

3.1 House Structural Parameters

Figure 2: Floor plans for a small (left), medium (center), and large (right) house.

We consider three house sizes (small, medium, and large). The floor plans for three house structures are shown in Figure 2. Our house structural model simplifies the floor plans shown in Figure 2 by ignoring internal walls. This abstraction is sufficient to capture the richness of the predictive models introduced in Section 2.4. Table 1 reports the parameters of the houses adopted in our SHDS dataset. The house sizes are expressed in meters ( $L \times W$ ). The walls height is assumed to be $2.4 m$ and the window area denotes the area of the walls covered by windows. The overall heat transfer coefficient (also referred to as U-value) describes how well a building element conducts heat. It is defined as the rate of heat transfer (in watts) through one unit area ( $m^{2}$ ) of a structure divided by the difference in temperature across the structure [17].

Fix Reference here

The walls material is considered to be a $150 m m$ poured concrete ( $1280 k g / m^{3}$ ) with a Heat-Transfer Coefficient ( $U_{walls}$ ) of $3.9 \frac{W}{m^{2} \cdot^{\circ} C}$ . We consider vertical double glazed windows, with distance between glasses $30 - 60 m m$ whose Heat-Transfer Coefficient ( $U_{windows}$ ) is $2.8 \frac{W}{m^{2} \cdot^{\circ} C}$ . Additionally, we consider a $2.54 c m$ wood roof with $2.54 c m$ insulation, with Heat-Transfer Coefficient ( $U_{roof}$ ) of $1.1 \frac{W}{m^{2} \cdot^{\circ} C}$ . Finally, we consider a $5.08 c m$ wood door, with Heat-Transfer Coefficient of $2.6 \frac{W}{m^{2} \cdot^{\circ} C}$ . These are commonly adopted materials in the US house construction industry [17]. We assume a background load consumption which account of a medium-size refrigerator ( $120 W$ ), a wireless router ( $6 W$ ), and a set of light bulbs (collectively $40 W$ ) [17]. The heat gain from the background house appliances is computed according to [17](Table 9.8). We consider the heat gain from people within the house, and computed as in [17](Table 9.7), assuming a metabolic rate as light office work.

Structural Parameters	small	medium	large	Structural Parameters	small	medium	large
house size ( $m$ )	$6 \times 8$	$8 \times 12$	$12 \times 15$	$U_{roof}$ $(W / m^{2} C)$	1.1	1.1	1.1
walls area ( $m^{2}$ )	67.2	96	129.6	lights energy density ( $W / m^{3}$ )	9.69	9.69	9.69
window area ( $m^{2}$ )	7.2	10	16	background load (kW)	0.166	0.166	0.166
$U_{walls}$ $(W / m^{2} C)$	3.9	3.9	3.9	background heat gain (W)	50	50	50
$U_{windows}$ $(W / m^{2} C)$	2.8	2.8	2.8	people heat gain (Btu/h)	400	400	400

Table 1: House structural parameters.

3.2 Smart Devices

In this section we report the complete list of smart devices (sensors and actuators) adopted by the smart homes in our SHDS datasets.

Sensors Table 2 reports the sensors adopted in our SHDS problem. For each sensor, we report an identifier (ID), the state property (see Section 2.1) it senses, and its location in the house. All sensors are considered to be constantly active, sensing a single state property at a location (e.g., an air temperature sensor is located in a house room, a charge sensor is located on a device).

ID	State property	Location	ID	State property	Location
01	air temperature	house room	08	dish cleanliness	appliance
02	floor cleanliness (dust)	house room	09	air humidity	house room
03	temperature	appliance	10	luminosity	house room
04	battery charge	appliance	11	occupancy	house room
05	bake	appliance	12	movement	house room
06	laundry wash	appliance	13	smoke detector	house room
07	laundry dry	appliance

Table 2: List of sensors.

Actuators Table 3 reports the list of the actuators. It tabulates the type of actuator and its model, its possible actions, the power consumption (in kWh), the state properties affected by each of its action, and the effects ( $Δ$ ) on the associated predictive models in the small, medium, and large house sizes. The latter represent the incremental quantity which affects the physical system, given the action of the actuator, as defined in Equation 4. We detail the calculation of the house and devices physical models below.

Actuator	Model	Actions	Consumption (kWh)	State properties (ID)	Effects Small( $Δ$ )	Effects Medium( $Δ$ )	Effects Large( $Δ$ )
Heater	Bryant 697CN030B	off	$0$	${01}$	$- \frac{{˙ L}_{h}}{148.48 \cdot T_{A}}$	$- \frac{{˙ L}_{h}}{296.86 \cdot T_{A}}$	$- \frac{{˙ L}_{h}}{593.75 \cdot T_{A}}$
		fan	$0.5$	${01}$	$- \frac{{˙ L}_{h}}{148.48 \cdot T_{A}}$	$- \frac{{˙ L}_{h}}{296.86 \cdot T_{A}}$	$- \frac{{˙ L}_{h}}{593.75 \cdot T_{A}}$
		heat	$0.5$	${01}$	$\frac{{˙ L}_{h}}{148.48 \cdot \| T_{Z} - T_{A} \|}$	$\frac{{˙ L}_{h}}{296.86 \cdot \| T_{Z} - T_{A} \|}$	$\frac{{˙ L}_{h}}{593.75 \cdot \| T_{Z} - T_{A} \|}$
Cooler	LG LW1212ER	off	$0$	${01}$	$\frac{{˙ L}_{h}}{148.48 \cdot T_{A}}$	$\frac{{˙ L}_{h}}{296.86 \cdot T_{A}}$	$\frac{{˙ L}_{h}}{593.75 \cdot T_{A}}$
		fan	$0.5$	${01}$	$\frac{{˙ L}_{h}}{148.48 \cdot T_{A}}$	$\frac{{˙ L}_{h}}{296.86 \cdot T_{A}}$	$\frac{{˙ L}_{h}}{593.75 \cdot T_{A}}$
		cool	$2.3$	${01}$	$\frac{{˙ L}_{h}}{148.48 \cdot \| T_{A} - T_{Z} \|}$	$\frac{{˙ L}_{h}}{296.86 \cdot \| T_{A} - T_{Z} \|}$	$\frac{{˙ L}_{h}}{593.75 \cdot \| T_{A} - T_{Z} \|}$
Waterheater	E52-50R-045DV	off	$0$	${03}$	${0}$	${0}$	${0}$
Waterheater	E52-50R-045DV	on	$4.6$	${03}$	${{27.9}^{\circ} C}$	${{25.2}^{\circ} C}$	${{19.2}^{\circ} C}$
Vacuum Bot	iRobot Roomba 880	off	$0$	${02, 04}$	${0.0 %, 0.0 %}$	${0.0 %, 0.0 %}$	${0.0 %, 0.0 %}$
		vacuum	$0$	${02, 04}$	${0.676 %, - 0.21 %}$	${0.338 %, - 0.21 %}$	${0.168 %, - 0.21 %}$
		charge	$0.26$	${04}$	${0.33 %}$	${0.33 %}$	${0.33 %}$
Electric Vehicle	Tesla Model S	off	$0$	${04}$	${0}$	${0}$	${0}$
Electric Vehicle	Tesla Model S	charge	$17.28$	${04}$	${0.167 %}$	${0.167 %}$	${0.167 %}$
Clothes Washer	GE WSM2420D3WW	off	$0$	${06}$	${0}$	${0}$	${0}$
Clothes Washer	GE WSM2420D3WW	wash (Regular)	$0.43$	${06}$	${1}$	${1}$	${1}$
		spin (Regular)	$0.45$	${06}$	${1}$	${1}$	${1}$
		rinse (Regular)	$0.15$	${06}$	${1}$	${1}$	${1}$
		wash (Perm-Press)	$0.39$	${06}$	${1}$	${1}$	${1}$
		spin (Perm-Press)	$0.43$	${06}$	${1}$	${1}$	${1}$
		rinse (Perm-Press)	$0.23$	${06}$	${1}$	${1}$	${1}$
		wash (Delicates)	$0.39$	${06}$	${1}$	${1}$	${1}$
		spin (Delicates)	$0.33$	${06}$	${1}$	${1}$	${1}$
		rinse (Delicates)	$0.01$	${06}$	${1}$	${1}$	${1}$
Clothes Dryer	GE WSM2420D3WW	off	$0$	${07}$	${0}$	${0}$	${0}$
Clothes Dryer	GE WSM2420D3WW	on (Regular)	$5.76$	${07}$	${1}$	${1}$	${1}$
		on (Perm-Press)	$5.25$	${07}$	${1}$	${1}$	${1}$
		on (Timed)	$5.95$	${07}$	${1}$	${1}$	${1}$
Oven	Kenmore 790.91312013	off	$0$	${05}$	${0}$	${0}$	${0}$
		bake	$8.46$	${05, 01}$	${1, {0.017}^{\circ} C}$	${1, {0.009}^{\circ} C}$	${1, {0.004}^{\circ} C}$
		broil	$10.56$	${05, 01}$	${1.25, {0.02}^{\circ} C}$	${1.25, {0.01}^{\circ} C}$	${1.25, {0.005}^{\circ} C}$
Dishwasher	Kenmore 665.13242K900	off	$0$	${08}$	${0}$	${0}$	${0}$
Dishwasher	Kenmore 665.13242K900	wash	$1.12$	${08}$	${1}$	${1}$	${1}$
		rinse	$1.14$	${08}$	${1}$	${1}$	${1}$
		dry	$0.63$	${08}$	${1}$	${1}$	${1}$

Table 3: List of actuators.

switch columns state property with consumption

3.3 Physical models

In this section we describe the physical models used to compute the effects values $Δ$ of the actuators’ actions on a predictive model (see Table 3). These values, in turn, are adopted within the SHDS predictive models as described in Equation (4).

Battery (Dis)charge Model The battery charge/discharge model we adopt for our battery-powered devices is as follows. For a given battery $b$ with capacity $Q_{b}$ (expressed in KWh), voltage $V_{b}$ , and electric charge $E_{b} = \frac{V_{b}}{Q_{b}}$ (expressed in ampere-hour (Ah)), and assuming a 100% charging/discharging efficiency, the battery charge time $b_{α}^{+}$ and discharge time $b_{α}^{-}$ are computed respectively as:

\begin{matrix} b_{α}^{+} = \frac{E_{b}}{C^{+}}; b_{α}^{-} = \frac{E_{b}}{C^{-}}, \end{matrix}

(11)

expressed in hours, where $C^{+}$ and $C^{-}$ are, respectively, the charging amperage and the in-use amperage. Following https://goo.gl/l5TGtz and https://goo.gl/NmO0fY we report the battery parameters for our Electric Vehicle and robotic vacuum cleaner in Table 4. The devices’ action effects $Δ$ for charging and discharging time are computed by dividing the total charging and discharging times by $|\setfT|$ .

	Tesla Model S			iRobot Roomba 880
	Slow Charge	Regular Charge	Super Charger
$V_{b}$	240	240	240	120
$E_{b}$	354 Ah	354 Ah	354 Ah	3 Ah
$C^{+}$	48 A	72 A	500 A	1.25 A
$C^{-}$	60 A	60 A	60 A	0.75 A
$b_{α}^{+}$	7 hr 22 min	5 hr	43 min	2 hr 24 min
$b_{α}^{-}$	6 hr	6 hr	6 hr	4 hr

Table 4: Electric vehicles [3] and robotic vacuum cleaner[1] batteries physical model.

Air Temperature Model The air temperature predictive model is computed following standard principle of heating and ventilation [17] and described as follows. Let $G$ be the ventilation conductance: $G = ˙ V \cdot ρ_{a} \cdot ¯ h,$ where $˙ V$ is the volume flow rate, set to $100$ , $ρ_{a}$ is the density of the air, set to 0.75, and $¯ h$ is the specific heat of the air, set to 0.24 following [17]. The house heat loss coefficient $h_{loss}$ is:

h_{loss} = U_{walls} \cdot A_{walls} + U_{roof} \cdot A_{roof} + U_{windows} \cdot A_{windows} + G

(12)

where $U_{walls}$ , $U_{roof}$ , and $U_{windows}$ are respectively, the heat transfer coefficients for the walls, roof, and windows of the house, and $A_{walls}$ , $A_{roof}$ , and $A_{windows}$ are respectively the the areas for walls, roof, and windows. Their values are provided in Table 1. Let $T_{A}$ and $T_{Z}$ be the current and a target temperatures; the heating load ${˙ L}_{h}$ is given by:

{˙ L}_{h} = h_{loss} | T_{Z} - T_{A} |

(13)

The heating load defines the quantity of heat per unit time (in BTU) that must be supplied in a building to reach the target temperature $T_{Z}$ , from the given temperature $T_{A}$ . Given the heating load ${˙ L}_{h}$ and the heater capacity $C$ of a heater/cooler, the time the device needs to run to reach the desired temperature is given by: $\frac{L_{h}}{C}$ .
Heating or cooling load is also effected by the outdoor and indoor temperature difference. Consider the example where $T_{A}$ = $12^{\circ} C$ and $T_{Z}$ = $22^{\circ} C$ , and the outdoor temperature changes from $T_{A}$ to $T_{N}$ = $8^{\circ} C$ . We can calculate the new load due to change in temperature by the following relationship given below:

{˙ L}_{n} = {˙ L}_{h} \cdot \frac{| T_{Z} - T_{N} |}{| T_{Z} - T_{A} |}

(14)

The above expression shows that an outdoor temperature drops of $4^{\circ} C$ , causes the heating load to increase by a factor of 1.4 (w.r.t. the previous heating load $T_{A}$ ). In our model we need to compute the change in temperature per time step ( $Δ$ ). This can be done using the heat loss relationship:

Δ = \frac{h_{loss}}{m \cdot c_{p}}

(15)

where $m$ is the mass of the air and $c_{p}$ is the specific heat of air. In our model, $m$ depends on volume flow rate of an air in the house, and $c_{p}$ = $1 K J / K g \cdot K$ .

Water Temperature Model The rise in the water temperature per unit of time ( $Δ$ value) is dependent on the difference in the water temperature flowing into the water heater and the amount of water flowing out of the water heater, as well as water usage We considered a gas-fired demand water heater(tankless). The water usage depends on household size and multiple user activities To calculate the water temperature, in our model, we used the highest potential peak water usage following [2, 4], and corresponding to 26.50 liters/min (small house), 29.34 liters/min (medium house), and 38.38 liters/min (large house). The rise in temperature is $39^{\circ} C$ for 18.93 liters/minute of water usage [2]. Thus the rise in temperature for our small, medium, and large house, are, respectively, ${27.9}^{\circ} C$ , ${25.2}^{\circ} C$ , and ${19.2}^{\circ} C$ .

Can you use liters rather than gallons?

Cleanliness Model Our floor cleanliness model is computed by using the equation: $T = \frac{A}{0.313}$ where, $A$ represents the area of the room (in m $^{2}$ ) and $T$ is the amount of time (in minutes) it takes the robotic vacuum cleaner to vacuum the entire room. Consumer reports found that it took 57 minutes for the Roomba to clean a 17.84 m $^{2}$ room [1] (which is approximately $0.313 m^{2}$ /min). In our experiment’s datasets we use three different areas. $A_{s m a l l} = 48$ , $A_{m e d i u m} = 96$ , and $A_{l a r g e} = 180$

. Thus the the estimated times to cover a 100% floor for the small, medium, and large houses are, repsectively:

T =

153.35, 306.71, and 575.08 minutes. The corresponding

Δ

value of Table 3 (which is a percentage) is computed as:

Δ = \frac{100 %}{T}

All other predictive models (e.g., laundry wash and dry, bake, dish cleanliness, etc.) simply capture the time needed for a device to achieve the required goals by checking that accumulated device effects achieves the desired property. This is discussed in the dataset generation, in Section 4.

3.4 Scheduling Rules

We report, as follows, the complete Backus-Naur Form (BNF) for the scheduling rules for a smart home $hi∈\setfH$ , introduced in Section 2.2

\footnotesize\anglesrules\defeq\anglessimplerule | \anglessimplerule∧\anglesrules\anglessimplerule\defeq\anglesactiverule | \anglespassiverule\anglesactiverule\defeq\angleslocation\anglesstateproperty\anglesrelation\anglesgoalstate\anglestime\anglespassiverule\defeq\angleslocation\anglesstateproperty\anglesrelation\anglesgoalstate\angleslocation\defeqℓ∈\setfLi\anglesstateproperty\defeqs∈\setfPH | s∈\setfPZ\anglesrelation\defeq ≤ | < | = | ≠ | > | ≥\anglesgoalstate\defeqsensor state | actuator state\anglestime\defeqat \anglesT | % before \anglesT | after \anglesT | within [\anglesT,\anglesT] | for \anglesT time units\anglesT\defeqt∈\setfT

In our dataset the device states are mapped to numeric values, i.e., $Ω_{p} = N$ , for all $p∈\setfPH∪\setfPZ$ .

3.5 Pricing Schema

For the evaluation of our SHDS datasets we adopted a pricing schema used by the Pacific Gas & Electric Co. for its customers in parts of California,¹¹1https://goo.gl/vOeNqj which accounts for 7 tiers ranging from $0.198 per kWh to $0.849 per kWh, reported in Table 5

time start	0:00	8:00	12:00	14:00	18:00	22:00
time end	7:59	11:59	13:59	17:59	21:59	23:59
price ($)	0.198	0.225	0.249	0.849	0.225	0.198

Table 5: Pacific Gas & Electric Co. pricing schema

4 SHDS Dataset

We now introduce a dataset for the SHDS problem for DCOPs. We generate synthetic microgrid instances sampling neighborhoods in three cities in the United States (Des Moines, IA; Boston, MA; and San Francisco, CA) and estimate the density of houses in each city. The average density (in houses per square kilometers) is 718 in Des Moines, 1357 in Boston, and 3766 in San Francisco. For each city, we created a 200m $\times$ 200m grid, where the distance between intersections is 20m, and randomly placed houses in this grid until the density is the same as the sampled density. We then divided the city into $k$ (= $| H |$ ) coalitions, where each home can communicate with all homes in its coalition. Finally, we ensure that there no two coalitions are disjoint. Tables 9, 10, and 11 report, respectively, the Des Moines, Boston, and San Francisco instances, where we vary (i) the number of agents ( $n$ )—up to 1883 for the largest instances—, (ii) the number of coalitions ( $k$ ), and (iii) the number of actuators within each home $m$ .

Each home device has an associated active scheduling rule that is randomly generated, and a number of passive rules that must always hold. The parameters to generate active and passive rules are reported, respectively, in Table 6 and Table 7. The time predicates for these rules are generated at random within the given horizon. Additionally, the relations $r$ and goals states $g_{i}$ are randomly generated sampling from the sets corresponding, respectively, to the columns $\anglesrelation$ and $\anglesgoalstate$ of Table 6.

We generate a total of $2351$ problem instances (available at: https://github.com/persoon/SHDS_dataset). We set $H = 12$ , and report in Table 8 a summary of the parameters’ settings for our smart homes physical models.

$\angleslocation$	$\anglesstateproperty$	$\anglesrelation$	$\anglesgoalstate$	$\anglestime$
Room	air temperature	$r \in {\leq, <, =, >, \geq}$	$g_{1} \in [14, 28]$	$\anglestime$
Room	floor cleanliness	$r \in {=, >, \geq}$	$g_{2} \in [0, 100]$	$\anglestime$
Electric Vehicle	charge	$r \in {=, >, \geq}$	$g_{3} \in [0, 100]$	$\anglestime$
Water heater	temperature	$r \in {\leq, <, =, >, \geq}$	$g_{4} \in [10, 45]$	$\anglestime$
Clothes Washer	laundry wash	$r \in {=}$	$g_{5} \in {45, 60}$	$\anglestime$
Clothes Drier	laundry dry	$r \in {=}$	$g_{6} \in {45, 60}$	$\anglestime$
Oven	bake	$r \in {=}$	$g_{7} \in {30, 40, 60, 120}$	$\anglestime$
Dishwasher	dishes cleanliness	$r \in {=}$	$g_{8} \in {45, 60}$	$\anglestime$

Table 6: Scheduling (active) rules

$\angleslocation$	$\anglesstateproperty$	$\anglesrelation$	$\anglesgoalstate$	$\angleslocation$	$\anglesstateproperty$	$\anglesrelation$	$\anglesgoalstate$
Room	air temperature	$\geq$	0	EV	charge	$\leq$	100
Room	air temperature	$\leq$	30	Water heater	temperature	$\geq$	10
Room	floor cleanliness	$\geq$	0	Water heater	temperature	$\leq$	42
Ooom	floor cleanliness	$\leq$	100	Oven	bake	$\leq$	$g_{7}$
Roomba	charge	$\geq$	0	Clothes Washer	laundry wash	$\leq$	$g_{6}$
Roomba	charge	$\leq$	100	Clothes Drier	laundry dry	$\leq$	$g_{7}$
EV	charge	$\geq$	0	Dishwasher	dishes cleanliness	$\leq$	$g_{8}$

Table 7: Scheduling (active) rules

Additionally, we provide upper bounds (in the obj column) for each for the instances (Tables 9, 10, and 11 report a subset of the SHDS dataset) by solving an uncoordinated DCOP, where each agent reports its best schedule found with a local Constraint Programming solver²²2We adopt the JaCoP solver (http://www.jacop.eu/) as subroutine, within a 10 seconds timeout.

Physical model	Parameter	Value (small house)	Value (medium house)	Value (large house)
Air Temperature	$˙ V$	100	200	400
	$m$	148.48	296.86	593.75
	$c_{p}$	1.0	1.0	1.0
	$ρ_{a}$	0.75	0.75	0.75
	$¯ h$	0.24	0.24	0.24
	$h_l o s s$	352.24	544	764.75
	$T_{Z}$	22	22	22
	$T_{A}$	10	10	10
	${˙ L}_{n}$	4226.88	6528	9177
Floor Cleanliness	$A$	48 m $^{2}$	96 m $^{2}$	180 m $^{2}$
	$T$	153.35 min	306.71 min	575.08 min
	$Δ$	0.652%	0.326%	0.174%
Water Temperature	household size	2	3	4
	liters/min usage	26.50	29.34	38.38
	$Δ$	27.9 $^{\circ} C$	25.2 $^{\circ} C$	19.2 $^{\circ} C$

Table 8: Physical models: Values and assumptions

What are the $Δ T$ in Table 7?

instance	$n$	$k$	$m$	sim. time (s)	obj	avg price ($)	avg power (kWh)	largest peak (kW)
dm_7_1_3	7	1	3	28.00	458.27	1.11	5.55	8.75
dm_7_1_4	7	1	4	36.00	1385.70	1.83	9.18	16.85
dm_7_1_5	7	1	5	26.00	1936.87	2.36	11.30	20.21
dm_7_1_6	7	1	6	51.00	5122.10	4.06	19.78	29.55
dm_7_4_6	7	4	6	69.00	52335.95	4.08	19.57	32.02
dm_21_1_3	21	1	3	25.00	1280.79	1.06	5.28	26.28
dm_21_1_4	21	1	4	18.00	4101.46	1.80	9.06	48.62
dm_21_1_5	21	1	5	12.00	6070.22	2.44	11.69	59.66
dm_21_1_6	21	1	6	29.00	16252.47	4.06	20.03	92.30
dm_21_16_6	21	16	6	15.00	16435.40	40.43	200.72	944.80
dm_35_1_3	35	1	3	36.00	2349.93	1.12	5.58	44.52
dm_35_1_4	35	1	4	45.00	6982.77	1.81	9.06	85.63
dm_35_1_5	35	1	5	40.00	10055.69	2.48	11.73	99.33
dm_35_1_6	35	1	6	52.00	26355.29	4.02	19.67	154.89
dm_35_32_6	35	32	6	22.00	26215.24	4.03	19.66	152.40
dm_71_1_3	71	1	3	71.00	4814.35	1.13	5.62	91.13
dm_71_1_4	71	1	4	30.00	14548.58	1.83	9.20	170.78
dm_71_1_5	71	1	5	100.00	20180.40	2.43	11.63	201.66
dm_71_1_6	71	1	6	102.00	53406.99	4.03	19.72	314.30
dm_71_64_6	71	64	6	49.00	53170.13	4.01	19.63	316.57
dm_251_1_3	251	1	3	161.00	17167.95	1.13	5.62	320.5
dm_251_1_4	251	1	4	151.00	50798.96	1.82	9.14	599.9
dm_251_1_5	251	1	5	286.00	73057.18	2.48	11.80	721.0
dm_251_1_6	251	1	6	535.00	188736.13	4.02	19.63	1117.5
dm_251_128_6	251	128	6	66.00	188258.87	4.03	1.96	1110.78

Table 9: Des Moines

instance	$n$	$k$	$m$	sim. time (s)	obj	avg price ($)	avg power (kWh)	largest peak (kW)
bo_13_1_3	13	1	3	16.00	843.75	1.06	5.33	17.36
bo_13_1_4	13	1	4	32.00	2761.91	1.87	9.40	31.75
bo_13_1_5	13	1	5	80.00	3707.74	2.52	11.86	37.01
bo_13_1_6	13	1	6	77.00	9181.61	4.03	19.41	53.59
bo_13_8_6	13	8	6	25.00	9513.77	4.02	19.50	57.03
bo_40_1_3	40	1	3	20.00	2651.70	1.11	5.53	50.03
bo_40_1_4	40	1	4	26.00	8016.06	1.84	9.23	92.99
bo_40_1_5	40	1	5	48.00	11335.13	2.50	11.75	111.41
bo_40_1_6	40	1	6	63.00	30507.66	4.07	19.78	179.32
bo_40_32_6	40	32	6	29.00	29978.17	4.08	19.71	177.39
bo_67_1_3	67	1	3	5.00	4625.82	1.12	5.59	88.89
bo_67_1_4	67	1	4	25.00	13218.52	1.80	9.01	158.50
bo_67_1_5	67	1	5	26.00	19166.54	2.40	11.68	193.20
bo_67_1_6	67	1	6	128.00	49565.08	4.00	19.56	293.76
bo_67_64_6	67	64	6	21.00	50847.42	4.04	19.70	298.76
bo_135_1_3	135	1	3	45.00	8981.98	1.11	5.53	172.25
bo_135_1_4	135	1	4	170.00	27602.08	1.83	9.16	325.76
bo_135_1_5	135	1	5	114.00	38668.73	2.45	11.64	386.87
bo_135_1_6	135	1	6	184.00	102105.12	4.04	19.77	598.08
bo_135_128_6	135	128	6	78.00	101369.93	4.04	19.69	596.32
bo_474_1_3	474	1	3	949.00	31864.64	1.11	5.56	600.63
bo_474_1_4	474	1	4	159.00	95450.24	1.82	9.11	1136.34
bo_474_1_5	474	1	5	1230.00	136395.09	2.46	11.73	1358.24
bo_474_1_6	474	1	6	411.00	356417.23	4.04	19.70	2106.18
bo_474_256_6	474	256	6	49.40	35510.81	4.03	19.66	2092.18

Table 10: Boston

instance	$n$	$k$	$m$	sim. time (s)	obj	avg price ($)	avg power (kWh)	largest peak (kW)
sf_37_1_3	37	1	3	121.00	2621.67	1.13	5.67	4.77
sf_37_1_4	37	1	4	121.00	7666.59	1.85	9.30	89.67
sf_37_1_5	37	1	5	151.00	10345.77	2.53	11.67	102.47
sf_37_1_6	37	1	6	116.00	28216.43	4.00	19.75	166.31
sf_37_32_6	37	32	6	30.00	26926.71	4.00	19.45	158.23
sf_112_1_3	112	1	3	31.00	75331.60	1.11	5.54	143.33
sf_112_1_4	112	1	4	47.00	23099.46	1.84	9.25	270.51
sf_112_1_5	112	1	5	244.00	32254.58	2.44	11.73	319.10
sf_112_1_6	112	1	6	59.00	84245.82	4.04	19.66	493.40
sf_112_64_6	112	64	6	78.00	85088.67	4.06	19.79	496.49
sf_188_1_3	188	1	3	162.00	124835.94	1.11	5.52	234.68
sf_188_1_4	188	1	4	163.00	381943.73	1.82	9.14	452.78
sf_188_1_5	188	1	5	142.00	547287.48	2.47	11.82	533.91
sf_188_1_6	188	1	6	230.00	140592.96	4.04	19.62	830.50
sf_188_128_6	188	128	6	430.00	141294.31	4.02	19.68	830.99
sf_376_1_4	376	1	4	556.00	74580.82	1.81	9.06	894.12
sf_376_1_5	376	1	5	735.00	108104.93	2.48	11.74	1072.98
sf_376_1_6	376	1	6	1033.00	283038.14	4.03	19.69	1667.89
sf_376_256_6	376	256	6	302.00	28306328	4.04	19.73	1652.88

Table 11: San Francisco

5 Conclusions

With the proliferation of smart devices, the automation of smart home scheduling can be a powerful tool for demand-side management within the smart grid vision. In this paper we proposed the Smart Home Device Scheduling (SHDS) problem, which formalizes the device scheduling and coordination problem across multiple smart homes as a multi-agent system, and its mapping to a DCOP. Furthermore, we described in great details the physical models adopted to model the smart home’s sensors and actuators, as well as the physical model regulating the effect of the devices actions on the house environments properties (e.g., temperature, cleanliness). Finally, we reported a realistic dataset for the SHDS problem for DCOPs which includes 2351 instances of increasing difficulty.

References

[1] Roomba 880 specs. http://www.consumerreports.org/products/robotic-vacuum/roomba-880-290102/specs/. [Online; accessed 18-February-2017].
[2] Sizing a new water heater. https://www.energy.gov/energysaver/sizing-new-water-heater. [Online; accessed 18-February-2017].
[3] Tesla model s specifics. https://www.tesla.com/models.
[4] Typical water used in normal home activities. http://www.pittsfield-mi.gov/DocumentCenter/View/285. [Online; accessed 18-February-2017].
[5] A. Farinelli, A. Rogers, A. Petcu, and N. Jennings. Decentralised coordination of low-power embedded devices using the Max-Sum algorithm. In AAMAS, pages 639–646, 2008.
[6] F. Fioretto, W. Yeoh, and E. Pontelli. A dynamic programming-based MCMC framework for solving DCOPs with GPUs. In Proceedings of the International Conference on Principles and Practice of Constraint Programming (CP), pages 813–831, 2016.
[7] F. Fioretto, W. Yeoh, and E. Pontelli. A multiagent system approach to scheduling devices in smart homes. In AAMAS, page (to appear), 2017.
[8] A. Gershman, A. Meisels, and R. Zivan. Asynchronous Forward-Bounding for distributed COPs. JAIR, 34:61–88, 2009.
[9] K. Hirayama and M. Yokoo. Distributed partial constraint satisfaction problem. In CP, pages 222–236, 1997.
[10] R. Mailler and V. Lesser. Solving distributed constraint optimization problems using cooperative mediation. In AAMAS, pages 438–445, 2004.
[11] P. Modi, W.-M. Shen, M. Tambe, and M. Yokoo. ADOPT: Asynchronous distributed constraint optimization with quality guarantees. AIJ, 161(1–2):149–180, 2005.
[12] D. T. Nguyen, W. Yeoh, and H. C. Lau. Distributed Gibbs: A memory-bounded sampling-based DCOP algorithm. In AAMAS, pages 167–174, 2013.
[13] B. Ottens, C. Dimitrakakis, and B. Faltings. DUCT: An upper confidence bound approach to distributed constraint optimization problems. In AAAI, pages 528–534, 2012.
[14] J. Pearce and M. Tambe. Quality guarantees on k-optimal solutions for distributed constraint optimization problems. In IJCAI, pages 1446–1451, 2007.
[15] A. Petcu and B. Faltings. A scalable method for multiagent constraint optimization. In IJCAI, pages 1413–1420, 2005.
[16] A. Petcu, B. Faltings, and R. Mailler. PC-DPOP: A new partial centralization algorithm for distributed optimization. In IJCAI, pages 167–172, 2007.
[17] M. J. W and J. E. , Braun. Principles of Heating, Ventilation and Air Conditioning in Buildingss. Wiley, 2012.
[18] W. Yeoh and M. Yokoo. Distributed problem solving. AI Magazine, 33(3):53–65, 2012.
[19] W. Zhang, G. Wang, Z. Xing, and L. Wittenberg. Distributed stochastic search and distributed breakout: Properties, comparison and applications to constraint optimization problems in sensor networks. AIJ, 161(1–2):55–87, 2005.

A Realistic Dataset for the Smart Home Device Scheduling Problem for DCOPs

Authors

Solving DCOPs with Distributed Large Neighborhood Search

A Novel Multi-Agent System for Complex Scheduling Problems

New Algorithms for Functional Distributed Constraint Optimization Problems

Privacy of Existence of Secrets: Introducing Steganographic DCOPs and Revisiting DCOP Frameworks

PingPong: Packet-Level Signatures for Smart Home Device Events

Online Guest Detection in a Smart Home using Pervasive Sensors and Probabilistic Reasoning

Multi-objective Reinforcement Learning based approach for User-Centric Power Optimization in Smart Home Environments