Many user studies of home automation, as the most familiar representative of the Internet of Things, have shown the difficulty of developing technology that users understand and like. It helps to state requirements as largely-independent features, but features are not truly independent, so this incurs the cost of managing and explaining feature interactions. We propose to compose features at runtime, resolving their interactions by means of priority. Although the basic idea is simple, its details must be designed to make users comfortable by balancing manual and automatic control. On the technical side, its details must be designed to allow meaningful separation of features and maximum generality. As evidence that our composition mechanism achieves its goals, we present three substantive examples of home automation, and the results of a user study to investigate comprehension of feature interactions. A survey of related work shows that this proposal occupies a sensible place in a design space whose dimensions include actuator type, detection versus resolution strategies, and modularity.
Some currently available platforms for the Internet of Things include Spitfire @cite_30 , Perla @cite_22 , and HomeOS @cite_29 @cite_13 . Our feature composition is compatible with the goals and capabilities of all of these, and could be implemented straightforwardly in any of them.
@cite_30 @cite_29 @cite_13 @cite_22
2001008003 1663109347 2080219315
Researchers who develop new home technologies using connected devices (e.g. sensors) often want to conduct large-scale field studies in homes to evaluate their technology, but conducting such studies today is quite challenging, if not impossible. Considerable custom engineering is required to ensure hardware and software prototypes work robustly, and recruiting and managing more than a handful of households can be difficult and cost-prohibitive. To lower the barrier to developing and evaluating new technologies for the home environment, we call for the development of a shared infrastructure, called HomeLab. HomeLab consists of a large number of geographically distributed households, each running a common, flexible framework (e.g., HomeOS [4]) in which experiments are implemented. The use of a common framework enables engineering effort, along with experience and expertise, to be shared among many research groups. Recruitment of households to HomeLab can be organic: as a research group recruits (a few) households to participate in its field study, these households can be invited to join HomeLab and participate in future studies conducted by other groups. As the pool of households participating in HomeLab grows, we hope that researchers will find it easier to recruit a large number of households to participate in field studies. Network devices for the home such as remotely controllable locks, lights, thermostats, cameras, and motion sensors are now readily available and inexpensive. In theory, this enables scenarios like remotely monitoring cameras from a smartphone or customizing climate control based on occupancy patterns. However, in practice today, such smarthome scenarios are limited to expert hobbyists and the rich because of the high overhead of managing and extending current technology. We present HomeOS, a platform that bridges this gap by presenting users and developers with a PC-like abstraction for technology in the home. It presents network devices as peripherals with abstract interfaces, enables cross-device tasks via applications written against these interfaces, and gives users a management interface designed for the home environment. HomeOS already has tens of applications and supports a wide range of devices. It has been running in 12 real homes for 4-8 months, and 42 students have built new applications and added support for additional devices independent of our efforts. A declarative SQL-like language and a middleware infrastructure are presented for collecting data from different nodes of a pervasive system. Data management is performed by hiding the complexity due to the large underlying heterogeneity of devices, which can span from passive RFID(s) to ad hoc sensor boards to portable computers. An important feature of the presented middleware is to make the integration of new device types in the system easy through the use of device self-description. Two case studies are described for PerLa usage, and a survey is made for comparing our approach with other projects in the area.