dduff617 wrote:i think this highlights how we are seeing the problem slightly differently.
in the scenarios i can think of, it seems like it works well to be able to tell indigo to control (i.e. "turn on", "turn off", "toggle") device X directly (the current default) or control device X and it's responders. i haven't come across any scenarios so far where this wouldn't work fairly simply and elegantly, but i may be missing something. can you suggest any?
Absolutely. And yes, we are seeing this slightly differently, probably based on our own setups. For 3-way SwitchLinc setups, your interface idea would definitely work. Slaves and masters are responders to each other, no problem there. Although, I would still argue that the option should be available at the device level, not the action group or trigger action level. I don't want to have to remember to tell Indigo to treat master/slave pairs as such for every action that involves them. I'd personally want to tell Indigo just once that the devices are a master/slave pair. I think you want to maintain the flexibility of controlling each component of the pairs separately, but I can't imagine why you'd want to do that. I can imagine (and do have) many, many action groups that manipulate my 3-way SwitchLincs.
But here's a few scenarios you've overlooked. I have them in my system now, and the first one elicits many complaints from other Insteon users. The dreaded KeypadLinc! I have a KeypadLinc running my aquarium. One button for each ApplianceLinc (for various lights and pumps). The ApplianceLincs are responders to the KeypadLinc, but the KeypadLinc (and more importantly, its buttons) are not responders to the ApplianceLincs. I have Indigo manipulate the ApplianceLincs directly, and those actions don't update the KeypadLinc correctly. So that wouldn't work with your solution.
Here's another scenario: I have a set of ApplianceLincs that operate small red lights that go on when my garage door is open. They are in different rooms. I want those two ApplianceLincs to be in sync with each other, but ApplianceLincs cannot be responders to each other.
Or how about this: a LampLinc that you want to control from a SwitchLinc. Maybe you have a ceiling light fixture that you want to brighten and dim together with a table lamp. You'd want the two to stay in sync regardless of which device you (or Indigo) controlled.
I could think of many more scenarios. This is why I want to be able to define the master/slave (or twin) relationship between any two devices, without regard to Insteon's definition of linked devices. And that's why I was insisting that Indigo not be relied upon to figure out what the pairs are.
My idea is not just to make easier the maintenance of the pairs that Insteon allows, but also to add possibilities that the protocol was never designed for. I'm suggesting we prod Indigo into making things possible that Smartlabs hadn't considered, not just make their vision of home automation a little bit more elegant or a little easier to setup.
Now these ideas may well be beyond the scope that Matt has in mind for Indigo, but for me personally, Indigo's ability to track, update and sync any pair of devices would be of great value.
).