INSTEON Link Managment

Insteon links don't work quite as I had expected. Lets say I link "Kitchen Light (load)" to "Kitchen Light (remote)". When Indigo sends out a command to turn on "Kitchen Light (load)" to 50%, "Kitchen Light (remote)" should see that command and say "I'm linked to that light, I need to turn on to 50% too". Instead I have to set up these group commands to make sure they are in sync.

I'm not saying this is the fault of Indigo, It's just not working as I really need them too.

[matt (support)]

...I think I could be quite happy without the clean up commands (or at least have the option not to send them). Most of them are just insuring the indicators are in sync on all 4 switches, it doesn't matter that much if one is missed.

You could do that if the secondary switchs were in the other device's controller list, but not in the controlling device's responder list. (If I'm not getting this all backward.) But I thought I'd read your software always makes controller-responders in pairs.

That is correct -- Indigo always adds both the responder and controller links, so there is no way via the UI to setup what you describe above. You could hack it by marking the links as not persistent, then doing a factory reset of the controlling switch. However, if you ever edit the links in the responding device (check persistent or change a value), then Indigo will automatically add the link to the controller as well. If you don't touch those specific links in the UI, then it should work. Point being, Indigo only forces the "pair-ness" of links if/when they are edited.

Matt

[matt (support)]

Insteon links don't work quite as I had expected. Lets say I link "Kitchen Light (load)" to "Kitchen Light (remote)". When Indigo sends out a command to turn on "Kitchen Light (load)" to 50%, "Kitchen Light (remote)" should see that command and say "I'm linked to that light, I need to turn on to 50% too". Instead I have to set up these group commands to make sure they are in sync.

Your description is correct. Links don't work like that.

Matt

yeah. I have a entrance / stair light that has 4 dimmers switches to control one load. Using the standard linking, each switch needs to have the other three switches as responders. They end up linking both ways -- which is how the state of the light is reflected correctly on each switches dimmer indicator. That's just normal Insteon setup requirements. Thank goodness for the link management page -- I can set these switches without getting as much exercise running up the stairs.

Wow. I see a lot of posts about 3-way (or 4-way) switches and links. Here's my take about it.

Every device in my system is defined, and named, in Indigo. Even "slave" switches that have no load. For my 3- and 4-way setups, I use Indigo's description field to keep track of the switches that control the loads. And I use a device naming convention that clearly illustrates the switches that are operating any given light.

I link my 3-way switches directly together and I use AppleScript to clean up the mess that creates. I thought some of you might appreciate a specific step-by-step example. Here's the recipe for a simple setup (but it works for any number of linked devices):

Ingredients: Switch A (a SwitchLinc), Switch B (another SwitchLinc) and Light (a light fixture in the ceiling).

I installed Switch A at one end of a hallway and wired it to Light. Switch A controls the load.

I installed Switch B at the other end of the hallway (it is not wired to Light).

I defined Switch A in Indigo and named it "B-Hall Light @ Bedroom Door". In the description field I entered "[Controls Load]", which is very handy for future programming and troubleshooting, etc.

I defined Switch B in Indigo and named it "B-Hall Light @ Upstair Hall Door".

The "B" stands for bedroom, so at a glance I know where in the house I'm at.

"B-Hall Light" describes which light the device operates.

"Upstair Hall Door" and "Bedroom Door" describe the physical location of the SwitchLincs, so I can see at a glance which switch is which.

I reserve the "@" symbol exclusively for these 3- and 4-way setups.

When you have multiple 3-way setups, and all their associated devices, actions and triggers, some sort of sensible naming convention is necessary. This one works for me. The naming convention does a lot of the work of keeping track of the setup: which light is controlled, which switches control it, where the switches are located, which switches are linked together, which switch controls the load, etc.

OK...

I then physically, manually linked Switch A to Switch B AND (very important) Switch B to Switch A. Indigo's link management can do this now, but "back then" I did it manually. It's imperative to cross link all the devices involved. (This gets very hairy in 4-way setups and completely nutty in 5-way setups. I actually have one 5-way. Indigo's link management will make quick work out of that now, compared to then, running around between 4 SwitchLincs on 3 different floors. Yikes!) I tested the cross linking by turning on and off both Switch A and Switch B, and brightening and dimming each as well. If the physical linking is done correctly, then anything done at one switch is reflected in the other.

Then I went back to Indigo and resynced both Switch A and Switch B (also a very important step). Then tested everything within Indigo. Now, operating Switch A or Switch B not only updates the other, linked switch, but also updates the devices' states in Indigo.

But... not done yet. Controling either Switch A or Switch B with Indigo does not yet update both switches! AppleScript to the rescue!!

I created an Action Group called "Three-Way Sync: B-Hall Light @ Upstair Hall Door", again to clearly identify what setup it is coordinated with. This Action consists of the following AppleScript:

using terms from application "IndigoServer"
    set tBrightnessLevel to (get brightness of device "B-Hall Light @ Upstair Hall Door")
    set brightness of device "B-Hall Light @ Bedroom Door" to tBrightnessLevel
end using terms from

The script sets the brightness level (or on/off state) of the slave Switch B to whatever setting Switch A is at (remember, Switch A controls the load).

Last step: I created a Trigger Action called "Three-Way Sync: B-Hall Light @ Upstair Hall Door" (yes, same name as the associated Action Group, for the same reasons), that executes the Action Group whenever the brightness level of Switch A changes (or turns off or on).

Whew!

So... when everything is done, tested and working correctly: any change to Light, initiated from any control (either switch, from Indigo, from a control page, from my iPhone, from a group scene, whatever) updates all the associated controls appropriately!

The only thing that is not covered, is if I turn on Switch B using Indigo (remember, Switch B is the slave). I could solve this, but then it gets really complicated and can cause some looping problems in the programming logic. And it's completely unnecessary, since all my Control Page controls, triggers, actions, etc. only manipulate Switch A (Switch B updates automatically). If I use Indigo's Device Panel interface to turn on Switch B, Switch A will not update, but I have no reason to do that, especially because, in that interface, Switch A is right above Switch B, and Switch A is clearly labeled "[Controls load]"!

That's the best I could come up with. Admittedly, the AppleScript is a tad slow, especially on 4- and 5-way setups, but not too bad, really. I considered using Indigo's new scene control to speed things up, but the AppleScript has the advantage of knowing every state of Switch A (on, off, and in between). I don't think I can use a Group Scene, or even any number of them, to get Switch B to look like Switch A under every possible circumstance like the AppleScript does.

Have fun!

OK, one more thing (can't resist). This topic/problem of 3-way linking seems to be quite prevelent/common. While I understand some of this is a result of the way Insteon links work, I can't help but suggest that this might in some way be handled more elegantly by Indigo itself. Matt - it would be quite nice if Indigo could keep track of 3-way setups and do the necessary updates to linked devices...

thanks, mark, for taking the time to spell out in detail some of the types of things that the system makes us do to maintain linked devices. i hope we can now all agree that while it is possible to make linked devices work, that indigo currently makes it rather tedious and inelegant to do so.

i recently brought up some ideas of how a future version of indigo might handle this better in another thread here:

http://www.perceptiveautomation.com/phpBB2/viewtopic.php?p=15299

... and a related thread here (way back in september of '06, if you can believe it!):

http://www.perceptiveautomation.com/phpBB2/viewtopic.php?p=7306&highlight=#7306

i'd enjoy hearing your thoughts/comments.

Hi.

Yah, I had already found one of your posts after I had posted my "dissertation," and I replied, emphasizing how common, and unfortunate, this issue is for everyone.

I had a little trouble wrapping my brain around some of your solutions, but definitely agree that Indigo needs to step up to the challenge.

I fear it might be more complicated than your Control Light/Appliance Action type with a checkbox called "also control linked devices" or "simulate local control" idea, though. Because I'm not sure Indigo could, or should, figure out, on its own, what devices have the master/slave relationship.

I haven't given this a lot of thought, but how about this? I think Matt's already got the interface element where this should go: how about the "Manage Insteon Device Links" dialog, which has the Link to Controller Device section. You'd select one of the linked controllers in that list, and just as you can adjust the ramp rate, you'd be able to click on a "Mirror State" checkbox, which would then be indicated in the list's row for that linked device, perhaps under the "Other" column. This would tell Indigo that you want this linked device's state to match that of the controller's state. And perhaps Indigo would then set that same checkmark option in the linked device's Manage Insteon Device Links dialog (to simplify use of this option a bit for the user). That should be it, right? I think every set of devices that have a master/slave relationship would have their master or slave device listed, right? Or should have. Have I left any possibility out? With that option set, Indigo would [do the hard part and] make sure all mirrored devices maintained the same state, no matter how or from where the state was changed.

I think the interface would have to be designed to offer that checkbox option only where appropriate. That's the part of my idea that needs some work.

As Matt pointed out, there might be an issue with KeypadLincs. I haven't thought through that, yet. Would my idea work for those? Maybe the checkbox option should be in the Link to Responder Device list, instead of the Link to Control Device list. That way, any time a Keypad's responder device changed, the LED would update to match that, again, no matter how that device was operated. I haven't quite got the hang of the Controller/Responder relationship yet. Maybe the option should be available for both responders and controllers? Again, only when that option makes sense for the pair you're editing.

Those damn KeypadLincs. I only have one, because once purchased I knew right away they were designed wrong. They seem to trip up, in some way, everyone who dares to try one. It's somewhat better now that Indigo's Links Management can be used to keep the LEDs updated, but that's another management kludge that has to be struggled with. I've always thougt they should have had eight Insteon codes each, and act as eight, independent controllers. But that's another topic...

I fear it might be more complicated than your Control Light/Appliance Action type with a checkbox called "also control linked devices" or "simulate local control" idea, though. Because I'm not sure Indigo could, or should, figure out, on its own, what devices have the master/slave relationship.

a quick reply on this specific point:

i think indigo already has to know all about what devices are linked together in order to correctly track the state of devices. indigo already does "figure this out on its own" as you put it.

i think indigo has been doing this for a long time and that the new "link management" feature just gives us the ability to view/edit what was already there.

the only complication i can see comes from the limitation of 255 possible groups that can be sent from the controller that indigo uses - that means you can't necessarily do a simple brute-force approach and instead you might want to "simulate" a group command with a series of direct commands in some cases.

Hi.

I haven't given this a lot of thought, but how about this? I think Matt's already got the interface element where this should go: how about the "Manage Insteon Device Links" dialog, which has the Link to Controller Device section. You'd select one of the linked controllers in that list, and just as you can adjust the ramp rate, you'd be able to click on a "Mirror State" checkbox, which would then be indicated in the list's row for that linked device, perhaps under the "Other" column. This would tell Indigo that you want this linked device's state to match that of the controller's state. And perhaps Indigo would then set that same checkmark option in the linked device's Manage Insteon Device Links dialog (to simplify use of this option a bit for the user). That should be it, right? I think every set of devices that have a master/slave relationship would have their master or slave device listed, right? Or should have. Have I left any possibility out? With that option set, Indigo would [do the hard part and] make sure all mirrored devices maintained the same state, no matter how or from where the state was changed.

this seems like it would work. however, in my opinion, it seems like both more work and less flexibility than having the "simulate local control" checkbox i proposed.

more work: with "simulate local control", indigo already knows exactly what to do - it just looks at the devices that are linked together - so there's no need for the user to do any extra configuration to say that one switch is linked to another.

less flexibility: with this being an option associated with an indigo "control light/appliance" action (or corresponding applescript), the user can either use this feature or not. in a situation where the user wants to directly manipulate a single insteon device, they can do that. if they want to work at a higher level of abstraction within indigo and use the "simulated local control" to change a group of devices, they can do that, too. no existing functionality is lost.

i think indigo already has to know all about what devices are linked together

I'm not so sure. Don't devices have links to other devices that they shouldn't necessarily mirror the state of? That's why I thought the user should have control over defining the master/slave relationship.

And I think Indigo knows about the state of a device based only on the message the device sends. I think when you click a master switch's paddle (at the switch) and the slave's state gets updated, that's the direct link between the two devices doing that. Both devices then broadcast separate messages that Indigo uses to update the state of each of the devices in its interface. I don't think Indigo knows anything at all about the master/slave relationship, at least in the way it would need to, to logically sync device states that were manipulated by a controller that was not a master or a slave.

As far as flexibility goes, I can't imagine a scenario where I'd want independent control over one device of a master/slave setup. I thought that was the whole point: that no matter which device got controlled, and no matter how it got controlled, Indigo would automatically mirror the new state in every associated device. Why would you ever want Indigo to independently manipulate the state of one device of a master/slave pair? But even if you did, with my interface idea, you'd just desect the "Mirror state" option for that pair.

I can imagine, however, that you might want to manipulate a master/slave pair with a third controller that should not mirror the state of the master/slave pair (a scene, for example). That scenario will create a link in the master/slave devices. How, then, would Indigo know that the link is supposed to be there, but that the states of all three devices should not always be sync'ed?

Wow, confusing... but Matt will figure this out, I'm sure.

I'm not so sure. Don't devices have links to other devices that they shouldn't necessarily mirror the state of?

yes, possibly. in some cases, you might want to achieve a finer-grained control with indigo than you do when controlling devices from other indigo devices.

that's why i propose that the existing "direct" style of control continue to exist, with "simulate local control" being an option.

And I think Indigo knows about the state of a device based only on the message the device sends.

I think when you click a master switch's paddle (at the switch) and the slave's state gets updated, that's the direct link between the two devices doing that. Both devices then broadcast separate messages that Indigo uses to update the state of each of the devices in its interface. I don't think Indigo knows anything at all about the master/slave relationship, at least in the way it would need to, to logically sync device states that were manipulated by a controller that was not a master or a slave.

that's not my understanding.

if device A is a controller of device B, then when the user hits the button on A, a message is sent over the powerlines by A. the receivers of this message are device B and the powerlinc (connected to indigo). both receivers send acknowledge messages back to A as part of the protocol. when indigo receives the message, it knows that it is an ON command from A. it then infers that B should now be in the ON state. it does this because when it previously sync'd links with A, it knows that the powerlinc and B are the two responders to A.

to be clear - there is no message sent from B in the above scenario (aside from the ACK sent to A).

at least that's how i understand things - i could be wrong.

it seems to me that if indigo were only tracking state by sniffing for ack messages (rather than by being registered as a responder as i described above), that reliability would be low, because there would be no retransmit in the case where a message was lost or corrupted on the way to the powerlinc.

As far as flexibility goes, I can't imagine a scenario where I'd want independent control over one device of a master/slave setup. I thought that was the whole point: that no matter which device got controlled, and no matter how it got controlled, Indigo would automatically mirror the new state in every associated device. Why would you ever want Indigo to independently manipulate the state of one device of a master/slave pair? But even if you did, with my interface idea, you'd just desect the "Mirror state" option for that pair.

i agree with mark that if indigo supported the concept of "sync'd" devices (either via my "simulate local control" style or mark's method of defining "master/slave" relationships), that i would use it almost all the time and i would rarely, if ever, want to drop back to the lower level of control.

that said, however, i can imagine a few scenarios where i might want to deviate from the normal mode of keeping devices in sync. i might, for example, want to "wink" the LED on a slave switch as visual feedback when a motion sensor is triggered, when the alarm system is armed, etc. in this case, i want the command to go to the slave switch and not control the load on the master. i expect these situations to be rare, but i wouldn't want to see the capability completely go away in indigo.

if device A is a controller of device B, then when the user hits the button on A, a message is sent over the powerlines by A. the receivers of this message are device B and the powerlinc (connected to indigo). both receivers send acknowledge messages back to A as part of the protocol. when indigo receives the message, it knows that it is an ON command from A. it then infers that B should now be in the ON state. it does this because when it previously sync'd links with A, it knows that the powerlinc and B are the two responders to A.

to be clear - there is no message sent from B in the above scenario (aside from the ACK sent to A).

That sounds right, thanks for the clarification. But it's somewhat academic. We're both after the same result. If the user wants a pair of devices' states to stay in sync, Indigo should either know that based on the physical links between the devices, or be able to be instructed of that by the user (maybe both), and then act accordingly. The setup of that should be both intuitive and flexible.

The rest is Matt's problem!

And it shouldn't matter if the two devices are both SwitchLincs, or a SwitchLinc and a KeypadLinc button or even a KeypadLinc button and an ApplianceLinc, whatever. That's why I'm confused about how Indigo could automatically determine which linked devices should have mirrored states.

And I still don't see how an action group setting is less work or more flexible.

When you use Indigo to establish the master/slave link, shouldn't the option to have Indigo manage the states of the two devices be right there? Right in the Link Management dialog? Maybe even On by default? Then it would be a matter of figuring out how to handle the option if a user defines the link at the devices (On or Off by default).

How would the user use the action group solution? Or know to intuitively? Can you give an example?

And it shouldn't matter if the two devices are both SwitchLincs, or a SwitchLinc and a KeypadLinc button or even a KeypadLinc button and an ApplianceLinc, whatever. That's why I'm confused about how Indigo could automatically determine which linked devices should have mirrored states.

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?

i'll will put together some diagrams of some linking scenarios so we can use them as a basis for further discussion.

you can click the following link to download a pdf i created with some diagrams showing some insteon linking scenarios.

PDF File

i tried to capture what i thought were common insteon scenarios in diagram form to help seed the discussion. i started with the simplest possible scenario and gradually got into more complicated examples.

i generated this from the perspective of considering links and how it might make sense to enhance indigo to provide a more convenient abstraction for controlling devices which participate in various types of link relationships.

i focused on "sync'd" devices such as those that occur in virtual n-way circuits, since those are prevalent in my setup. if people have other configurations that i've overlooked here, i would like to know about them. i can add them to the doc or provide the source doc (omnigraffle) for someone else to modify.

i also tried to cover "scene"-based scenarios in the document, but i confess to having limited direct experience with setting these up. i've just have never gotten around to implementing it in my own setup.