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. As an aside, this would not work in the case of the FanLinc either.

The solution to this is to rework the command handling, so far everything has been implemented using 'direct' messages sent to each device. In the future, this behaviour will be replaced by a several step process.

When a new device is added to plcd, the PLM will create a cross link to it, making PLM group 0 the responder to the device, and making the device a responder to the PLM, in a unique group.

The PLM protocol handler will maintain a mapping between device and group number, this will be read from the PLM at startup, and new devices added as the links are created. When the device is commanded to do something, the PLM protocol handler will look up the associated group and broadcast the command to that group instead of directly to the device.

This has one drawback in that there are a maximum of 255 controllable devices (including sub devices) but it does have the benefit of working correctly with the FanLinc. So overall this feels like a better solution. If 255 is too few devices, it would be possible to relink devices on an as needed basis, however, I don't expect this to be an onerous limitation.

I will be posting more on this solution as I implement it over the next few days