This page presents the high level requirements and scope for the iHale software system.   This software system is intended to provide the following services for Halepilihonua:
  • A repository that holds historical data regarding the state of household systems over time and, potentially, occupant usage and behaviors. 
  • A user interface providing:
    • Data visualizations that enable occupants to understand the current state of household systems, historical trends (when useful), and the interactions between systems.
    • Control mechanisms that enable occupants to change the state of household systems.
  • An API that specifies how services in the house can add information into the repository or obtain information from it. 
  • An extensible design that allows the system to grow and change over time with the household systems. 
There are goals for iHale beyond Halepilihonua:
  • The system will be open source, allowing students to learn from the code and adapt it to other contexts;
  • The system will provide a modular architecture, enabling developers to experiment with different implementations and alternative approaches. 

Basic architecture

The top-level architecture can be visualized as follows:

This diagram reveals several aspects of our vision for iHale.  First, the system itself has three components:
  • A web-based user interface.  This provides a simple, standard, and portable way to see data regarding the house systems and to (potentially) control them.
  • The iHale API.  This is a key design feature of the system.  It specifies exactly how external systems (either house systems or optional interfaces) communicate with it.  The iHale API specifies how data regarding house systems can be stored in the iHale system, how historical data about the house can be requested from iHale, and how iHale controls House Systems.
  • The repository where historical information about house systems is kept.
Second, all communication is done through the HTTP protocol.  We assume that all house systems can communicate using HTTP and will be assigned at least one IP address. In some cases, that might require the development of a controller/interface using Arduino or some other configurable, network-enabled controller.  Our system does not care whether the network is wired or wireless.

Third, while the iHale system provides a web-based user interface, other interfaces can be developed independently based upon the iHale API. The diagram suggests some of the possibilities: native tablet, iPhone or Android, or even Facebook.  It is also possible to interface a machine learning subsystem that would gradually learn from user behaviors in order to, for example, turn on the lights soon before the occupants arrive at the house (assuming they arrive at a regular time each day). 

Fourth, all access to the repository is through the iHale API.  Our architecture does not include a standalone database server that can be manipulated using "raw" SQL commands, for example.   This enables us to better control the integrity of data.

Fifth, authorization and authentication for the iHale API will be done using HTTP Basic authentication.

House System Requirements

For each house system, we need to determine what different types of data can be sent to the iHale system for storage and analysis.  For each type of data, we need to know the frequency with which it will be updated, the kinds of control that are possible and desirable, the potential interactions of this data with other types of data (both within this system and in other house systems). 


To be determined.


To be determined.


To be determined


To be determined


To be determined.