MarkJames Posted February 8, 2010 Posted February 8, 2010 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!
Guest Posted February 9, 2010 Posted February 9, 2010 OK, didn't make it all the way through this yet but nice summary! You should publish a book.
Goose66 Posted February 10, 2010 Posted February 10, 2010 So if the KPL buttons are simple responders, then why can't I send them ON or OFF commands in ISY programs like I can all other devices? Is this a limitation of their "responderness," or simply an oversight in the ISY programming?
MarkJames Posted February 10, 2010 Author Posted February 10, 2010 So if the KPL buttons are simple responders, then why can't I send them ON or OFF commands in ISY programs like I can all other devices? Is this a limitation of their "responderness," or simply an oversight in the ISY programming? 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.
johnradams Posted May 13, 2010 Posted May 13, 2010 First, MarkJames, thank you very much for your excellent write-up. Your "Concept of Operation" makes things much more clear. My setup sound similar to yours: about 100 devices, multiple panels, two buildings, and two completely separate electrical meters -- I rely on the RF of Access Points to bridge the two systems. So here's my question: I am pretty sure that the link information stored in the devices does not exactly match the link information known to ISY. This may be in part due to my earlier use of SmartLinc2. The result is apparent gremlins in my system -- last week, for no apparent reason, and without making any changes that I recall, the lights in my office began blinking every few hours. I recall reading somewhere in the forums about identifying differences between the device link tables and those known to ISY. Is there some way to start some massive "scan" of all devices known to ISY, and (a) compare the device links to what is known to ISY, and ( optionally force the device links to match those in ISY? I like the idea of being able to first review what is going on before having ISY go and "fix" the bad links. BTW, I understand that I will "lose" any useful links that are in the devices, but not known to ISY -- but I don't mind, as I really want my devices to reflect what ISY is managing (and can thus be documented, backed-up, etc.). I have read that these sorts of bogus links in devices account for some degree of unreliability (due to excessive bogus traffic), especially in large systems, so I am hopeful that my system will perform better overall after the cleanup is done. Finally, if anyone from UDI is reading this far, it would be very helpful if someone would expand the ISY documentation to include cleanly written examples, tutorials, etc. I see that the forum and the wiki do include a number of examples. But sometimes an "example" in a forum ends up being a thread, with all sorts of fix, improvements, etc. The history is useful and worthy, but it would be great if a final summary was included in the standard doc (either the PDF, the wiki, or even a sticky part of the forum). For example, the Concept of Operation offered by MarkJames should absolutely be included as some sort of reference material. I wish I had blundered upon it months ago. Not only would it have saved me time, but I would have bugged UDI tech support less. Another example: I asked UDI tech support for help with the programs and KPL configuration so that I could use a KPL to track the status of multiple scenes in a room. The goal is to allow me to turn on/off lights (on a room-by-room basis; each room has several scenes) when the kids leave the lights on downstairs. It took about 10 email exchanges before the kinks got worked out. I assert that the final example should be included in the wiki or forum, as a "supported" or otherwise clearly described example. Requiring your customers to each individually build a knowledge base is too much work, and a waste of people's time and effort. Thanks again to my hero of the day, MarkJames.
MarkJames Posted May 13, 2010 Author Posted May 13, 2010 There is no way to en-masse restore all the links in your system afaik. There's a couple of things you should keep in mind here, though. First - if your lights were flashing then knowing what we know about Insteon we can be certain that something within your own system was telling them to do so. Flashing can only be accomplished by programmatic control so that would be a starting point to troubleshoot that problem. Switching from software to software is a big PITA. I've switched from Insteon with x-10 addresses controlled by Stargate to Houselinc to Powerhome, to ISY and have had to troubleshoot the weirdnesses each time so I consider myself well experienced in this arena. The first thing you should know is if you go to Tools->diagnostics->device links you can read all the links in a device. There's then a compare button which will compare your links to the ISY table. They should read identical all the way down with an ignore at the bottom. If they don't then before you perform a restore on the device you'll want to make sure you have no comm problems. Be sure to let the read links routine run right to the end or you'll get a weird compare result. Working across multiple panels by RF can be difficult - I'd start by picking a simple switch with few links that's on the 'other' panel from your ISY and see if ISY communicates properly with it. If not you'll have to work on this problem first. Next - make sure you don't have any stray X-10 addresses left in your system if you were using X-10 before. X-10 isn't as robust or secure as Insteon so it's possible to get lights flashing and general weirdness if someone in your area has X-10 with the same house/unit addresses or, from what I've seen with X-10, you can get weirdness just because it feels like it. Then make sure you don't have programs doing things that you've forgotten about. Try and troubleshoot light by light and search for programs that are controlling that light. Insteon can't just 'turn on' by itself. The controller-responder link must match so you can be certain that if it's turned on or off then somehow, somewhere, you've told it to. Finally, if your device tables don't match you can hard reset them and restore them or simply rightclick the device and hit restore on it from the main screen. The latter is preferable as the former will kick your 6 or 8 button KPLs into their default which you may have changed. Restore will delete links that don't exist in the ISY table and rewrite the links that do. ISY will warn you that you'll need to have your RF devices that are linked to the hardwired devices in link mode when you do this but I've not found it necessary. I'd check after a restore with the diagnostic routine to make sure you got what you expected and now everything is identical. If you can't successfully perform a restore followed by a device link diagnostic that matches up then something is amiss with your communications. Lots of devices makes things better, not worse - so long as you don't max our your PLM. Lots of access points make things worse, not better, imho. The only err msgs I get pop in ISY is from my RF devices as they asynchronously communicate through multiple access points. Multiple panels is no big deal but I would definitely use the 2406h hardwired signal bridges in each panel - it may be overkill to use more than one but they're cheap and easy to install. Multiple METERS is hard and can only be done RF unless one meter feeds the other meter (as in a deducting system). Insteon seems to make it through the meter but you'll always want to be thinking FIRST about your communications whenever you do anything to your system. With multiple meters you can do it - I've done it - but every so often I'll change something and it will stop working properly and I have to go back and figure out what I've changed. Finally finally (oops), run the diagnostics on your PLM and make sure you don't have something funny going on with it. Your device count should be less (much less, hopefully) than 1024 If none of that helps, post back to the forum. The ISY users are the most helpful and knowledgeable of any I've ever encountered anywhere and the support from the UDI tech guys has got to be the best in the business. I saw that you had a bit of a time there with a previous problem but bear in mind that the last few months has seen some 24/7 coding/troubleshooting by the UDI gurus as they struggled to get the now stable 2.7.15 firmware out for us. mark
Michel Kohanim Posted May 13, 2010 Posted May 13, 2010 Hi johnradams, I did read your whole post ... I agree with you about the documentation and, as I had mentioned to you on our email exchange, we are working on it. The process is rather slow. MarkJames, I want to thank you as well. With kind regards, Michel
johnradams Posted May 13, 2010 Posted May 13, 2010 MarkJames, Thanks for the suggestions. I agree with you that somewhere, somehow my system has gotten slightly munged. I recently changed out about a dozen devices, and it probably happened during this process. I thought I did everything cleanly, but I guess not. I think I have exactly one old X-10 device, which I will eliminate ASAP. I have 2406H devices next to every panel, so I've got this covered. I am guilty of "too many" Access Points (I lost count, but have at least 10, as suggested by SmartHome), and will trim that down a bit. I guess I really only need them at the two places where I am jumping from one building to the next (and which is where we are "jumping" from one electrical system to another, using completely distinct feeds from the local power company). All the above being said, I think that I do need a few "extra" Access Points to ensure good signal transfer between some of the panels which are somewhat electrically distinct. By "somewhat electrically distinct", I refer to panels that are separated by a transfer switch for the generator. What tools are available to track the signal flow in the system, especially across Access Points? Can/should I add Access Points to my ISY configuration? Will their status be reported in the ISY UI? The idea of going through each device, one-at-a-time, and checking the device link tables against the ISY link tables is the kind of thing that computers a good at Folks at DUI, any plans to have the ISY software do this sort of thing? It would a great way to verify that a system is configured as expected. And seems like it could save your customers, and your your tech staff, many hours of debugging. At this point, I have only a few simple programs; I have held off on doing the cool/fun stuff until my system is more reliable. Reliability first, features second. Michel, Thanks as always for listening. I really think that UDI would be well-served by spending X hours on doc, thus answering many questions with a broad brush. And saving 25*X hours in one-on-one support handling. Getting the doc right is a "highly leveraged" activity, and would save UDI staff (as well as your customers!) many hours.
MarkJames Posted May 13, 2010 Author Posted May 13, 2010 All the above being said, I think that I do need a few "extra" Access Points to ensure good signal transfer between some of the panels which are somewhat electrically distinct. By "somewhat electrically distinct", I refer to panels that are separated by a transfer switch for the generator. I agree with you. Access points seem to have a variable range that depends very much on line of sight. I would tend to put one in each building that are electrically separate as close to each other as possible and then let the signal bridge do its job. What tools are available to track the signal flow in the system, especially across Access Points? Can/should I add Access Points to my ISY configuration? Will their status be reported in the ISY UI? access points, afaik, do not 'talk' on the network. They merely act as any other hardwired device relaying the insteon messages through the network. Of course, they also inject signals from RF devices and other APs as well. There are no communication analyzers for Insteon that I've found. X-10 had them but that was a different scenario as X-10 signal strength was something you could measure in mV. Insteon talks digitally so a comm analyzer wouldn't know much about the signal other than whether it's there or not. The idea of going through each device, one-at-a-time, and checking the device link tables against the ISY link tables is the kind of thing that computers a good at Folks at DUI, any plans to have the ISY software do this sort of thing? It would a great way to verify that a system is configured as expected. And seems like it could save your customers, and your your tech staff, many hours of debugging. I've wanted a report like this myself but bear in mind that it's not that simple... it would have to be a fairly comprehensive report that would need to reference each device, its memberships, whether its linked membership exists in its paired device, and so on. In a complex network I betcha it would take it the better part of 24hrs to run. Docs are always a problem when you're on the bleeding edge. No sooner something is documented it's obsolete. The forum is probably your best friend for that as I've never come up short asking a question here. hope that helps, mark
johnradams Posted May 14, 2010 Posted May 14, 2010 I've wanted a report like this myself but bear in mind that it's not that simple... it would have to be a fairly comprehensive report that would need to reference each device, its memberships, whether its linked membership exists in its paired device, and so on. In a complex network I betcha it would take it the better part of 24hrs to run. Yes, it would involve a lot of gathering status, then doing a lot of cross-referencing to see what, if anything, is amiss. Somewhat like running fsck or chkdsk, where you determine if the number of references to each disk block is correct, that there are no "orphaned" blocks. etc. As you suggest, it gets quite involved, and might take quite a while to run -- which is why I want the computer to do all of that for me As far as docs, I am suggesting that a longish thread can be properly summarized/edited, and made into a single coherent piece. Much like what you did with the Concept of Operation (hope you don't mind my giving it that title). Didn't you edit it 6 times to get it right? Proves my point. Your piece is MUCH more readable and organized than some long thread with dozens of comments, corrections, etc. Having a single coherent piece saves everyone the trouble of figuring the lengthy thread on their own. Speaking of edits to your doc, you mentioned that the PLM is connected to the ISY via CAT5. While the wire may well be CAT5, I think the communication protocol is RS-232. While a far cry from 10 Mbps Ethernet (or faster), the serial link (19.2 Kbps?) is cleaner and more reliable than Insteon's over-the-wire signaling. Thanks again for your insights. I now have renewed enthusiasm for my Insteon/ISY system!
Michel Kohanim Posted May 14, 2010 Posted May 14, 2010 johnradams, My pleasure ... I totally agree with you. The process of culling out everything from the from and condense into Wiki is a good idea and we are working on it. As far as a system wide Compare, I think that's a good idea as well. With kind regards, Michel
johnradams Posted May 14, 2010 Posted May 14, 2010 Thanks as always, Michel, for listening. I realize that you must have a feature and bug list a mile long. But I respectfully suggest that having the ability to gather all device link data would be very useful, and might save UDI staff -- and customers -- LOTS of debugging. I am very keen on using the current Topology report to review my system. I now realize, of course, that this report describes only what ISY knows about. The topology report is not based on actual device link info -- yet it is the device link info that controls what the devices are actually configured to do. The existing UI function: Tools->Diagnostics->Show Device Links Table is somewhat tedious; it requires GUI interaction for each device, shows only the hex detail, etc. Could you consider at least taking "baby steps" towards a full-blown system-wide Compare function? For example, a very nice baby step would be to simply cycle through all device known to ISY, and read the link tables, and display them something like this: aa.bb.cc (Foyer Dimmer) --------------------------------------------------------------------------- Controllers | Responders --------------------------------------------------------------------------- hex dump device name | hex dump device name --------------------------------------------------------------------------- Wow. Such a report would allow people to review and essentially do a "visual compare" (hey -- the Foyer dimmer is controlling the lamp in the bedroom!?!). And for those that care, the hex dump is right there for diagnostic purposes. Assuming the report is HTML, the table cells could each use their own CSS class, so people could make the hex dump invisible if/as desired. For those who don't realize this, you can tweak the appearance of the existing Topology report by editing the CSS declarations in the HTML file; very handy. The above report would not perform any sort of cross-checking; such cross-checking and what-not can get quite involved as you try to keep everything in memory, etc. It is much easier to simply walk the ISY device list and dump them one at a time. Perhaps the UI could allow the user to do this on a folder basis, so that one can get the details for just one folder that contains devices that are "misbehaving". Especially useful for checking a few devices without having to wait for *all* devices to be queried. It is noted that such a report, might well reveal devices not known to ISY, which is not a problem -- that is in fact a help, and the user could then remove these "orphan" links. Anyway, I am hoping/asserting that a simple "dump" tool would be: (a) a very valuable and useful debugging tool, and ( far simpler to implement than a full-blown link analysis tool that attempts to reconcile all devices by examining all of the link details simultaneously. Based on my understanding of the link table structure, it seems to me that the above report would give anyone pretty much all the information they might ever need to review a system, and confirm that their actual devices match their ISY configuration. I suppose minor (future) enhancements could include further decoding of the hex values, perhaps especially to show the dim rates. And of course, once people start discovering a bunch of orphaned or otherwise bogus links, then your users will want a nice UI function to clear out such links. No rest for the weary, right? Thanks as always for your consideration. MarkJames, your suggestions?
MarkJames Posted May 14, 2010 Author Posted May 14, 2010 Have you looked at the topology report? It does most of what you've described, I think.
johnradams Posted May 14, 2010 Posted May 14, 2010 Have you looked at the topology report? Unless I am mistaken, the Topology report only lists what ISY knows about, and it is implicitly assumed that the information in the devices matches the information maintained and believed by ISY. Which is a significant issue, raised by you and others: if the actual device links don't match what ISY knows about, then your system will have problems. What I am proposing is a report that lists the link tables in the devices (and, to the extent that the device entries are "known" to ISY, displays the human-friendly device names). Make sense?
Michel Kohanim Posted May 15, 2010 Posted May 15, 2010 Hello johnradams, We would surely consider such a report. The only thing that I wonder is why one does not use Restore Device to fix the issues? i.e. if you have devices that respond to unintended controllers, then you should restore the responder first and the controller second. This guarantees ISY and the devices will be in synch. And, it takes the same amount of time (+ a few minutes) to restore your whole network instead of creating a report and then sifting through it, and trying to make sense out of it. Obviously, neither method would work if you have crawled your network and ISY brought in links from other PLMs (such as those from HouseLinc). In that case, the report is not going to work either since ISY does not know about that device. With kind regards, Michel
MarkJames Posted May 15, 2010 Author Posted May 15, 2010 I've contemplated the benefits of systemwide restore numerous times and have felt like I would have benefitted from it. In retrospect, though, doing a systemwide restore would only benefit me if I knew for sure that there were no comm issues. In the presence of comm issues - which seems to be the #1 source of trouble for Insteon systems - you can't be sure that the restore gave you anything better than you had prior. While the ISY can confirm with an ACK that the write happened, it can't confirm that it deleted something that wasn't supposed to be there in the first place - you'd have to do a hard reset on the device to guarantee that and hard resets have their own problems (6 vs 8, grouping, toggle mode). I liken it to adding whacks of devices to a scene at once. If an error occurs you generally get the 101 write error messages (in recent versions, anyways - which is far improved from earlier ones). With comm errors those 101's can be a real pain to get rid of. It's really best to add 5 or 10 devices at a time to a scene. Trying to rewrite every link at once in an entire system is probably not practical Anyways.... not to denigrate the idea as on its face it has merit - just having gone down this road numerous times I can tell you from experience that your best bet is to simply do a restore on a device that's not doing what's expected - or restore the link between a device and scene if that is more appropriate.
johnradams Posted May 18, 2010 Posted May 18, 2010 And, it takes the same amount of time (+ a few minutes) to restore your whole network instead of creating a report and then sifting through it, and trying to make sense out of it. Well said -- I'm not looking to create work! However, I seem to be facing a disconnect between what I understand is essentially three databases: (a) the set of links found in each and every Insteon device's link tables ( the links found in the PLM © the device names, descriptions, and link knowledge maintained in the ISY application Although I am probably misstating something, what I seem to have encountered is that my ISY software knows about a PLM that is no longer in use on my Insteon network (I used it when I was using HouseLinc2 to try and diagnose comm failures). Links to/from this unused PLM continue to appear in device link tables, even after doing a device restore. The PLM device in question does not appear in the left-hand pane of the UI, but does appear in the Topology report. So my problem seems to be that ISY knows about a device, but is unable to communicate with it. And the philosophy of the ISY software appears to be "don't delete references to a device just because communication is failing". In this case, however, I *know* that the device is no longer in use, and I want to completely remove all knowledge of this device from devices, the PLM, and ISY. I suppose that what I need to be able to do is: (a) delete all references to this device in the ISY software/database, then ( cause all device link tables to reflect this change. Although the abandoned Insteon device in this case happens to be the PLM that I used with HouseLinc2, there may well be other abandoned Insteon devices that I want to purge from the system. In general, what is challenging me is knowing what is in the device link tables, versus what is in the PLM that ISY is using, versus what is "known" to ISY. And making sure that they all reconcile. In a consistent, verifiable, and reproducible fashion. Am I missing something? Thanks.
Michel Kohanim Posted May 18, 2010 Posted May 18, 2010 Hello johradams, First of all, it would be an impossibility (or a bug) if your topology shows a device that is NOT listed as a node. As such, please do be kind enough to click on My Network, sort the table by Address and then let me know if your device shows up in the table. Once we know the answer to this then we'll find the best course of action. As far as your other comments: 1. You are correct: ISY configuration, PLM configuration, and Device configuration are three separate entities that ISY tries to synch/manage 2. ISY does not automatically discard devices that cannot be communicated with 3. Your configuration right now includes the configuration from crawling your network + additions done via ISY With kind regards, Michel
johnradams Posted May 18, 2010 Posted May 18, 2010 Here is a recent Topology report: http://adamsj.com/udi/topology.v2.7.15__2010-05-18.10.29.44.html You will see an entry (in bold) for a PLM device with address 0D.D8.82.1 which is marked as "Unsupported Device:3.19". I put part of the line in bold to make it easier to find. Here is a (partial) screenshot of the ISY GUI, sorted by device address: http://adamsj.com/udi/Capture-05-18-00001.png You will see that the mysterious PLM device does not appear in the list of "known devices". It should appear near the cursor. In summary, at least these two "databases" are not properly reconciled. It would seem that this may well explain why performing a "device restore" does not remove the obsolete entries from the device link tables. And may well explain other oddities. I very much like the idea that the ISY software controls and maintains the authoritative list of links. This allows one to backup, manage, review, print, display, and otherwise manipulate the myriad of links in an Insteon network. Without ISY, it would be a nightmare to try and keep track of what is where! If you wish to login to my system, please email me and I will reply with the URL and password. Thanks, john
Michel Kohanim Posted May 18, 2010 Posted May 18, 2010 Hello johnradams, I got your email and link to your system. I stand corrected, ISY does NOT show Unsupported Bridge devices (i.e. PLM). I sent you an email ... perhaps we can fix it remotely. With kind regards, Michel
Teken Posted December 12, 2010 Posted December 12, 2010 MarkJames, If I had read this thread a year ago a lot of things would have been so much clearier !!! Much thanks for taking the time to share your personal experience and knowledge with us all . . .
porscheguy Posted February 6, 2011 Posted February 6, 2011 I am really new to the ISY and I wish that UDI would not only listen to comments in this and other threads that request increased documentation and examples for the ISY operation, but would do so in an incremental and timely manner when good solid points or examples are provided. I read where UDI is "working on it" in posts over a long time frame but I'm not sure when things actually find their way into the isy99_userguide. As a new user, the isy99_userguide is the first place I looked for learning how to use the ISY but found it insufficient to understand the subtleties of the ISY and the Insteon network. I really appreciate the posts by MarkJames and JohnRAdams in this Thread, and also the comments by Michel. These are helping me a great deal. But I am very irritated (sorry Michel) that I have to wade and crawl through the forum to find some light to illuminate the tunnel in trying to understand the idiosyncracies of the ISY, Insteon and the ISY programming. The editing by MarkJames is very much appreciated as he improves and corrects his Post and the fact that this Thread is a sticky one does help, but somehow more meat needs to get into the isy99_userguide so one can progress further from that document before wading into the forums. Appendices that contain MarkJames' and others' posts would be one way. I'm so new to the ISY that I haven't implemented my system yet because I don't want to leave a working hybrid X-10/Insteon system and implement an ISY/Insteon-only system until I understand better how to do it. This Thread has been a big help. Somehow the really good posts need to be brought together. Thanks again for the posts.
oberkc Posted February 6, 2011 Posted February 6, 2011 I'm so new to the ISY that I haven't implemented my system yet because I don't want to leave a working hybrid X-10/Insteon system and implement an ISY/Insteon-only system until I understand better how to do it. In case you did not know, the ISY supports X-10 also. There is little reason to abandon your X-10 equipment if it is otherwise working. My perception is that many folks around here still use X-10 to some degree.
art Posted February 23, 2011 Posted February 23, 2011 Echoing oberkc Not being monetarily endowed myself, I can't afford to convert everything to Insteon. Espeicially with spontaneous (chicken brooder) or seansonal (Christmas) needs, I find it convenient to dig in my X10 box of goodies to grab a module. I am even too cheap to buy the ISY's X10 module and still it functions quite adequately with my X10/Insteon hybrid system. Trust me, the ISY will breathe new life into your hybrid system and you'll wonder why you didn't start playing sooner!
Brian H Posted February 24, 2011 Posted February 24, 2011 I still have some X10 modules in my setup. There is still no Insteon replacement for a Chime Module. No Insteon remote with 16 separate addresses either. Some of my Insteon modules still have an added X10 address just so I can use the HR12A Palm pad remotes. MY ISY99i has no problems sounding my chimes when it is time to get up. Some users have fond that as more Insteon devices are added. They get more reliable and their X10 gets touchier.
Recommended Posts