Designing Applications

An application in this context is anything that the user might want the system to do. This can range from something as simple as switching a light on and off to a comprehensive security application that controls door locks, door and motion sensors, lights, alerts, alarms.

Evolving User Interfaces

The user interfaces for both the everyday use of existing home automation systems, and the design of their applications have evolved over time.

The initial emphasis was on the use of mobile phones for the everyday use of these applications. Increasing use is now made of laptops and tablet devices, which has led to the greater use of dashboards.

Mobile phones were used initially for designing the applications, and many are still used in this way. Two factors subsequently led to the adoption of larger screen devices, especially for designing the more complex applications. The first is the inherent difficulty of trying to design a complex system using the small screen of a mobile phone, which is beyond all but the keenest of users. The second is the increased use of laptops and the ready availability of low cost tablet devices.

The use of these larger screen devices has gone hand-in-hand with the introduction of several new software tools for designing applications.

The Correct User Interface

The user interface for everyday use should be as standardized as possible, regardless of the application, as should the tools used to design the applications.

A mobile phone or a tablet provides the best user interface in some circumstances, while a larger screen device is better in others.

A mobile phone will continue to be the most suitable, and the most commonly used, for the normal day-to-day use the home automation system. Responsive website design technology enables the same content to be tailored for other larger screen devices, especially tablet devices, but also laptops and desktops.

These larger screens also enables greater use to be made of the available screen space, such as for dashboards and similar pages. Tablet devices can also be wall-mounted, and enable home automation systems to be tailored more for use by older people.

When installing or testing an individual device, a more mobile device, such as a mobile phone or a tablet device, is the best option. They enable the user to have access to both their user interface into the system, and the device being installed or tested, at the same time. Again, responsive website design technology is used to present the page content in the best way for each device.

The design of any application requires a larger screen. This enables the selections available to the user, the completed application, and a testing pane to be displayed on the same page. In this way, the user can easily change their selections, and check that the application functions as expected.

The smallest screen size on which applications can be designed for this system is a 10” tablet, and preferably used in a landscape orientation. User access to the design tools is hidden when a device with a smaller screen size is being used. This approach has been adopted on the basis that the vast majority of users will have access to a tablet device, a laptop, or a desktop.

Application Structure

Well-established software development practices have been adopted for the design of the applications.

Firstly, the concept of a three tier structure is used. This views the software as three main layers, a user interface, the business logic, and data access.

We have used the term “activator” for the user interface layer, because the user activates something, such as switching a light on, or enabling a more complex function.

We have then used the term “action” for the layer that controls the individual devices, which is equivalent to the business logic.

Two separate designers are provided, one for the activators, which are predominantly user interface related, and one for the actions, which are essentially functions to be performed by the system.

The user does not have direct access to a data layer, but instead defines the function of each device in terms that relate to its use.

For example, an Iris motion sensor also reports the local temperature. If such a device is located in a kitchen then it may be defined to the system by the user as the “kitchen temperature”. When designing an application that requires this temperature, the user merely selects the “kitchen temperature” from a dropdown selector.

The other main concept drawn from established software development practices is that of modularity.

In the context of this system, it is the actions that are modular. Any one action can also cause other actions to be executed. Equally, an activator can cause multiple actions to be executed. This modularity enables the more complex applications to be built from several smaller actions.

For example, one action might be to enable the external door sensors. Another might be to switch on certain lights at certain times. Both of these can be enabled from a single activator, which might be, say, for overnight security.

Data can also be passed between actions, and between an activator and actions.

Adding Devices

When a device is added to the system, an activator and an associated action are created automatically for that device, and the activator is made available to the user for everyday use.

For example, a smart plug may have been added in order to control a room heater in the lounge. When installing the device, the user references it as say “Lounge Room Heater”. This then causes an activator to be generated with the title “Lounge Room Heater”, and with an On/Off slider switch.

Designing Applications

Users can design their own applications. They use the activator designer to design the user interface for the normal use of the application. The activator includes the actions that it invokes. The action designer is then used to design the associated actions.

Most of the potential sophistication is in the actions, rather than the activator. The action designer is based solely on the user making selections from dropdown selectors.

These actions are predominantly sets of rules applied to one or more inputs, in order to control one or more outputs. In this context, an input might be the “living room temperature”, and the output the “living room heater”. The terms used for these inputs and outputs are specified by the user for each device.

The user is able to define the following rules for each action:

The rules for the inputs from the sensors are based on either ALL of the inputs or ANY of the inputs. For example, an ANY rule might be if the front door is opened, or the back door is opened, or the lounge window is opened.

Value comparisons can also be applied to each input, so an input can be tested for being less than, equal to, or greater than some value.

The system’s response to an input can also be conditional on one or more time periods, such between 6:00 am and 8:00 am and between 5:00 pm and 7:00 pm.

Parameters can also be set for outputs, such as the brightness and colour of the living room light.

We have also produced a range of packages, which are targeted at the more advanced applications. The user is again able to make all of their selections from dropdown selectors, in just the same way as for the action designer.

Users can also design their own more advanced actions by writing C# programs. The inputs and outputs are included by the user entering the name of the input or output, which they will know, because they defined them as part of each device profile.

For example, GetDeviceById(“Living Room Temperature”) will return the temperature in the living room.

Although the C# language is used, the programs are only as complex as the rules that the user chooses to apply.

These programs are compiled automatically as small C# executables when the user clicks on the Save button to save them. The actions created in this way can be combined with other actions, including those created with the designer.

Our range of standard packages are created in the same way, so users can access their sources to adapt for their own purposes.