Ryan Herbst

Insteon Power Link XPL Gateway

Insteon is a creation of SmartHome and is an X10 like lighting and device control system. The Insteon protocol is superior to X10 using a more complex protocol with error checking to avoid problems that commonly occur with X10. I abandoned X10 a long time ago due to lights not turning on/off when they should only to turn on hours later due to some random noise on the power line. Although the Insteon protocol provides support for X10 you will find that my software does not. The older section of my house will have to wait until I get around to updating the wiring.

Insteon devices are used in my house to control:

  • Front gate lights
  • Christmas lights (in December)
  • Fountain pumps
  • Bug zapper
  • Heat lamp in the chicken coup
  • Front yard flood lights

The gateway between my XPL network and the Insteon devices consists of a piece of Insteon hardware called the Power Link Controller and a custom software daemon. The Power Link Controller is a small plug in module with a USB interface. The USB interface on the controller is well documented and available with the Insteon developer kit. An alternative to the Power Link Controller is the SmartLink Controller. The SmartLink controller is physically similar to the PowerLink Controller with a network interface replacing the USB interface.  I have not yet put any time into learning about the SmartLink controller or interfacing it with xPL since I don’t currently own one and I don’t intend to buy one until my current PowerLink controller fails. (Ok well maybe I should plan ahead a little, one of these days I will buy one).

So how do I interface Insteon to my xPL network? I use a custom Linux daemon written in c++. My custom daemon is called “xPL_Iplc”  and uses xPL4Linux framework to interface to the xPL network. xPL4Linux is a very nice piece of software which handles the xPL network layer as well and allowing your xPL software to be configured and monitored using xPL client software. It provides functions for sending out xPL messages and allows you to register a callback function for processing received xPL messages. The framework also allows you to setup filters to limit the type of messages your software will see. I have written a number of software daemons designed around the xPL4Linux library.

The software structure of my Iplcd software is shown in the following diagram:

xPL_Iplc Software Diagram

The software consists of the following c++ objects:

  • Top Level – This block glues all of the pieces together and handles the start up initialization of the software.
  • IplcCfg – This block is a container for the Insteon devices handled by the software. This object will read an XML file at startup which contains a list of  devices found on the Insteon network and their associated names.
  • IplcDevice – This is an object which represents a single Insteon capable device on the network. Currently this object is limited in scope and assumes that the Insteon devices are single channel controller type devices. I have not yet added support for Insteon sensors, multiple channel controllers or other smart controllers such as thermostats. I will add these features as needed. The IplcDevice class acts as the interface between the XPL and Insteon sections of the software design. Received XPL messages are converted to method calls on the IplcDevice class which generates Insteon messages that are passed to IplcCntrl class.  Similarly received Insteon message are passed to the IplcDevice class which will call methods on the IplcXpl class to generate the appropriate xPL traffic.
  • IplcXpl – This object receives and sends XPL messages using the xPL4Linux library. It currently implements the Lighting XPL schema. This means that all of my Insteon controlled devices are handled as lighting devices. In the future I plan to add support for sensor devices as they are added to my Insteon network.
  • IplcCntrl – This class is a high level interface to the Insteon hardware. It provides support for all of the commands and messages supported by the PowerLink controller device. It converts all Insteon level commands into Insteon messages using the InsteonMsg class. Hardware level commands to the PowerLink controller are passed through the IbiosMsg class.
  • InsteonMsg – This class contains and forms the Insteon messages.
  • IbiosMsg – This class handles hardware level commands and responses to/from the PowerLink controller hardware.
  • IplcHid – This class handles the low level USB interface to the PowerLink controller. More details about the USB interface are included later on this page.
  • IplcQueue – This class provides an asynchronous software queue for sending and receiving messages at the USB level. This queue is used since the IplcHid class uses threads to handle USB sending and receiving data over the USB interface.

The interface to the PowerLink USB level is implemented using low level USB HID (Human Interface Device) calls to the Linux kernel. In previous versions of the software I used the USB driver for the PLC found on the Linux home automation page. This was a nice driver but I found that the developer was not keeping up with the more recent versions of the Linux Kernel. Using a the Linux USB HID interface allows my software to move to newer kernels without any additional updates.

The following xPL configuration variables are supported and can be updated using DCM or another xPL configuration manager:

  • logdevice = File to which debug messages should be written. “/var/log/home/iplcd.log”
  • iodevice = Device file which can be used to access the Insteon Power Link controller. “/dev/usb/hiddev0”
  • cfgfile = File containing the XML device descriptions. “iplcd.xml”

Here is an example of a device configuration file:

iplcd.xml

My to-do list for the software:

  • Add support for Insteon sensors. Specifically the new Insteon wireless motion sensors.
  • Add additional xPL schemas. (Maybe my fountain should not appear as a lighting.basic device!)
  • Add support for groups. (Right now I have 5 controllers turning on Christmas lights! These should show up as one group!)
  • Implement reading of device state over Insteon. Right now I cache the state of the devices in the daemon. This currently works for me since most of the devices I control don’t have local on/off capability.

Please email me if you have any questions or if you are interested in using the software!

Amaroq Weather Station

Beresford Ave, Redwood City, CA
temp: 72.1 F (22.3 C) (22.3)
humidity: 52%
wind: From the WNW at 3.1 MPH Gusting to 2.5 MPH
pressure: 30.00" (1015.9 mb)
station: KCAREDWO4
hardware: WMR918
updated:July 17, 11:40 AM PDT
local forecast