As time has gone on (and looking at the blog, it's been a lot of time) I decided that it would be great if plcd somehow knew that two devices were linked at the device level (ie directly).

As this is an Insteon concept, I decided it was the PLM protocol's responsibility to inform the engine that switching device A on also meant that device B turned on as well. So I added the parameters to the configuration file as "PLM.LinkedTo" followed by an incrementing number, so "PLM.LinkedTo0" is the first, followed by "PLM.LinkedTo1" etc.

This meant that the Parametered class got extended to return parameter arrays, where a vector is filled out with all of the arrayed parameters as strings. The calling function can then decode them as it feels like. If a parameter is the empty string, or not present then the retrieval ends at that point. You can also write the vector back into the Parametered class, at which point it will use the same method to store it.

Doing this, was great, but led to a problem. Namely sending the same command to a device for each of the linked switches. For example in the living room, we have 3 switches that are set up to mimic a 4 way switch. Each of them is linked to one outlet, and via a macro to another outlet, this worked well, pressing any one of the three switches caused whatever it was that you expected to happen. With the new linking parameters however, it caused it to happen 3 times, as turning one switch on, caused the other 2 to turn on. I fixed this by adding some "Link" commands. That cause the engine to update the device states, but are not matched into any macros.