Last night I worked more on the GUI client. I am starting to refer to it this way as it no longer is specifically Windows or Linux, it is now properly a multiplatform client with a GUI on the front.

With my research into I2CS bearing no fruit, I have decided that I will further improve the windows client.

This morning I went to install the SwitchLinc for the dining room light. I popped the old switch out and discovered a switchloop without a neutral. Not a big deal I say to myself, I have done this before! I remove the switch, tie a piece of onto the end of the wire and go into the attic to pull it up.

With this new batch of stuff, (and most of the previous batch too) there have been devices that refuse to be controlled via direct message by the PLM. After much reading this turns out to be caused by a "protocol enhancment" referred to as I2CS, or Insteon 2 with CheckSum. Part of the changes wrapped up with this is that the devices will not respond to direct commands unless the device is linked. How this relates to the direct command to go into linking mode I don't know.

Why Insteon chose to do this, I don't know. The reasons they give are

  1. Improved security of your devices

The order came in without difficulty. This time I splurged on USPS shipping because Fedex Home Delivery are awful.

In the box were a couple of InlineLincs, some FilterLincs, some SwitchLinc dimmers, some OutletLinc (Love these things!) and a KeypadLinc. There are two more InlineLinc dimmers on back order, they should be in at the beginning of next week.

Insteon in a boxInsteon on the counter

I spent the last couple of evenings with the GUI client software, way back when I was looking at how I could make it multi platform without having to rewrite all of the network handling code. I chose to use wxWidgets.

What with one thing and another, life got in the way of making any significant progress against the linking code until this weekend.

I finally got the time to put into plcd to finish up the linking code, and it appears to work in both directions.

plcd[1362]: PLMProtocol::LinkDeviceAsController: linking 1a1e8c01
plcd[1362]: PLMProtocol::GetNextLinkNumber: Next group is 2
plcd[1362]: PLMProtocol::LinkDeviceAsController:     sent: 02640102
plcd[1362]: PLMProtocol::LinkDeviceAsController: received: 0264010206
plcd[1362]: PLMProtocol SS            sent: 02621a1e8c0f0902

With yesterday's linking success, I have extended the PLM protocol handler to send group commands to those devices that have a group mapping. The idea is that I don't need to add everything to make plcd continue working. When you send an on command to a mapped device, it will send the broadcast message to the corresponding group.

The first part of the grouping is linking the PLM to the target device as a controller. As mentioned previously, this is relatively easy, with the only problematic part being knowing which PLM group corresponds with which target group. I have decided to put the target group in the lowest "link specific" byte which appears to correspond to the firmware revision of the device. plcd does not use this for anything specific and I cannot think of anything else that might use it, or if it does, how it is used. Here is the command chain while linking

As mentioned in this entry the PLM protocol handler is going to manage the PLM All Link database to provide control and feedback of each device and button.

Tonight I removed the code that configures the PLM for monitor mode (this is no longer necessary) and added code to read the link table at startup time. Using the response from this, I deleted all the links that I had set up in various test scenarios.


Subscribe to RSS - blogs