Running the Insteon PLM Driver for the First Time

Monitoring the log

Because this is a BETA driver, I recommend that everyone who runs this, please monitor the log for errors.

To monitor the log:

• Open WebAdmin
• On the Left pane, select 'Generic Serial Devices'
• On the Insteon PLM Device, click 'Advanced'
• in the TOP RIGHT, click 'FOLLOW LOG'

This will pop up a new window with the log processing in real time. When you quick reload the router, I'd recommend pressing F5 on the Log window to clear out the old history. During the initialization of the GSD, it shows all the code (over 2000 lines) before it actually 'starts' (hence the refresh)

Initial Device Setup

Insteon Devices

Running for the first time

Initially, the driver needs at least ONE active lighting device. The driver will download this device's database and attempt to extract other Insteon ID's from it. Then it goes out and PINGS those devices to find out what kind of device it is. Once that is finished, it attempts to download each device's database, in turn, looking for more Insteon devices. This procedure nicknamed 'Spidering' continues until all devices and device links are recognized. Once this 'Spider' is complete, the driver reports all detected devices, to LinuxMCE.

Running for the Second time

Once the devices have been added to LinuxMCE, they can now hold their configuration. Even though all the databases were downloaded during the first run, the devices themselves did not exist, and therefore, we can't store their configuration during the first run. This happens on the second run. You will now see a 'Configuration' field in each device. This holds the device's Type, Database Delta, and all ALDB records (the remote database) encoded into a long string.

If, at any time, you want to re-download a device's database, simple delete the configuration string. Upon next reload, the driver will go out and redownload the remote database.

Running after the first two times

Part of the configuration string is something called a DATABASE DELTA. It's basically a byte that increments each time the remote database is altered.

I store the Database Delta when I read the complete database. Then, upon router reloads, I ONLY read the database delta from the device. I compare that with the value stored in it's configuration, and if they are the same, I know I don't need to do any further downloads to that device.

This speeds up initialization dramatically. Sending 1 command vs sending 8 commands per record, and on average, more than 2 records.

Currently, I cannot figure out how to call the Lighting Wizard. Ideally, this would run at this point to allow simple configuration of all the lighting devices.

Alas, you'll have to use webAdmin to select Rooms and Floorplan Object Types. (don't forget this, it's important!)

Note: The Driver will automatically determine the type of device. If it's a Dimmer, it will assign it to Lighting Switch (dimmable). If it's a switched device(on/off), it will assign it to Lighting Device (ON/OFF). If it's a EZRain1 Sprinkler controller, it will assign it to an Irrigation device! (This may need some debugging)

X10 Devices

X10 Devices must all be added manually to the Lighting Devices. X10 devices are truly 'dumb' devices, and hence, don't have databases to download.

X10 Motion Sensors can be used as Security Devices. They report an ON command when motion is sensed, and an OFF when no motion is sensed (within a timeout period)

X10 and Insteon can co-exist. (You can have a mix of devices)

Bidirectional Communication

The Insteon devices support Full 2-way communication. You can verify this by watching the logs as you turn a light switch on/off or dim/brighten a light switch.

X10 Devices support 2-way communication of ON/OFF commands only. Support for more commands can be implemented with little trouble. (I had to get the beta out)

Error Detection

As with all communication systems, there's always errors. Power Line Communication errors are handled in this fashion:

• Process IDLE triggers about once every 2-3 seconds (I think)
• Commands will TIMEOUT on the FIFTH Process IDLE (watch the log, you'll see)
• When a TIMEOUT is detected, the command is retried 3 times before FAILING.
• When a command FAILS, the driver simply discards the command.