MarkJames

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?

ahh... I gotcha - I misunderstood what you meant. So in an example scene Switch A is a controller (non load) Switch B is in the scene as responder (load) When you turn A on and off B will turn on and off When you turn B on or off it will have no effect on A In a second example scene Switch A is a controlller (non load) Switch B is a controller (load) A on or off will reflect in B B on or off will reflect in A What you were referring to was the responder link in the controller - not the reciprocal arrangement in a crosslinked 3 or n way relationship. I only point this out because when I first got my ISY I came from a powerhome background where you had to write the responder and controller links manually. The first scene I created in ISY worked in a proper crosslinked manner even though one was a controller and one was a responder - this wasn't because ISY did it - it was because I had left over links from powerhome. It confused the bejesus outta me cuz I thought ISY was creating reciprocal links and I was afraid I wouldn't be able to control things in one direction only. Once I reset the switch and wrote only the ISY links to it it then worked as I would have expected. Took me a week or two of scratching my head to figure that one out and I bet I'm not the only one who's come to ISY with a bunch of already crosslinked switches that wondered why they stopped working when the devices got rewritten by ISY with the actual scenes. It becomes far more apparent with items that can ONLY be controllers or ONLY be responders. mark

I'm not sure that's true. You can make a kpl a controller without it being a responder too (I'm fairly certain). To crosslink you must make them both controllers. I may be wrong so don't throw things at me if I am

I think the part that gets confusing for people starting in ISY - I know it was for me - is the conceptual part of any button only being able to be a controller of one 'scene' though it can be a responder to many. In a typical cross-link between two buttons you just make both controllers - A will turn B on and off, B will turn A on and off. If you make A a controller and B a responder then A will turn B on but B will not turn A on. This is exactly what happens if you manually link two switches too. You must make B a controller of A in order for B and A to 'jive'. In the case of a KPL-6 the primary button is always the Load - so turning it on or off will always turn the load on or off - you can't control the light without controlling the load. You can fool this in a KPL-8, though, by turning the switch upside down - effectively making the load button H instead of button A. This is a useful technique in some situations and you barely notice the little plastic tab on the wrong side. The one button being only one controller gets conceptually difficult when you want to put that button in multiple scenes - but when you think deeper it only makes sense. Turning any one button on will ALWAY turn on everything that is in that scene - so clearly any one button can only be a controller of one 'scene' regardless of how many different things are happening. However any number of things can turn that button on or off so it can be a responder of as many scenes as its link table will allow (over 400, I think) It gets a little more difficult if you have one switch turn on two separate lights that each have their own switches. It's easy to turn them both on by making A a controller of B and C but clearly you don't want B and C to be controllers of A because then if either B OR C turned off A would turn off despite the other being on. In this scenario you have to use a program that monitors a status change to B and C and make A match when B and C match - if B is OFF and C is OFF then turn A off. As for your question, Steve, about sending an insteon command to turn the KPL button on that is, indeed, possible, and is, indeed what ISY does - it just keeps the links in the PLM so that it can keep track readily of what is on and what is off instantaneously. Without this system the ISY would continuously have to poll each device in order to determine if it is on or off - and THAT is a huge amount of unnecessary insteon traffic. Dunno if that helps but there ya go.

In 2.7.10 you can add a device with the same name as an existing device. I did this with a KPL and then subsequently tried to rename the new KPL - but ended up changing names on both kpl-s when answering 'change names on all associate devices' (I assumed this means all the buttons on the same KPL)

Interesting.... I did a hard reset and now I'm trying to restore a select device or two just to see if it does anything. The event viewer shows activity and it looks to the uneducated observer like it always did. A series of INST-ACK then INST-SRX then Standard Direct Ack as it restores the device. Quite a coincidence it died just as I added the remotelinc. Well - if it doesn't work I'll try and get a 2413. I was just logging on here to see if you support that yet. Thanks for your help, mark

Michel, I didn't add an access point or move any. I think I made an error, though, while adding the remotelinc. The ISY software didn't indicate to me how to put the remotelinc into programming mode when adding it nor did the remotelinc manual. So I pressed and held the 1 button to put that into linking mode. The ISY seemed happy to write but it wrote for probably 15 minutes. Not having added a remotelinc before it seemed odd but I left it go. Now there are two KPL's which originally controlled all the different lights in the kitchen and surrounding area that are completely messed up. I've hard reset them and restored them but when I do a compare I find them full of missing records. I restored my backup from a few days ago - prior to the update to 2.7.10 and didn't read your post until after I started a full housewide restore going. As you know, I have a LOT of devices so it's been running for some time and will probably go all night. I've also restored my PLM in an attempt to make everything congruous. At this point I'll phone in to tech support in the morning and see if you can dial in and check this out. I can't even control the KPL from the admin console now. I have buttons that are members of scenes and I can turn the scenes on and off from admin console - the controlled lights go on and off but the buttons on the KPL don't do anything. Wow... this got really whacky. mark

wow! Something REALLY crappy just happened. I just got my first remotelinc and installed it. The installation ran for what seemed like an age. Now that it's done I can no longer control ANY of the lights in the room that the remotelinc was set to control just one of the lights in. I can't even restore it the KPL it should have linked to. I can't tell you if this is 2.7.10 or what as this is my first remotelinc. I'm going to play for a while but I've tried restoring the devices or restoring the links between the light and the controller - neither works. I may have to go back to a backup mark

Sorry.... I don't use an IRlinc so I didn't know. I feed my IR signals directly from an IR panel into the ISY.

I'm not fluent with the IR section yet - it's on my todo list. But all I did was created a folder in the program section called IR commands and then created a series of programs that respond to the button presses. If irbutton_fireplace_on pressed then turn scene fireplace on Like that. It actually happens remarkably quickly. The IR programs work very well. I notice no lag at all. mark

I've only done a bit with my universal remote through ISY but I didn't see any way to add the remote buttons to the Admin console. I found them all available in the programming section, though. It'd be cool if you could access them from admin, mind you. mark

like oberkc said... take a look at your access points too. I have some that have addresses on them and others that do not. I betcha he's right - it's probably an access point ID.

Yeah - I don't know why that happens - I've had it in some of my devices too. I think it's a bad write or something - one of the advanced guys around here will probably know. Are you sure it's not the address of your PLM or a motion sensor? The extra record only matters if you try to communicate with a device of that number. If it does then your system performance will degrade as insteon tries to talk to it but can't find it. Sort of like if you have a bunch of switches in your house and you airgap them to turn them off. Or if you remove devices and don't tell ISY and your PLM. You'll probably never notice this one. I wouldn't worry about it unless you notice odd behavior. mark

I believe the problem with the backup is that it restores your ISY database but I don't think it restores all your devices. Check in your ISY that your device has the proper managed by/manages links, then hard reset the device and restore it. That will clear all the unnecessary links and write all the proper links. You'll probably have to do this with all the devices that have responder or controller links now that shouldn't. The key to understanding it is that ISY keeps a table of what 'should' be there - what it has put there - but you can accidentally or intentionally change that in the devices. You also have to remember that everything insteon does requires both a controller record and a responder record. If you simply delete the controller record but not the responder record then the next time the controller sends a message the responder will still turn on. Conversely if you remove the responder record you can hit the controller all you like but the responder won't do anything. If ISY and the device don't have identical tables (and you can check using diagnostics->device links->compare then you won't get the result you expect. At that point it's easiest to do a 'restore device' mark

Thank you for the fix to my system, Michel. Things are working much more smoothly now. Brilliant bit of troubleshooting - finding that a bad signalinc was the problem - not the ISY. mark

deleted - just read the part you wrote above about mail errors

[deleted]

The links were all created prior to 2.7.9, though they were all rewritten as part of a restore WITH 2.7.9 - so I guess for your purposes the answer would be yes - they were written with 2.7.9 When I switched to 2.7.10 yes - I hard reset and performed a restore I've attached the entire event view of the attempt to restore with 2.7.10 that ends with 'fail to write device link' below. Sorry if there's extra information there - my lunch was burning and when I came back it had already finished so there may be some extra lines.

Something is up with the KPL link writing in this version. I have two KPL's that have not caused me any trouble so far. In this version I get 'failed to write device link' and 'failed to read device link' on them. I just finished removing all the scene memberships from one in the hope that it may be something was corrupt. But now with that one gone it's simply moved the issue to another one. I don't want to keep removing all my links. I've hard reset the KPL's several times and now I've removed one from ISY and am trying to add it back in but the add device routine runs way too long - as if it was having trouble finding the device - then it added a scene by the name that I gave the device and didn't add the device at all. The one that the problem 'moved to' now has 'writing' icons attached but it won't write. I've tried hitting 'write updates' but I get the 'failed to write device link' error which I didn't get yesterday. I've tried a restore on this one but all I get it a bunch of 1011 icons attached and when I try to write the updates I get the 'failed to write' error again. I suppose it could be these KPL's but it seems a bit suspect. mark

I love the little green icons telling me what's writing, what's written, and what's failed to write! I would, however, prefer the icons to be different colors rather than the numbers that are in the boxes - I can't read them very well. mark