plcd

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.

While trying to control the individual buttons on a KeypadLinc, I had to implement the extended command handling to transmit the commands to control the LEDs. This went a lot easier than the standard command work, due to the lessons learned through that process. However, the documentation which led me to believe that the LEDs are individually controllable is incorrect, and it turns out that you actually send a bitfield. For this to work properly, it would be necessary to read the existing LED state, and 'or' in the desired change, involving 2 powerline commands.

After the final command sending post here it has been working properly. I recently turned of the transport logging, and found it broken again. There must have been a race condition that was hidden by the slowdown caused by the extreme amount of logging.

With the revelation that every single device and button needs to be linked to the PLM to report its status, it became apparent that plcd needs to deal in 32bit addresses. Insteon uses 24bits for each device, and plcd uses an additional byte for the controller group. For example

0xAABBCCGG

Back on 6/22 in this post I mused about adding a group parameter to the Device class and into the corresponding config file entry. At some point over the last week (actually it was 7/4 according to git) I made the configuration file changes to add the groups.

Tonight I added the group to the DEVICE network thread command, when sent from plcd. It now reads

DEVICE:&ltaddress&gt:&ltname&gt:&ltgroup&gt:&ltstate&gt:

With the discovery of the need to link each controller group to the PLM, it is simple to determine that a button has been tapped or a switch switched. The problem remains that in most cases there are devices linked to that controller which do not report their state to the PLM.

As time has passed, I have been trying to understand how the PLM will present commands that are sent through the Insteon network. Through testing I have discovered that there are no commands received by the PLM for any device or group that is not linked to the PLM.

To overcome this limitation, it is necessary to link all controllers to the PLM (PLM is a responder). While it is only necessary for one controller group per device to be linked, by linking all controller groups, it guarantees the message gets sent to the PLM.

A few posts ago I was having issues with commands not having all the bytes I was expecting. It was causing issues with sending commands as I would on occasion not get "command 1", it was causing issues with receiving commands as I would not get some parts of the command, most of the time "command 1". Generally it was being a HUGE PITA.

Pages

Subscribe to RSS - plcd