Technical Introduction to INSTEON

What is this document about?

Introduction to INSTEON for people new to home automation. Attempt to collect the relevant information into a concise document for a quick read to get a basic understanding of INSTEON technology.

Hardcore home automation fanatics won´t find anything new here.

I collected these notes as I read through the INSTEON whitepaper, available here: http://www.insteon.net/pdf/insteonwtpaper.pdf

What is INSTEON

An equivalent, modern day proprietary version of X10 (from Smart Homes Ltd). It too works over AC but is a digital format achieved by FM complete with frame-checksums so reliable communication channels can be established with very heterogeneous environments. It delivers a 2K/s throughput, which while not enough for IP communication really addresses the problem of the last mile in a cheap and elegant way. All devices are equal peers capable of transmitting, receiving and forwarding messages. The messages in an INSTEON network are not routed but the devices form an ad-hoc mesh network.

Using the powerline, INSTEON is compatible with the older X10 devices.

• Created by Smartlabs Inc. who now run the alliance vendor organization.

• Development for INSTEON involves purchasing the dev kit from Smartlabs for $200 and then running your product through free testing and certification by Smartlabs. Purchasing the developer kit means you join the alliance as a member. This apparently includes the right to use the Insteon label and to sell the product in whatever channel without any other licensing fees.

• Smartlabs apparently maintains a central device database, with registered device IDs and their capabilities. Devices do not announce their metadata directly? We need to find out more about this...

• INSTEON is 110v only, not available in Europe, although this is supposed to happen in 2008.

• This is a good article that explains how commands and macros can be detached from a computer controller and uploaded to an INSTEON standalone controller.

What does OpenRemote want to do with INSTEON?

OpenRemote is thinking about supporting INSTEON as a plug-in as a priority feature.

Raison d'être

X10 is considered unreliable due to its protocol design that lacks acknowledgements, labeled press and pray.

Radio alone (Z-Wave, ZigBee) may not be reliable enough for all locations.

Bluetooth is considered to have a too short of a range.

WiFi radio is considered too expensive to include with every device and light switch.

Characteristics of INSTEON

Ease of install through existing powerline or over radio. New wiring is not required.

Network builds itself automatically due to factory installed ID in the devices and due to the ad-hoc nature of a mesh network.

Mesh networks become more reliable as new devices are added and INSTEON provides multiple pathways either through powerline or radio (or both).

Designed for low bandwidth control messages rather than high bandwidth applications.

Compatible with X10 on the powerline.

Can be bridged over USB, RS-232 or Ethernet to home LAN, the Internet, other networks.

INSTEON Protocol Overview

Messages are fixed in length. They do not contain routing information other than source and a destination.

Network is peer to peer mesh network, dual band over powerline or radio. Messages are relayed by all devices (except certain mobile RF controllers), messages are acknowledged and retried in case of failure.

Messages are standard 10 bytes or extended 24 bytes in length. Six bytes are used for source and destination IDs, three for each. Two bytes for the command, one byte for message flags and one byte for message integrity. For extended messages 14 bytes of arbitrary user data can be sent.

Message forwarding (hops) on the mesh is restricted to 4 (original link + 3 additional hops) spanning at max five nodes, including originator and receiver.

Encryption of messages can be implemented by software, as well as basic session functionality over the stateless INSTEON protocol.

Protocol Details

INSTEON standard message:

    bytes [1..3]             bytes [4..6]             byte 7      byte 8   byte 9   byte 10
     24 bits                   24 bits             1 1 1 1 2b 2b  8 bits   8 bits   8 bits
+------------------------+------------------------+-+-+-+-+--+--+--------+--------+--------+
|                        |                        |B|G|A|E|H |M |        |        |        |
|  From Address          |   To Address           |C|R|C|X|o |a |  Cmd 1 |  Cmd 2 |  CRC   |
|                        |                        |A|O|K|T|p |x |        |        |        |
|                        |                        |S|U| | |s |  |        |        |        |
|                        |                        |T|P| |M|  |H |        |        |        |
|                        |                        |/| | |S|L |o |        |        |        |
|                        |                        |N| | |G|e |p |        |        |        |
|                        |                        |A| | | |f |s |        |        |        |
|                        |                        |K| | | |t |  |        |        |        |
+------------------------+------------------------+-+-+-+-+--+--+--------+--------+--------+
                                                  ^     ^       ^
                                                  |     |       |
                                                  +-----+       |
                                                  ^ Msg         |
                                                  | Type        |
                                                  +-------------+
                                                     Msg Flags

The extended message is the same, with 'Extended Message' bit set to 1, and additional 14 bytes (112 bits) between the commands and CRC fields.

The address fields are 3 byte IDs that are unique in [0..16,777,216] range, set by manufacturer on each device.

Messages can be direct, with a to address of a recipient device, broadcast messages to the entire mesh network, or group broadcast messages to a subset of devices (linked) in the network.

Direct messages are always acknowledged. The ACK (or NAK) message may contain status information (for ACKs) or reason (in case of NAK) of the responding device.

When broadcast messages are used, the 'To Address' bytes contains 2 byte device-type identifier and one byte firmware version byte. Broadcast messages are never acknowledged.

When a group broadcast is used, the 'To Address' contains 1 byte (range [0...255]) group id, in the least significant byte. Groups in INSTEON indicate linked devices. Group broadcast messages are never directly acknowledged. Instead, the message originator in the group sends a Group Cleanup message after group broadcast to each individual device in the group which will be acknowledged. Basically group broadcast messages are a hack to achieve 'instant' command execution effect for all devices belonging to the same group (i.e. linked together).

INSTEON devices transmit data with most significant bit first.

Message Flags

One byte flag field contains message type in the 3 most significant bits: Broadcast/NAK (bit 7), Group (bit 6) and Acknowledge (bit 5). Together the 3 bits can form the following message types:

000 - Direct Message
001 - ACK of direct message
101 - NACK of direct message

100 - Broadcast message

110 - Group Broadcast message

010 - Group Cleanup Direct message
011 - ACK of group cleanup message
111 - NACK of group cleanup message

ACK bit is zero when either 'Broadcast/NAK' or 'Group' bit (or both) is set (value 1).

If message is a 'NAK' then both 'Broadcast/NAK' and 'ACK' bits will be set.

The 'Group' bit is set for all group broadcast messages and the group cleanup (including ACK and NAK) messages.

Other Message Flags

Bit 4 (Extended Message) denotes a standard (value 0) or extended (value 1) message.

Bits 3 and 2 indicate the number of message hops left in the range of [0..3]. Once value of zero is reached, the message will not be retransmitted. If the message reaches the intended recipient (To Address) before hop count is zero, message will also not be retransmitted.

Bits 1 and 0 indicate the maximum hops a message should make in the range of [0..3]. The first hop from the message originator is not counted towards the maximum hop limit. Therefore the total hops from the message originator can be up to four, spanning five distinct devices.

Commands

Commands are 'owned' by SmartHome, they maintain the table of codes for valid commands. New commands can be added to table by sending a request to SmartHome.

SmartHome also maintains a list of 'Device Classes' that specify which commands a certain device class must implement.

Commands are split to primary ('Command 1') and either parameter, subcommand, group ID or acknowledgement ('Command 2')

Cyclical Redundancy Check (CRC) Byte

The implementation in device firmware is a 7-bit Linear Feedback Shift Register. The message originator counts the value based on bytes [1..9] for standard messages or bytes [1..23] for extended messages. The receiver verifies the message by doing the same calculation.

Message Acknowledgement

The message receiver switches the 'To Address' and 'From Address' field contents and sets either ACK (001) or NAK+ACK (101) bits. The command fields of the acknowledgment will include status for an ACK or reason for a NAK.

Group Broadcast Messages

Group number is set in the 'To Address' field. Group command is in the 'Command 1' and optional parameters in 'Command 2' field. The direct group cleanup messages will contain group command in 'Command 1' field and group ID in 'Command 2' field.

Should the recipient miss the group broadcast message and not execute the included command, it may do so when receiving the group cleanup message that also contains the command.

Direct group cleanup messages will be either ACK'd or NAK'd. The acknowledgment (or NAK) will contain the group command in 'Command 1' field and either status or reason (ACK or NAK, respectively) in 'Command 2' field.

Message Retries

Message retries are handled by firmware. Applications either receive an ACK or indication that message could not be delivered.

If the message is not acknowledged, the message originator will retry sending the message. A retry may occur up to 5 times. Each retry will also increase max hops value up to its maximum.

INSTEON Devices

INSTEON devices are classified by device category, device descriptor, device attributes and firmware revision. INSTEON devices broadcast this information in a specific device identification broadcast message.

The standard message for device identification broadcast is formatted as follows:

    bytes [1..3]             bytes [4..6]             byte 7      byte 8   byte 9   byte 10
     24 bits                   24 bits                8 bits      8 bits   8 bits   8 bits
+------------------------+------------------------+-------------+--------+--------+--------+
|  From Address          |   To Address           |  Msg Flags  |  Cmd 1 |  Cmd 2 |  CRC   |
|                        |                        |             |        |        |        |
|  (as usual)            | 4 MSB = Device Category| 1000xxxx    |  0x01  | Device |        |
|                        |12 bits= Device Descript|             |        | Attrs. |        |
|                        | 8 LSB = Firmware Rev.  |             |        |        |        |
+------------------------+------------------------+-+-+-+-+--+--+--------+--------+--------+
   * MSB = Most Significant Bits
   * LSB = Least Significant Bits

The 'From Address' field in first three bytes is used as normal. The next 3 bytes of 'To Address' have a changed semantic. The first two bytes form a device type, with the first 4 bits indicating device category and next 12 bits containing a device descriptor. The last byte contains firmware revision number.

Device categories are assigned by Smarthome. Each device category can have its own set of device descriptors. These are also assigned by Smarthome for each device manufacturer.

The device attributes in the second command byte is an arbitrary set of bits that can be interpreted differently for each device type.

The 'Firmware Revision' is split into major and minor revision number, with 4 most significant bits indicating major and 4 least significant bits indicating minor revision number.

Device Linking

An INSTEON device can be linked to other devices to control them. This can be accomplished either manually through device buttons or with INSTEON messages.

A controller device establishes a group and responder devices join these group(s). A detailed link session message exchange is shown in the whitepaper starting on p.50.

While linking INSTEON devices appears relatively easy, the protocol is ill-suited for an environment where changes occur frequently. Devices must be explicitly unlinked if they are to leave a group.

Hardware Notes

INSTEON can send messages either over powerline or radio (RF). Radio transmissions are faster than powerline.

Using a powerline (US), a standard message takes 50 milliseconds to send due to breaking up the messages into smaller packets that can be sent over the zero-crossing timeslot (packets will have minimum interference on the line during zero-cross). Sending an extended message takes 108 milliseconds.

This translates to theoretical maximum bit rates of 1440 bps for standard messages and 1698 bps for extended messages. When non-zero hop count and ACKs are added, the bit rate drops significantly from the theoretical maximum.

The RF bit rate is significantly higher (38,400 bps max) compared to powerline. Sending standard message over RF takes ~3ms for standard and ~6ms for extended message. However, message retransmits may be synchronized between powerline and RF which would affect overall message rate for messages traveling multiple hops.