yardman 49

Hello Chris: Just another data point: this morning my "outside lights off" program did not run (for the first time) under 2.4.15. It did not run even though I use the "random" feature as follows" **************************** If Time is Sunrise - 10 minutes Then Wait 20 minutes (Random) Set 'Hall KPL A - Porch Light' Off etc, etc...... **************************** Is this the same bug? I didn't think that it would effect schedules where the "random" setting was used. But maybe it already has the "random" start time calculated, and if it's busy at that "randomly" selectetd time then the same bug occurs. If so, how do I write the random programs to make certain that they are reliable until you produce the next beta drop? Thanks

Hello Mike: I really like to way you optimized your programs. I had also come to the same conclusions: For point #2, that is exactly what I did for my program, for the same reason: if a light is dimmed, it really is not "on", but neither is it off. So I used ">OFF", rather than ON. And for point #1, I took the same approach: only the load controlling devices need be included foir monitoring. The moment they get turned on by another controller, then their status gets read back to the ISY as ">OFF" (or "ON" for a Togglelinc) and thus the program runs anyway since it sees that the load device has switched on. Best wishes

i gotta write that on a postit note That's the reason that only one "on" command has to be issued from a controller, and then everything flagged as a responder will turn on. I guess that keeps traffic down on the network, since a controller doesn't need to send out discrete commands to every device that it controls. Sort of like "X10" but with discrete addresses rather than house codes, which then allows devices to belong to multiple groups. Pretty cool. On the ISY, what I find to be pretty cool is the way that the ISY doesn't have to keep polling the network for device states. Rather, it remembers the last state, and then in the case of a power failure or reboot, it does an entire network state query. This seems to be the best compromise, and again helps to keep network traffic down, which neither Insteon nor X10 seem to like very much. I guess that means that Insteon is not a full duplex protocol.

Hello Chris: Yes, that's a very important point. I tend to forget that and automatically assume that it's the controller. Thank you!

Hello Chris: You wrote: No, actually I have never used that option! That's what is confusing me. I've never used "Keep existing links". When I first started experimenting with the ISY a couple of weeks back or more, I one time used the "Add Devices found in Links and remove existing links". I only did that once, and since then have done another factory reset on that device. Every time I've added that device back in again I've used "Remove Existing Links". All other times I've added devices, I've used "Remove Existing Links" without exception.

Hello all: Here is some information for those of you who create scenes through the ISY where the load (primary) and the secondary buttons from the same KPL are included in a scene as Responders. These are dictated by the way that the KPLs have been designed. We don't know yet if any of this will change with the release of the new version 1.5 KPLs: *************************** 1)- KPL A button must always be added last when adding primary and secondaries to a scene as Responders, otherwise the secondaries won’t backlight. 2)- If more secondaries are added to a scene after the primary has been added as a Responder, then the primary must be removed and added back in again to enable the secondary backlights. Otherwise, all of the secondaries on that KPL may then fail to backlight. 3)- If another device is added as an additional Controller to a scene, then the Responder KPL A’s must be removed from the scene, and then added back in again to enable the secondary backlights. Otherwise, all of the secondaries on that KPL may then fail to backlight. *************************** This can be a huge inconvenience when modifying or adding to existing scenes, especially when multiple KPLs are used in a scene. But unfortunately, that how the KPLs work at this present time.

Hello all: I know that I have spoken with Michel about this in the past, but I'm not certain what the correct answer is for revision 2.4.15 to this question: When either a "Restore Device" or Restore (all) Devices" is done, should this overwrite all links in the device link database, including ones created "manually" at the switch? Because if it is supposed to, then I think that I have found that it doesn't. Manual links persist. Of course, if it doesn't, then it's working as planned. However, the third option is that when a device is added that has manual links, that those links are saved to the ISY, but not "shown" in the GUI. Therefore, Restoring a device would then push the same "hidden" links back to the device. Thanks

Chris & Michel: Is it possible by looking at the GUI or doing a shell command to determine which PLM that the ISY "thinks" that it is connected to? Thanks

Mike: That looks to me like it should work. I used the parentheticals already in one program and they worked as expected. Best wishes,

Hello Michel: Just to add to the sentiments of others, I would like to thank you for holding your price for us! Although the ISY-26 is not yet "perfected", it gets better with every beta upgrade. And hopefully your sales volume will increase so substantially it will really help you to gain more leverage with SH so that they can continue to improve the PLM product, which can't do anything but help everyone that uses the PLM. I still think that the PLM is the "weak link" right now and is need of better "ears". Any hope that SH will eventually license you to come up with your own version of the PLM?? Or at least that they could make one for you to your specifications?? I would like to say that a great by-product of moving my system to the ISY-26 is that I seem to have a much better understanding of how Insteon works, even though I've never studied the protocol. I guess that the way that you've designed the product to be so faithful to the original protocol helps me to better understand how it works. Or at least it seems that way. I think that aspect will also make it much easier for me to teach to others. Best wishes,

Hello Michel and everyone: I have a KPL that I would like to try replacing. I'm concerned about what will happen with scenes that have the KPL "A" load button included. This is because of the limitation of the KPL, where any scene that includes the secondary buttons as well as the "A" button must have the "A" button added last, or the secondary button backlights won't work properly. So if I do the "Replace with..." function, will this preserve the proper order of the links in the table, such that all of the buttons in scenes backlight properly on the replacement device? Thanks

Hello Chris & Michel: Thanks so much for taking the issues that we see seriously, and acting on them so quickly! In the meantime, should we go back to 2.4.13, or is the next revision drop imminent? Best wishes,

Hello guys: On my post regarding 'Pessimistic "Restore Devices" Progress Bar' the way that I corrupted my network and had to resort to "Restore Devices" was to use the "Remove PLM" command I didn't explain that previously, so in light of the current thread, I figured that I should explain the reason Best wishes,

Hello Rand: What you describe is exactly the behavior that I have seen. But I had seen a communication from SmartHome that said otherwise. It said that "the device would stay awake for 4 minutes from the last message received". So I just wanted to see if we all were having the same experience. As you have said, restarting the linking mode will add another 4 minutes. Thankfully UD has designed the ISY so that it doesn't give up too quickly when writing to the RemoteLinc. I not surprised about this discrepancy in what SH says and what actually happens. I've seen a few times now when they don't even have their own linking instructions on their other devices documented properly. For instance, for the KPL the PDF instruction manual will say to hold the button for 10 seconds to go into linking mode, release, and then hold for another 10 seconds to enter unlinking mode. In reality it will maybe be only another 3 to 5 seconds to enter unlinking mode. This is also true for some other devices.

Hello all RemoteLinc users: I've seen information from SmartHome that suggests that once the RemoteLinc is put into "communication mode" (by holding down the Dim and Bright buttons for more that 10 seconds) that it should stay in that mode longer than 4 minutes, as long as it receives a message in that time period. I have not experienced this desired behavior. If I put my RL into comm mode, it only seems to stay there for 4 minutes, even if it is in the middle of being programmed by the ISY. What sayeth ye? Does anyone see the RL stay in comm mode more than 4 minutes when linking devices through the ISY, or when doing a Restore Device on the RemoteLinc? Thanks

Hello Jim: Yes, that should work well. Best wishes

Hello JG: Another thing that you might consider is going to a fixed IP for your ISY device. This can be done through the admin shell. Be certain that you pick an IP address that is in a range not under DHCP control, so as not to ever run into a conflict with a dynamically assigned address. Then you can even turn off uPnP, and just access the ISY directly by typing the IP address into your browser, and saving it as a favorite. The address will be in the form "http://xxx.xxx.xxx.xxx:ppppp/0/p.html", where the x's represent the fixed IP address, and the p's represent the unique port number of your ISY. Best wishes,

Good news! Thanks, Michel.

Hello Mike and everyone: Ok, I was able to get the desired functionality to work. Here is what I did: I had to write two programs. They are as follows: ******************************************* program name: TURN KITCHEN KPL G ON If Status 'Kitch KPL G - Lower Level' is Off And ( Status 'Bsmt Entry Dimmer - 2G' > Off Or Status 'Bsmt Game Dimmer - 3G' > Off Or Status 'Bsmt Sconce Relay - 3G' is On Or Status 'Bsmt KPL A - Soffit Dimmer' > Off Or Status 'Bsmt Family Dimmer - 3G' > Off Or Status 'Bsmt Stairway Dimmer' > Off ) Then Wait 1 second Set Scene 'Kitchen KPL G Group' On Else - No Actions - (To add one, press 'Action') ********************************************* program name: TURN KITCHEN KPL G OFF If Status 'Kitch KPL G - Lower Level' is On And ( Status 'Bsmt Entry Dimmer - 2G' is Off And Status 'Bsmt Game Dimmer - 3G' is Off And Status 'Bsmt Sconce Relay - 3G' is Off And Status 'Bsmt KPL A - Soffit Dimmer' is Off And Status 'Bsmt Family Dimmer - 3G' is Off And Status 'Bsmt Stairway Dimmer' is Off ) Then Wait 1 second Set Scene 'Kitchen KPL G Group' Off Else - No Actions - (To add one, press 'Action') ******************************************** Possibly there is a more elegant way to do this, so if anyone can think of one, please feel free to share. "Kitchen KPL G Group" is a scene that consists of just the "Kitch KPL G - Lower Level" button. So the " Kitch KPL G - Lower Level" button status, in conjuction with the basement switch statuses, will cause the "Kitch KPL G - Lower Level" backlight to either go on or off as appropriate to the true status of the basement lights. I found that I had to put a 1 second delay for the "Kitchen KPL G Group" status change in these programs. Otherwise, KPL button G (which is both the initiator and recipient of the program) was getting bombarded with traffic while the lights were turning on, which eventually caused the KPL to lock up. I then had to go back an resolve some conflicts with other status changes that I have programmed into the ISY. But after fixing these, this seems to work well. I wonder if this would work for you , MikeB. I haven't tried it with buttons in non-toggle mode, though. Best wishes

Hello Michel & Chris: Is there (or will there be) and equivalent to "Rediscover Device" as SH's Houselinc has? Possibly as part of some diagnostic routine? Thanks

Hello Mike: Thanks for the reply. Let me give more detail on what I've currently got set up. KPL G in my kitchen is linked through a scene to all of the switch devices in the basement. They are all set as responders only. With a single push (in toggle mode) of the Kitchen G all of the basement lights come on. Also included are the basement KPL and all of the Togglelinc dimmers and relays that are part of the n-way circuits down there so that the status reflect properly. The KPL G is only set as a responder to just one of the basement groups (scenes), that is the basement stairway group. So if the basement stairway lights go off, the Kitchen KPL G goes off. As most of the time the stairway lights are always on when the basement is occupied (even if in some other scenes they are called out as dimmed) that gives me a partially reliable status of the basement. I can't make KPL G a responder to all of the lights for the following reason: the moment that one of the lights gets turned off from down in the basement, the KPL G backlight will also go off, and we wouldn't know that there really are lights still on in the basement. Of course, this then creates the opposite problem: if the lights are all off in the basement, and someone from down there turns on any of the lights, the kitchen KPL G does not have the backlight go on. Of course, this is the typical "scene" quandry. Nothing new here. So, I'm going to write a program that just monitors the status of all of the downstairs lights, and the Kitchen KPL G will repond to the status of the basement light. I already have a group (scene) created that only has KPL G in it, and I use that successfully in other programs. I'll let you know what I work out. Best wishes,

Hello Michel: Thanks, Michel. Yes, I know that that button has to be in a scene, a "one-button scene". So what I want to do is to write a program that monitors the status of all my basement lights, then only turns that "one button scene" off when all of my basement lights are off (and on when at least one of the basement lights are on). This should be an easy program to write. But I just wanted to make certain that I didn't encounter any "gotchas". I figured that Mark or MikeB or others may have ideas. Best wishes,

Hello all: I just wanted to get your ideas on the following: - I want to write a program that monitors many different Insteon devices in my basement. As long as at least one of them is on, I want that reflected as a "backlight on" on a KPL in my kitchen. If all of the basement devices are off, then I want the Kitchen KPL button backlight to also be off. I have my own ideas, but I don't want to miss anything. So your input would be appreciated. Thanks you.

Hello Rand: Thanks much for the explanation. It's all working well now. Best wishes,

Chris: You wrote: Just to let you know: my communication problems are resolved. So at least this is out of the equation as a source of the problem. Best wishes, Frank