Hi Mike & All: I hope I can answer some of these important questions.
Mike: INSTEON allows both group and direct commands. The group commands use the link tables you refer to in the controllers and the responders. The direct commands are specific point-to-point messages used mainly by software or group-cleanup commands.
The group commands allow for a one button/one INSTEON message command that can cause a huge number of devices, to respond instantly, because at link time, they preserved their state(s). For lighting that is the light level and ramp rate. For (future-INSTEON-compatible) stereos, that's the input channel, output channel, volume, preset, perhaps even the CD track all preserved to restore to that button or command. If those were sent directly (and individually), of course it would take much time.
Having written that, the INSTEON software developer can choose to implement either group commands or direct commands or both. Most software that we've seen to date (currently including our own Timer Software (currently)) uses direct commands. Obviously as group commands provide a far more powerful approach, we intend to release another Smarthome Manager that (besides other improvements) uses group commands.
So, to directly answer your questions:
(1) you do not have to link the PLC to a device to control it, as direct commands do not require that. However, there are benefits to linking and using groups.
(2) if you do implement (or use software that implements) links, you would probably want those links backed up, which is also provided to the software developer through either direct RS232/USB data or even abstracted through our ActiveX Smarthome Device Manager for any developer to implement. This would allow your software to virtually recreate your links without requiring your manually recreating them.
(3) This answer is two part. Again for the software that uses direct links, you do *not* need to backup your links, or even preserve them at all. Plugging in another unit would allow you to control devices. However, for that extra power of groups and monitoring third-party traffic, sure, backing up via software is appropriate (and for a hundred units, I'd say required). We are working with and supporting HA software vendors in implementing backup/restoring of links. (Please ask your favorite vendor to provide backup/restoring so they are further aware of your desire). Also, (thanks Wayne) we will come out with a simple (like UPStart) and effective link management software ourselves to fill any gaps before or between HA software vendor implementations.
Our Translator uses group commands to enable X10/INSTEON translation. Should one fail out completely, you do *not* need to factory reset your devices. Responders would never hear the Translator-as-Controllers group broadcast since that ID doesn't exist anymore. And the Controllers talking to a Translator-as-Responder would transmit the same group message that already controls a number of devices anyway (no loss there). Only in the followup/cleanup direct commands would it check the Translator specifically to see if it got the message - and those messages are sent when the line is clear, politely backing off otherwise.
As this is the same very link table of the PLC, any software (including ours) that implements link table backup/restore would work for the Translator too, allowing a proper and complete switchout when necessary.
The main point that these implementations address is ... addresses. INSTEON provides truly unique IDs/addresses so that you don't control your neighbor's devices, and they don't control yours (This, of course, is but one of the issues with X10). This point, of course, brings up lots of other architecture and comparitive points - which the forum post response couldn't even begin to address. Fortunately, if you are interested in the details from which I based my answers, or in the architectural points, INSTEON has two whitepapers: INSTEON Details and INSTEON Compared located on the front page of
INSTEON.net
I hope I've answered a few of your original questions and provided some further insight into INSTEON.
Thanks for your continued interest,
Jim Gale,
SmartLabs, inc.