INSTEON Linking Question

upstatemike

Senior Member
I think I need to get a better handle on INSTEON linking. Lets say I have a v2 lamp module and I have it linked to a v2 dimmer switch. The dimmer switch has nothing connected to the load so it is acting just as a transmitter to control the lamp module.

Now suppose I link a button on a v2 keypad to the dimmer switch. Will pushing the button on the keypad turn on the lamp module?
 
Thanks. I had it explained to me so I think I understand it now. You don't really link a switch, you link a load to a button. Could be a button on another switch or the button of a keypad. If you want three switches to be slaves to a fourth "master" switch, the load of each slave gets linked to the button of the master.

For a virtual 3-way circuit the load for each switch must be linked to the button of the other. That way pushing either switch will control both loads. (As far as I know the load of a switch is always controlled locally by it's own button... unlike UPB where that does not have to be the case) The status LEDs are considered part of the load so even if one of the switches is only used as a transmitter with no lights attached, you still have to link its load (the LEDs) back to the button on the other switch so that all the LEDs stay in synch.

The LED on a keypad button is also considered a load from a linking perspective. If you link a keypad button to the load of a switch, the keypad will turn on the switch but if you want the LED on the keypad to go on when the switch is activated locally you also have to link the keypad button's LED (its load) to the button of the switch.

This is kind of a different way of looking at it so someone let me know if I'm still off-base.
 
upstatemike said:
Thanks. I had it explained to me so I think I understand it now. You don't really link a switch, you link a load to a button. Could be a button on another switch or the button of a keypad. If you want three switches to be slaves to a fourth "master" switch, the load of each slave gets linked to the button of the master.

For a virtual 3-way circuit the load for each switch must be linked to the button of the other. That way pushing either switch will control both loads. (As far as I know the load of a switch is always controlled locally by it's own button... unlike UPB where that does not have to be the case) The status LEDs are considered part of the load so even if one of the switches is only used as a transmitter with no lights attached, you still have to link its load (the LEDs) back to the button on the other switch so that all the LEDs stay in synch.

The LED on a keypad button is also considered a load from a linking perspective. If you link a keypad button to the load of a switch, the keypad will turn on the switch but if you want the LED on  the keypad to go on when the switch is activated locally you also have to link the keypad button's LED (its load) to the button of the switch.

This is kind of a different way of looking at it so someone let me know if I'm still off-base.
Hey Mike,
You're absolutely correct! The LEDs on the INSTEON SwitchLinc are in a sense "physically" connected to their SwitchLinc load output. If the load is ON, the LED will reflect it. There is (currently) no way to have the LEDs NOT reflect the current state of its load output, unless of course you were not using it to physically control a load, but rather as a controller (virtual 3-way) for another SwitchLinc. If you were using a SwitchLinc (A) to control another (B ), basically using it (A) as a controller, you must link it (A) to the other (B ).

This is great if you want to control 'B' from location 'A' but what happens in the following example:

After linking A to control B you turn on "B" by pressing "ON" from 'A'.

Now you goto "B" and you turn it (B ) "OFF" from 'B'.

Well if you've only linked 'A' to control 'B' you'll notice that the LEDs on 'A' (the controller) will still be illuminated, showing (or indicating) that the load (physically controlled by B ) is still ON.

But we know it's OFF because we just turned it OFF @ location B. However, in order for location 'A' (the controller) to "know" that you've turned OFF B, you need to "cross-link" B to control A. So basically you link A to B then "crosslink" B to A.



Crosslink = A to B, then B to A

The same is true for controlling a SwitchLinc (or any device) from a button on a KeypadLinc. Since the buttons KeypadLinc have LEDs for each button (acting as little indicators) it's important to "crosslink" the keys with the SwitchLinc (or other INSTEON devices) being controlled by that key. This will ensure that the LEDs on the KeypadLinc will always reflect the true state (On/Off) of the device(s) it’s controlling.

I hope this helps clear up some confusion. If not, let me know. I have lots of personal experience with linking and cross linking.

Regards,
Mike Fernandez - Dr. Buddha
 
Hey everyone,
I just thought of another example which is commonly overlooked. Lets expand on the example I've already given (above).

So to clarify things, we have two SwitchLincs which we'll call "A" and "B." Only one of these SwitchLinc's has an actual "load" connected (physically) to it while the other (A) simply acts like a controller.

Now we had to link A to control B then we "crosslinked" B to control A, so everything (LEDs) would stay synched with the actual state of the load controlled by these two SwitchLincs.

Okay, so now, what happens if we want to add another controller? What if the user now wants to add an additional controller (i.e. the ControLinc - http://www.smarthome.com/2430.HTML) to the equation?

Well, most users will figure out that they need to link the new controller, we'll call it "C", to control B. But the controller "C" should ALSO be linked to control "A".

Why? So when you turn "B" ON or OFF from "C", "A" will "update" itself (LEDs) automatically. This will keep everything (LEDs) in sync with the actual state of the load. From the users perspective everything will appear tied together.

So, to simplify:

Link A to control B
Crosslink B to control A

Link C to control B
Link C to control A

If "C" where a controller that had status LEDs (i.e. a KeypadLinc button or another SwitchLinc) then it would important to "crosslink" back. In other words, continue with the following:

Crosslink B to control C
Crosslink A to control C

This will insure that the status LEDs on C are always updated to accurately show (or 'indicate') the current status of "B" (the load). This is if "C" has status LEDs, otherwise "crosslinking" is not necessary.

again, I hope this helps!
 
So let me see how I would apply this to a real-world example. The master switch for my garage is in the laundry room and I have 3 slave switches out in the garage itself. If I call the master A and the slaves B, C and D then I would have to set it up as follows:

I go to each of B, C and D and link them to control A (3 links)

I go to A and cross link it back to B, C and D so their LEDs are correct when A is operated locally (3 more links for a total of 6)

I go to B and link to C and D so their LEDs don't get out of sync when B is pressed. (2 more for a total of 8)

I add another 2 by linking C back to B and D (total of 10)

And finally I link D back to B and C for a grand total of 12 links for the 4 switches.

It looks like the number of links for n number of switches working together is Links=n*(n-1)

2 switches = 2 links, 3 switches = 6 links, 4 switches = 12 links, 5 switches = 20 links, etc.
 
upstatemike said:
So let me see how I would apply this to a real-world example. The master switch for my garage is in the laundry room and I have 3 slave switches out in the garage itself. If I call the master A and the slaves B, C and D then I would have to set it up as follows:

I go to each of B, C and D and link them to control A (3 links)

I go to A and cross link it back to B, C and D so their LEDs are correct when A is operated locally (3 more links for a total of 6)

I go to B and link to C and D so their LEDs don't get out of sync when B is pressed. (2 more for a total of 8)

I add another 2 by linking C back to B and D (total of 10)

And finally I link D back to B and C for a grand total of 12 links for the 4 switches.

It looks like the number of links for n number of switches working together is Links=n*(n-1)

2 switches = 2 links, 3 switches = 6 links, 4 switches = 12 links, 5 switches = 20 links, etc.
Hey Mike,
Yep, it sounds like you've got it figured out :lol:

So to simplify the process, it looks a little something like this:

We have 4 SwitchLinc's (1 Master = A, 3 Slaves = B, C, D)

A links to B
A links to C
A links to D

B links to A
B links to C
B links to D

C links to A
C links to B
C links to D

D links to A
D links to B
D links to C

Hmm, 12 links! Yah, it's a lot of linking, but the end result is the utmost in flexibility. The process can be time consuming because you have to interact with each SwitchLinc, however when software is available, it should support reading/writing to the devices databases allowing the user to easily setup something like this via software (maybe even as easy as dragging and dropping?). Until software is out to make it a little easier, it will have to be done manually, but at least this way here you become an expert like me B)
 
For my example it would really be 20 links. Once INSTEON is supported by my Stargate I will need to create 4 more double links to link each switch to the controller! I did an inventory the other day and found that instead of the 100 or so X-10 devices I thougt I would be replacing, it is actually closer to 150 since I have to replace passive slave switches with full INSTEON ones for multi-way circuits. This means 300 links to a controller before I even start to count the links between various switches and keypads!

I also note that keypads count as either 6 or 8 switches in my link formula. Plugin modules do not dual link to keypad buttons or link at all to each other since they do not have transmit buttons (local control from sensing operation of a lamp switch does not generate a status transmission). So you leave plugin modules out of the formula and add those single links at the end of the calculation.

Example- The master bedroom/bathroom/dressing room area has four 6-button keypads and 5 plugin modules. Each button belongs to a group controlling 1 module except the sixth group which controls a load connected to one of the keypads.

The keypad buttons would be Links= n(n-1)6 (for a 6 button keypad where all buttons are configured the same) for a total of 72 links. Each plugin module is single linked to all 4 keypads so that is just 5*4=20 Links. A controller will need to double link to every button on every keypad (4*6*2=48 Links) and single link to each of the 5 plugin modules. The grand total to set up the master bedroom area will be 72+20+48+5 = 145 Links! Good thing I'm not using 8 button keypads!
 
upstatemike said:
For my example it would really be 20 links. Once INSTEON is supported by my Stargate I will need to create 4 more double links to link each switch to the controller! I did an inventory the other day and found that instead of the 100 or so X-10 devices I thougt I would be replacing, it is actually closer to 150 since I have to replace passive slave switches with full INSTEON ones for multi-way circuits. This means 300 links to a controller before I even start to count the links between various switches and keypads!

I also note that keypads count as either 6 or 8 switches in my link formula. Plugin modules do not dual link to keypad buttons or link at all to each other since they do not have transmit buttons (local control from sensing operation of a lamp switch does not generate a status transmission). So you leave plugin modules out of the formula and add those single links at the end of the calculation.

Example- The master bedroom/bathroom/dressing room area has four 6-button keypads and 5 plugin modules. Each button belongs to a group controlling 1 module except the sixth group which controls a load connected to one of the keypads.

The keypad buttons would be Links= n(n-1)6 (for a 6 button keypad where all buttons are configured the same) for a total of 72 links. Each plugin module is single linked to all 4 keypads so that is just 5*4=20 Links. A controller will need to double link to every button on every keypad (4*6*2=48 Links) and single link to each of the 5 plugin modules. The grand total to set up the master bedroom area will be 72+20+48+5 = 145 Links! Good thing I'm not using 8 button keypads!
LOL Mike,
Your math is way better than mine so I'll let someone else verify your logic B)

It sounds like you've got it all figured out though. A couple of things though, you're right about the plugin modules not TXing upon local load sense. So you don't have to worry about crosslinking any plugin modules.

On another note, you don't have to link every device to every other device. I LOVE KeypadLincs and consider myself somewhat of an advocate of KeypadLincs, however I only link devices to the KeypadLinc's that I'll be controlled/monitored from their respective KeypadLincs. This may still mean quite a bit of linking as each KeypadLinc typically controls several different devices, but I don't think I've ever linked more than 6 devices to one KeypadLinc, the exception would be if I wanted a button to control everything in a certain room, but in that case I wouldn't cross link any of the devices back to that button, because if any one device turned OFF but the others stayed ON, the button would turn OFF, which doesn't make much sense to me.
 
To damn complicated for me. A light switch is a light switch. Let it be dimable and have a ramp rate and let you HA software do the rest. Sheesh. :D B) ;)
 
TCassio-

I know you feel all the logic should be in a centralized controller but I don't think current technology limitations will allow that. Every command would have to be processed by the controller and there is currently nothing available that does not get overly busy and have latency problems. PC based stuff has too much overhead supporting windows and patches and service packs and plugins and drivers and virus software and anti-spyware software and.... While all current hardware controllers are way underpowered with respect to processor speed and memory space. Schemes to offload functionality to local switch hardware is not just an alternative approach, in the current HA universe it is an absolute necessity.

FTB-

I'm not linking everything to everthing but when you have several keypads controlling the same area from different locations then you are going to have to link a lot of buttons together to keep the LEDs in sync.
 
To be quite honest, I am running a P4 proc 2 ghz with 512 meg of ram. I am running Homeseer, MLserver, J River Media Center/Server, TTS, A USB-UIRT, WGL W800 and a Smarthome Powerlinc. I have about 60 diveces and some odd 90 events. And the system dosen't miss a beat. I do beleive the computer is under utilized. Seems it could handle a whole lot more.

I don't see how you can acheive any kind of AUTOMATION without a central controler.

I would think from a service stand point, the Switchlinc linking scheme would be a nightmare if one were to fail.

But I guess that what makes HA so much fun. Alot of different approaches and ideas with endless possiblities. "And to each his own" B)
 
But I guess that what makes HA so much fun. Alot of different approaches and ideas with endless possiblities. "And to each his own"

Pretty much the whole idea of having a forum! Wouldn't be very interesting if everybody just agreed with each other all the time! B)

As for a link failing, it really isn't a big deal. Remember a link is really just a single entry in a table on a single device. If you lose a link all you are really losing is that one entry and you can always add the entry back by going through the linking process again. A server failure on the other hand...

I am interested that you are having such good performance with your system. I tend to have a lot of concurrent activity happening (greeting a guest at the door while simultaneously speaking a lengthy status report in the kitchen while also sending a bunch of X-10 commands and updating logs based on data from hardwired inputs etc.) and sometimes I see some latency in the reaction of a motion sensor or something. What do you use as your hardware interface for hard wired inputs?

I don't see how you can acheive any kind of AUTOMATION without a central controler.

I'm not suggesting a technology like INSTEON should replace a central contrller. I just think off-loading some of the overhead related to light control can free up controller resources for other tasks.
 
upstatemike,
I am running HS2 w/500 devices and 200 events with most plugins, MainLobby server w / all plugins, Media Center w/ a library of 20,000 songs, 3 terrabytes or so of storage, various monitors, 10 comports attached to devices, a TV capture card (PVR350), Alarm system monitoring, X10 and Insteon lighting, and lots more and the server doesn't miss a beat.

I am thinking of offloading some stuff to the ELK M1 for no real reason other than to do it and to test some new plugins.

Multithreading HS2 has been a big help towards everything running smooth.
2.8ghz P4Hyper, 1 gig ram.
 
Thanks for the feedback on your system. I have to admit I don't know what to think about HS at this point. Some people like you and TCassio have had no problems at all while other people seem to have had their systems go down the tubes with 2.0 and never recovered.

My personal situation with HS is that I tried it about a year ago and didn't like it for a few reasons:

1- I expected you to be able to do more from the gui. I didn;t expect to have to start writing scripts for really basic stuff (like speaking variable values). Scripting is OK, I just wasn't expecting to have to do it for core functionality.

2- The stargate plugin required me to use com1 on my stargate which is also used by Winevm (the stargate programming interface). I tinker with my stargate program a lot and every time I fired up Winevm I had to shut down Homeseer. If I have to shut it down all the time I can't have it doing anything critical so I never moved much to the HS system.

3- Homeseer does not support general ASCII I/O. (You can probably write scripts to do it but I don't have enough VB skill to manage it and I kind of felt ripped off that this was not a basic feature included in the gui interface). Most things are easy to control if you can send and receive ASCII on a serial port. Without a generic ASCII interface you have to wait till someone writes a plugin for the device you want to control or learn more about VB than I care to know.

Anyway, I will keep learning about HS and CQC and all the other PC based systems from folks like you on ths board but I don't expect I'll try running one again anytime soon.
 
Back
Top