Creating a Profile

A device profile is similar to a driver for a computer peripheral. The main difference is that devices from different manufacturers differ in the way that they function, even though they may conform to an overall standard, such as that produced by the ZigBee Alliance. For this reason, profiles are created for each device type from each manufacturer, so that each device type can present a standardized interface to the control system.

Methodology

A device profile is created by first testing a representative version of the device type from a particular manufacturer. The collected information is then used to define a unique profile for that manufacturer’s device type. The profiling must also take account of the product generation.

For example, the electronics of the Iris 1st Generation keypad was manufactured by Everspring, but the 2nd Generation keypad was manufactured by Computime. More generally, the more recent Iris ZigBee devices comply with the ZigBee HA standard, whereas the earlier Iris ZigBee devices employ an MSP standard, as used by AlertMe.

Having created a profile, it is then used to test several devices of the particular type via the control system over an extended period of time. The profile is then released for downloading by users onto their Raspberry Pi hub, so that it can be selected when any device of the particular type is being added to a network.

The same approach is applied to both ZigBee and Z-Wave devices. The Z-Wave devices conform more to a single standard than ZigBee, mainly because the Z-Wave standard is defined by Silicon Labs, which manufactures the network communication devices.

Apart from the endurance testing, it takes about an hour on average to profile a device.

Profile Definition

General Information

The definition of a profile starts with the manual entry or selection of general information about the device type, including:

• Device Name / Title
• Network Type
• Manufacturer, Brand & Model
• Group, Generic Type & Individual Type

The manufacturer of the electronics is normally identified by the device firmware, whereas the brand is the name by which the device is badged. For example, Computime is the manufacturer of the electronics for the Hive branded heating receiver. The model is that visible on the device to the user.

The group, the generic type, and the individual type identify the device type within the Action Designer.

An image of the device is also uploaded to the profile. This image helps user to identify the device visually, especially when installing it. Multiple images are used to identify the individual buttons on devices such as the Osram Lightify 4 button switch.

Each profile includes fields for data that is entered by the user via the Action Designer. For example, the user selects and enters the location of the device in terms of the floor, the room, and its position within the room. This forms part of the definition of the data source used by the control system, such as “The Temperature in the Hallway at the Front Door”.

Network Settings

When the user attaches a device to a network, the devices are listed for selection. The length of the list is reduced substantially by only showing those devices that are most likely to match the device being attached.

This is achieved by filtering the list on the type of network, and the generic device type. The network type, such as ZigBee or Z-Wave, is selected for the profile, including the ZigBee network generation, which is either Modern HA or Legacy AlertMe / Iris Gen 1. The Device Type, Manufacturer Name and Model Identification are also entered.

Events

The control system recognizes a set of standardized events. For example, these are the standard events for three of the event types and subtypes:

One of the profiles that use these groups is for the Samsung SmartThings Outlet.

The profile interprets some of the attributes reported by Endpoint #1 of this device as follows:

No button is specified for TURNEDON and TURNEDOFF, because there is only one button (switch).

All events are logged to files for subsequent investigation and analysis. This data is particularly useful for identifying the cause of any exceptions, which in turn expedites their resolution and correction.

In order to limit the volume of the logged data, while still retaining sufficient data for diagnostic purposes, certain constraints are applied. These include the minimum time period between logged events, for those devices that generate events at a high rate, which are mainly mains powered devices, and a limit on the maximum length of time that data is retained. These limits are set separately for each device.

Several devices have extended properties, such as whether it is battery powered, generates a temperature event, detects motion, detects open / close, etc., each of which is identified within the profile. Other devices report their attributes at predefined intervals, for which the minimum time interval is defined within the profile.

Bespoke Programs

Most of the device data can be expressed as simple data; Numeric, String, Boolean, or Hexadecimal. Some aspects require more logic, which requires a bespoke computer program. As with the rest of the software, these programs are written in Microsoft C#.

One example of the use of a bespoke program is for the device health checking. The profile takes all of the data being reported by the device, and interrogates the device, where relevant. It then interprets this data in a more standardized form for use within the control system, and for reporting any exceptions to the user.

These exceptions for each device are typically a loss of connection, a poor signal quality or signal strength, a failure to respond correctly to a command from the control system, and a low battery level, in the case of battery powered devices.

As the control system has control over each individual device, and monitors each device, it is able to identify and locate any exceptions to a specific device quickly and automatically, and is able to anticipate any future exceptions.

There are many other examples where devices require a bespoke C# program, including:

• Status reporting of the older AlertMe and 1st Generation Iris devices.

• Temperature reporting of devices, such as door sensors, which have a different primary function.

• Button selection on multiple button devices.

• Smart bulb color changes.

The Profile

Once all of the data has been entered, the profile is saved, a JSON file is created automatically for the profile. Any C# bespoke programs are embedded as an attribute within the JSON data. The profiles are subject to version control.

The created profile is then tested by adding a device of the type covered by the profile, for which the newly created profile is selected. The addition of any device causes an activator and action to be created for the device.

An action is also created to test the device, which is execute over a period of several days to ensure the correct operation of the device. Any embedded C# programs are complied at this stage.

Once proven the profile is encoded and made available for normal use.

Downloading & Updating

Users can download the latest versions of the profiles from a secure area within the cloud to the Micro SD on their Raspberry Pi.

When a new device is added to a network, the correct profile is associated automatically with each device by the control system.

The user can also download the latest profiles on demand, which causes all of the currently used profiles to be updated to their latest version.

To maximize performance, each profile is copied to the local RAM memory on the Raspberry Pi when the device is installed, and when the profile is updated.