MarkJames

Sorry for steering you in the wrong direction earlier. Here's a program I use to do something similar I have one switch that turns on 2 lights. If either one of the lights turns on it turns on the switch but I don't want it off until BOTH the other lights are off. If Status 'LIGHT - A' is Off And Status 'KPL - A' is Off Then Set 'TRIGGER - Both Things' Off Else Set 'TRIGGER - Both THings' On This way if ALL of the first three are off then the trigger turns off - otherwise the trigger turns on It works well - there's a second or so lag for program execution. I found it worked better based on status then on condition because the condition seemed to get 'missed' sometimes.

Learn something new every day I just tried that and confirmed it. A dim level of 0 will not turn off a KPL button - only a load.

Ok.. sorry... I didn't understand that A must toggle on and off. If that's the case then my first suggestion won't work. It sounds to me like you have the loads connected as members of the scene but not the buttons that control the loads. Can this be the case? Your scene - in the simplest case - should look like this KPL 1 - button A - controller KPL 1 - button B - responder - dim Level 0 KPL 1 - button C - responder - dim Level 0 KPL 2 - button B - responder - dim Level 0 KPL 2 - button C - responder - dim Level 0 KPL 3 - button B - responder - dim Level 0 KPL 3 - button C - responder - dim Level 0 Load controlled by KPL 2 - button B - responder - dim Level 0 Load controlled by KPL 2 - button C - responder - dim Level 0 I'm assuming here that KPL - button B, KPL 2 - button B and KPL 3 - button B control the same load? If you have it that way then no matter what you do to KPL1 - button A - on or off (but not hold and dim) should make all your buttons B, C, and their loads turn off. mark

Now from what you wrote it sounds like you want to press buton A on any one of them and have buttons b and c go out on all of them There are two ways I can think of to do that. One - make A a non-toggle off. Then create a scene with B&C from all the KPL's as members with A from All of them as controllers. Pressing any A will turn every A, B, and C off then Two - make a scene as above but highlight the A in the scene and make sure that each of the A, B, & C's have dim levels set to 0 in their scene properties in response to each A. So if you make a scene like that then A-on will turn them off because their dim level is 0 and A-off will turn them off because that's normal. Just be sure you're looking at the A as a controller part of the scene when you check. If you don't make the A non-toggle off and you haven't set the dim levels to 0 in all of them then the A will simply toggle all the responders to match its current state - ie A on will turn them all on, A off will turn them all off. Does that help any?

I don't use the button groupings feature much but if I understand correctly you're trying to make the buttons grouped on one KPL trigger in response to the buttons on a different one? If that's so, I don't believe that's possible. The button grouping is internal to each KPL - so that when you press one the others respond accordingly. At least that's the way I understand it. But if they're triggered from remote they don't follow the groupings. At least not the way I understand it. I think button groupings are a local function. I do something similar to what you're doing but I use scenes to do it. I join all the responding buttons in a scene and use the other KPL as a controller to turn them on/off at once.

I have older KPLs in my bedroom that don't dim. They came with the clear do-it-yourself button kit. I just made a template in photoshop for the buttons and printed them on photo paper with white letters on a black background. When printed in high quality mode on an inkjet it cuts the light down a LOT and they're very easily readable. I quite like them - and my wife does too... she can't sleep with any light in the room. mark

The thing to remember - that markens pointed out - is the way ISY handles programs. The IF condition part of the program is continuously monitored. An IF (status) is ON will be evaluated every time the status changes - so if it's ON and it goes OFF the condition will be reevaluated and the ELSE will happen. An IF (condition) like ON pressed will be evaluated whether it's an ON or and OFF. If at any time the IF changes the program will STOP if it's running and the whole IF is reevaluated and the THEN or the ELSE happens. So if you have a series of steps separated by a WAIT and the program is in the middle of the wait all is well until the IF changes again - that will cancel your program and start the whole thing over again with the appropriate then or else. It's an interesting way to do it - and it confused the crap out of me for a bit. I think markens is the one who explained it to me the first time, too. It makes you think more 'dynamically' and though it creates a few problems it also solves a few.

Well.... I just tried adding yet another motion sensor - 2420m Rev 2.0. Specified unit ID, specified Remove existing links - got the failed to write highwater mark error along with that node error. I put it back into linking mode and repeated the exact same steps but this time it successfully added. I don't know if it's ISY or me... I'm just glad it added. mark

That was it... I knew that's what it was - I just couldn't see it. I get bit by the 'change the condition, restart the program' mistake ALL the time. mark

well - I have another one in a box from smarthome - I'll try that later. It seems that it matters if you remove links or not and if you autodiscover or not. There was another post in a different thread with someone having a problem with it as well, though. mark

I see there are still issues adding motion sensors in 2.7.11? autodiscover with remove links doesn't work for me with a 2420M fresh out of the box. mark

That looks like it should fade the light off - 25% every 10 minutes. However you really should put the light into a scene. Simply create a scene called 'my daughters light' with whatever the light as a responder. You can then use the insteon - adjust scene command to dim the light. Even simpler still, though, why don't you just put it in a scene with a ramp rate of 40 minutes and turn it off? That's much more straight forwards and doesn't depend on a program. The lamp will simply dim down over 40 minutes to off. It doesn't have to have this ramp rate for everyday use - just as part of that one scene. mark

Restore - at least in my experience - does not restore the button mode of a KPL - 6 button vs 8 button, nor does it restore the button toggle mode. I don't use button grouping so I can't speak to that issue. All of these features are remote configurable - I just wonder why restore doesn't 'fully' restore? Is it just the way it's working in MY installation? Or is this the way ISY restore is written? I only ask because I have quite a number of KPL's that are not configured as their 'default' - 6 or 8 button. So if I want to restore after a reset then I first have to configure it to the right number of buttons, then restore, then reset my button toggle modes. It seems like a lot of steps that ISY could be handling for me. Don't take me wrong... I'm not griping - I'm just wondering if this is a problem that is unique to me or if it's just the way it is or if the plan is to eventually fully restore a KPL mark

That is if you don't have to change them from 6 button to 8 button or vice versa

Why, I guess, is a good question. My guess would be so he doesn't chew up 3 spaces in his panel for just a signal bridge and PLM. Personally I had space for a 220 breaker that I could dedicate to the signal bridge. If I didn't, though, I would have piggybacked the signal bridge off something 220 that doesn't run very often - we have a steam shower that would be perfect. The steam shower is off 99.9% of the time so for 99.9% of the time the signal bridge would have the circuit to itself - the other .1% of the time the signal would cross over through the steamer circuit anyways. The other option is to screw the whole signal bridge thing and get that smarthome bridge that plugs into your dryer outlet. It'd save you a breaker and two spaces in your panel. This guy... http://www.smarthome.com/4816B2/SignaLi ... ler/p.aspx The only criticism I have of it is that it pushes your dryer away from the wall a bit if it's right behind. The PLM, though, should really be a homerun if possible. Anyways - I wasn't trying to pick nits with you, Tahoe, I've just had this 110v coming off a 220v circuit issue come up numerous times in my home. Mine is 28 years old so I'm constantly having to 'make do' with existing wiring. I've had cause to worry about it more than a few times over the years - having to decide whether to run back to the panel or take a leg off the 220. I'd definitely make sure and color code the legs properly if you're going to take 110 off 220 as leaving them improperly coded can come back and bite you in the behind bigtime.

KPL buttons when acting as responders can, indeed, be addressed directly. It's not the way ISY deals with them though. You would simply send an on command to the address of the KPL and the button # you want on or off. you can do this using a serial PLM if you cared to use something like hyperterminal and send the insteon command set manually. Powerhome does this for you and I can tell you from personal experience that it's no panacea. ISY doesn't work that way because if it did you would be able to write programs that changed KPL buttons and ISY would have no way of knowing. By forcing you to put the button in a scene it can track the changes. There's no down side to using the PLM and a scene structure - it's just a different way of thinking about the same problem.

robandcathy - I had the same issue at one point with 2.7.10. I exited the ISY console, closed the browser, unplugged the PLM to force the ISY to reboot and then plugged it back in, opened a new browser session and started admin console again. That cleared the write icons. Actually it didn't one of the times and I had to hit the write updates button - but it did ultimately go away this way.

I use the ISY's IR control but do not have an IRlinc. I've merely plugged my IR distribution bus into the ISY IR port. The signal strength is great and the responses work fine but it's come to my attention that were I using an IRlinc I'd be able to add the buttons to my main lighting page and use them directly. The way it is now I've been using them via program control. Is there a way to add the IR buttons to the main screen WITHOUT an IRlinc? Or a way to fake an IRlinc and add them like that? mark

Sorry.. that's not true. 220 breakers are common trip - if one side trips then both sides open. I've asked several electricians about this and they all give the same response - it's safe. It is also to code where I live but only if you color code the wires properly - wrapping white around the appropriate leg you're using for neutral. Mark

In just installed 3 of the 2410 signalinc hardwired couplers - one in each panel. I can't tell you if one vs 3 makes a difference as I installed all 3 at once but I CAN tell you that the hardwired phase coupler has made a significant improvement to my communication quality. I no longer bother with access points that communicate with each other - I uwse them only for RF. For what my 2cents is worth I took off the load from the bottom double breaker on my main panel - the 2 closest to the incoming line power - and attached the first signalinc there. I have no reason to believe this is in any way a greater 'quality' spot - but if any spot was gonna be the best logic would have it that that should be the one. I did the same in my sub-panels located in other buildings. I didn't run a box for my signalinc - My house is already finished - I just left the signalinc loose inside the panel. I doubt it's to code (actually I'm sure it's not) but I don't see what harm it can cause.

Are you sure about that oberkc? I would have thought that the status of the light itself would have to be in the condition being evaluated for that to happen. I still get confused by the then/else functionality of ISY

I began with X10 in the early '90s and adopted Insteon devices bit at a time as they came out. I have a fairly large installation - over 100 devices in all spanning multiple buildings and multiple electrical panels. X10 was a nightmare in this setting and Insteon promised to be much better. It is, in fact, much better and over time I've learned a bunch of things piecemeal from many tech support people and many forums that I thought I would share in the hope that it would make it easier for the next person. First off some nomenclature. Every insteon device has an address - in the format aa.bb.cc where the letters correspond to Hex number 0-F. This system allows for over 16 million different addresses and I doubt Smarthome has sold that many devices but at some point they will repeat. It is important, though, that every device in your home have a unique address. Next - Insteon deals in 'groups'. Every kind of command in Insteon is a group command. As such the words related to Insteon are heavily flavored with the word group. Insteon also deals with 'controllers' - devices that send group commands such as on or off and 'responders' - devices that receive these group commands and act accordingly. Some devices are both controllers AND responders - such as Keypadlincs or Switchlincs. Some are just controllers - like Motion Sensors - and some are just responders - like Inlinelincs. Regardless the terminology is the same. In the context of a device as a controller the buttons on that device are not referred to as buttons. They are referred to as groups. A switchlinc has, therefore, 1 group - its paddle. We'll call this group 1. Keypadlincs can have either 8 groups or 5 (the on/off on a KPL6 is group 1). When they have 8 groups they're simply referred to as groups 1-8. When there are 5 groups they are referred to as groups 1,3,4,5,6 In the context of a device as a responder the buttons are referred to as buttons - and the numbering is the same as the groups are for controllers. If it helps, you can think of the part that clicks when pressed as the groups and the LED's that light up on them as the buttons. The basic Insteon command set that concerns us - outside of the bright and dim commands are on, fast on, off, and fast off. Fast on and Fast off are simply double-presses of an on or off. Insteon gives you some extra flexibility in the way it handles them. On turns the device on to the set dim level at the set ramp rate. Off turns the device off at the set ramp rate. Fast on turns the device full on instantly and Fast off turns the device full off instantly. OK... so let's examine how Insteon works and how ISY ties it together. When you first install an Insteon device like a Switchlinc it will just control its load - no different than a regular switch. On will turn on, off will turn off, hold the button will dim/bright. I'm going to skip over the parts about setting the ramp rate and bright level on an individual switch in isolation for the moment as the internal method is different than 'regular' insteon. That's because there is no powerline transmission - it's all done internally. So let's go on to the next logical step - linking two devices. Every Insteon device has a controller link table and a responder link table. The controller table keeps track of what that device controls - it's the 'who do I control?' table. The responder table keeps track of what devices control it - the 'who controls me?' table. A typical controller record will keep the address of the device to be controlled, the group on the controller itself responsible for the control, and the button # on the controlled device that will be controlled. So in a switchlinc with address aa.bb.cc that will be controlling switchlinc device dd.ee.ff there will be a controller record in aa.bb.cc that says dd.ee.ff, group 1, button 1. The group and button numbers must be 1 as a switchlinc only has 1 group to send and one button to respond (they are physically the same thing - only the name changes) If aa.bb.cc was a keypadlinc the controller record group # could range from 1-8 as appropriate but the switchlinc would always be button 1. If it was a keypadlinc instead of a switchlinc at dd.ee.ff then the button being controlled could be 1-8 (unless its a kpl6 as above) So what happens when you press the ON button on a controller with this controller record? A group command to address dd.ee.ff. will be sent from group 1 to turn button 1 on (and it's load if applicable). But in this case absolutely nothing will happen! Why? Because you haven't yet created the responder link in the dd.ee.ff device. This is an important difference between X-10 and Insteon and one worth mention. In X-10 a miscreant could plug a controller into an X-10 enabled house's outdoor outlet and start turning lights on or off. Clearly you wouldn't want to control your security system via a B-3 off! With Insteon this is not possible - you are protected - as no device in your house would have a matching responder record to the intruder's device! For additional security an Insteon device is designed to NEVER reveal its address except when placed into linking mode - which requires physical access to the switch. So your neighbors can NEVER control your Insteon devices! Insteon devices can even encrypt their data using a feature called 'extended messages' - this makes Insteon suitable for high-security applications such as door locks or security systems. So when you link devices you create the controller link in the controller link table and then you go to the responder and create the responder link to complete the linkage. I should mention that one of the benefits of ISY is that it takes care of creating both sides of the link for you - the controller record in the controller and the responder record in the responder. The responder link table looks a little different than the controller link table. It keeps the address of the device that will control it, the group of the device on the controler that will control it, the button on itself that will be controlled, the ramp rate for it to respond and the dim level for it to respond to. So... when a responder sees a group command arrive with its address as the destination it looks in its responder table for a record that matches the controlling address and controlling group and if they match it reacts by doing what it's supposed to do in that record according to the group command it receives. So how does it react to these commands? When a responder receives a fast OFF - it turns completely off instantly. When it receives a fast ON - it turns completely on to full brightness instantly. Off will turn the device off but will do so at the ramp rate specified in the responder table for that command. On will turn the device on - again at the ramp rate specified but will turn it on to the level specified in the dim level setting in the responder table. What's important here is that the controller is only sending on, fast on, off, fast off. The 'scene' type settings - the dim level and ramp rate - are stored in the responder table for the matching group command. The next important thing to understand is how Insteon sends it's commands through the network. Insteon doesn't do what X-10 did - flooding the powerline with a varying, time sensitive voltage signal. Insteon controllers send their command to the devices they know of as a binary message with specific data in it. The command is set to a 'max hops' of 3. If the destination device receives the command then it responds, acknowledges, and it's over. If not then that device will relay the command to the devices that it knows of and decrement max hops. When max hops reaches 0 that device will no longer forward the command. This is so that if you sent a command to a device that doesn't exist it would bounce infinitely around inside the network, never stopping. That would effectively ruin your network. Max hops prevents this internal reflection. You can see clearly by this 'mesh' model how having more devices and more links between them strengthens the network as there are more paths to get to each device and a greater likelihood of finding it quickly. A significant part of this communication is that when the responder finally receives the command it acknowledges it. This is something that X-10 never did. With X-10 you sent your command and prayed. Later devices let you do status checks but they were expensive and didn't work well. The controller relies on this ACK coming back. Commands that are not acknowledged cause a great deal of network performance degradation. The controller will lag and flash if it doesn't receive a prompt ACK - this signifies to you that something is wrong - and that something is usually a missing responder or responder link. Let's look at the links a little more 'visually'. Essentially in each device there are two tables that look like below. There is actually a lot more info than this but what's here will suffice for 99% of what we need to do. Note that when you see the Ramp Lvl - it's a number from 0 to 31 for a range of instantaneous to about 9 minutes. For those of you who speak binary you'll spot the 0-31 range as representing the least significant 5 bits of an 8 bit byte. The dim level is a number from 0 to 255 where 255 is full bright, 0 is full dim - again, for binary users this is an 8 bit byte. Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl So in a typical situation - say switchlinc A - device address AA.AA.AA that is linked to switchlinc B - device address BB.BB.BB you would see tables that look like this EXAMPLE 1 ------------ Device AA.AA.AA Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # 1............1.....................BB.BB.BB.............1 Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl Device BB.BB.BB Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl 1............1...................AA.AA.AA...........1...................31...............255 To complete the '3-way' control the links tables change and look like this: EXAMPLE 2 ------------ Device AA.AA.AA Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # 1............1.....................BB.BB.BB.............1 Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl 1.............1..................BB.BB.BB...........1..................31................255 Device BB.BB.BB Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # 1............1....................AA.AA.AA...............1 Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl 1............1...................AA.AA.AA...........1...................31...............255 So here we have the simplest sort of Insteon scenario. Of course many of us use KPL's to control other devices. With a KPL you start to get into the whole 'group' vs 'button' scenario. So let's see what happens when a KPL8 is used to control a switchlinc. In this scenario we'll have button C on the KPL crosslinked with a Switchlinc. The KPL will be device AA.AA.AA and the switchlinc device BB.BB.BB. Note that the controller group # for the KPL is 3 - that corresponds to button C EXAMPLE 3 ------------ Device AA.AA.AA (kpl) Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # 1............3.....................BB.BB.BB.............1 Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl 1.............3..................BB.BB.BB...........1..................31................255 Device BB.BB.BB (switchlinc) Controller links table (what I control) Link#.... My grp #......... Resp address......... Resp button # 1............1....................AA.AA.AA...............3 Responder links table (what controls me) Link#.... My btn #....... Ctrlr address....... Ctrlr Grp#.......Ramp Lvl.... Dim Lvl 1............1...................AA.AA.AA...........3...................31...............255 In KPL's there is an additional kind of link many of us use - the link WITHIN the KPL - for example using button H as an 'all off' turning off everything on the same KPL. This functionality DOES NOT look the same and DOES NOT use the controller/responder link tables. A moments thought will understand why not as NO powerline communication is necessary in this case - the device is simply talking to itself. OK... so now we have the tables - what about the command? In the above KPL example you would see a command issued when button C was pressed that contained Cntrlr Address...............Cntrlr Group #.........Destination Address......... Destination Button # AA.AA.AA........................3........................BB.BB.BB........................1 The command would get relayed through the network until a responder with a matching destination address received it. When the responder with the matching address sees the command it refers to its responder table and if it finds a match for the controller address and group # it processes the command according to the dim level and ramp rate in the matching record. Simple, right? OK - so we have the basics of insteon communication and link tables. So what, then, is a scene? Well - a scene is merely a bunch of devices that all have responder records with matching controller addresses and controller groups. This means that they are all prepared to respond to the same group command from the same controller address. The power of the scene is that because the dim level and ramp rate are set in the responder link table a single controller can turn multiple devices on to varying levels of brightness at varying rates. Very cool! But you have to remember that the devices are still simply responding to on, off, fast on, fast off. So ALL the devices in the scene will either turn on or all the devices will turn off. You don't get to mix ons and offs in one group command. This is kind of restrictive in that for most of the scenes I've ever created I've wanted some lights to turn off while others turn on and others dim. The solution to this problem is the dim level setting. Recent Insteon devices have overcome the problem of a scene ON command needing to turn things OFF by allowing a dim level near 0. When the insteon device receives an ON and its dim level is set close to zero it will turn the device so low that it appears off. Magic! Scenes can now do whatever you want! Further - because scenes respond to dim/bright commands as well you can get creative and make all the lights in a scene move up and down in unison - very cool. It's important to note, though, that you CANNOT turn off a KPL button using an ON command. Even if you set it to a low dim setting it will not work. So what is it that ISY is doing for you? Well the first thing ISY does is have you add your devices. This is a very significant part of the process and bears some analysis. When ISY adds your device you tell it the address (or put the device in linking mode). This is in keeping with what I mentioned earlier about security - ISY can't find it unless you tell it where it is or make it visible manually. You can either tell ISY what kind of device it is or let it figger it out itself by device ID and version information kept within the device. This is so that later on ISY can offer you the choices and functions relevant to your device specifically. You hit OK and ISY goes off and does some stuff. So what's it doing? Well - it's recording the info about your device into its own table. It's also creating a controller-responder link between your device and the PLM. This is of great importance as the PLM is the hub of a scene controller like ISY. So lets examine a PLM for the moment. A PLM is basically like a KPL without the ability to control anything and without any buttons. It has groups that number into the hundreds and each group has its own responder and controller link tables. Why does ISY link your device to the PLM? There are two reasons. First - a controller with no links at all sends no signals on the network. If you connect a switchlinc to your light and do not link it as a controller to another device then when you press the button on the switchlinc the light turns on and off but NO Insteon signal is sent. The device is effectively invisible to the ISY or anything else on the network. Programs based on status and control states couldn't work without being able to detect the signals. Why does it send nothing? Well - what would it send? There are no records in its controller link table! It has nothing to send to anyone so it just sits there quietly. So ISY linking your device to the PLM makes it visible on the network. Secondly - one of the key features of the ISY is to be able to know - at a glance - what devices are on or off or at what dim level. By linking each device to the PLM your ISY can be informed when the devices change by looking at only one device - the PLM. The PLM is connected to the ISY by cat5 cable so it's fast - no powerline messaging required. When the PLM link is controlled the ISY is notified and makes entries into its tables so that it 'knows' what's on, off, dim, etc. and can tell you without having to go look first Understanding this is key to understanding why you do NOT want to create links outside of ISY in your home network. Doing so will render the PLM records inaccurate and therefore your ISY info inaccurate. So always link your devices through ISY. I would wager that 99% of comments about lights turning on or off when they shouldn't are related to links created inadvertently outside of the ISY. Insteon is NOT like X-10. A device cannot respond arbitrarily. If it doesn't receive the RIGHT command from the RIGHT controller it will NOT respond. As you saw earlier the matching records have to exist. X-10 was subject to stray signals, line interference, and who knows what else. It was common to have lights turning on or off mysteriously. Not in Insteon. The other purpose of the PLM is to keep all the group responder and controller link tables as a sort of library. This allows you to create way more scenes than you have controllers and use a scene controller like ISY to manage them. What I mean by that is this. Let's say you have 20 inlinelincs and one KPL6. The most scenes you could have would be 5 - one for each button on the KPL (again, remember that the off on a KPL6 is group 1). The responder link table in all the inlinelincs would have the controller address of the kpl, and a line for each group (1,3,4,5,6) and the associated ramp/dim. Now let's say you have a PLM in the system who's device address is pp.ll.mm (yes, I know that's not hex). You could start creating responder links in your inlinelincs (using a scene controller like ISY) that respond to device pp.ll.mm group 1, 2, 113, 224...... all the way into the hundreds! Now that's flexibility! Of course you could never SEND those group commands with only a PLM as a PLM doesn't have the ability to do that. That's what a scene controller like ISY does - it CAN send the group command specifying the PLM address and group # in the controller command. So using your ISY you can now create hundreds of scenes where once you could create tens. Your scene flexibility is not limited to the number of controllers you have and that's great because who wants every switch in their house to be a KPL8? Now you can have scenes launched based on programmatic control - fast on, fast off, on during a certain time, two switches on at once, switches turned on or off in sequence - whatever you can imagine! So why does ISY treat everything as a scene? That's a common question and with the information we have now the reasons are obvious. The scene corresponds to a PLM record and the ISY only knows the status of your devices because it is informed when a PLM group changes. When it sees the change it matches the PLM change against its internal tables and you will instantly know the status of your devices. Without using the PLM linkage ISY would have no way of knowing what the status of your system was. Because Insteon commands only hop until they find their destination ISY would not be privy to every command issued on the network. Furthermore, in order to determine the status of any device without the PLM links the ISY would have to query the device each time you needed or wanted to know. This is dreadfully time consuming! Adding the PLM link causes zero degradation in your network performance and makes ISY very powerful indeed. Some other things ISY does: - It takes care of writing both sides of the controller-responder linkage for you so all you have to do is specify a controller and a responder. It also makes it a snap to 3-way the linkage by specifying both (or n) devices as controllers so their states reflect in each other. - ISY maintains all the links in its database it makes it a snap to restore a device to its appropriate link tables should you reset it for whatever reason. - ISY will do all the work of changing all the controller and responder records in all the linked devices should you change out a device. This can be a HUGE time saving for you in a heavily linked system as every single responder and controller record must be changed to reflect the address of the new device! - ISY will also take care of removing all the responder links in devices should you choose to 'break the link' - again, this is a huge time saver vs the manual method of putting your devices into unlinking mode one by one. - ISY will configure button toggle modes (which I didn't go into as this is an internal memory addressing procedure) as well as button grouping and backlighting. It keeps you from having to remember how to set each little aspect of each firmware version of each device. The way Smarthome keeps churning these things out you end up with quite a library of 'how-to's by the time you have a house full of Insteon. -ISY also makes it a snap to bring up a scene and adjust all the responder links related to a specific controller simultaneously on ONE page! and, of course, there's the programming language which allow complex device management based on multiple conditions! Well - enough for now. I'll add to this as I learn more. Hope you found something of value in here and if you have found any errors please point them out to me. Thanks!

They work great as indicators too. I have a few that flash to indicate things like garage door left open.

and bless the fine people at Universal Devices for making it so!

Programs, as you say, exist in the ISY - no ISY, no programs. Scenes do not live in the devices. Scenes live in the PLM. Devices have controller tables and responder tables in them. If A controls B then it will have a record of B as a responder in its responder link table while B will have a record of A in its controller link table. This is why reciprocal arrangements aren't automatic. It's not just a matter of 'you and I are linked'. It's a matter of I control you or I am controlled by you. If you examine the database in any insteon device it has a list of who it controls and who controls it along with associate ramp rates, dim levels, etc. Scenes work by group commands. When devices are grouped as responders to a scene then when a group on or off command is issued all devices that are in that group respond instantly. That's the biggest plus to Insteon imho - is that you can turn off literally hundreds of devices in a blink using a group command. With that said - ISY writes all the records that correspond to a scene into the appropriate devices. So say you create a scene - ISY will give it a number in the PLM - say it's group 35. ISY will then write the links to all the devices so they are responders to group 35. When you issue a group 35 on or off every device that is a responder to group 35 will respond. That's why the ISY doesn't have to be involved in scene control - scenes work with or without the ISY present. What the ISY does is tie the PLM scenes together with its own link table to give you a snapshot view of the on-off state of every device. Another thing is that every device even if NOT in a scene IS part of a scene. It's a member of group 0 of the PLM. The KPL button lights are not 'tied' as you say, to anything. They are merely responders. When you press the button on a KPLit will turn its light on or off according to it's toggle mode and send the on or off command associated with its group number. If the KPL button is a responder to a scene then when the scene is turned on or off the KPL button LED will turn on or off (or dim) accordingly. It's confoozalating, no?