markbrown1

Michel - Tonight things are generally going better. Upon discovering the nature of the bug where I lost my programs, I was able to look at file sizes for all of my past saves and determine which ones would have the programs stored in them and which ones wouldn't. As luck would have it, on Tuesday even though I tried restoring older versions, every one I tried happened to be one where the programs weren't saved. So . . . Tonight I loaded one with the larger file size (only two days old), and have my programs back. The changes I've made since then are going to have to be redone due to my KPL 1.65 issues anyway (see other post), so in the end I got lucky and no harm really done. Thanks for the quick responses. You and your team are doing a great job supporting your customers through a lot of issues, only some of which are your fault. You did have the bug posted - I just didn't find it until too late. I admire the level of professionalism you show despite some frustrated rants from people like me. In the end I think all of us got into Insteon assuming a level of refinement/quality that just wasn't there. Also, thanks for the alert e-mail - probably makes sense for bugs where significant loss of work/time is a possibility. Keep up the good work, mark

Michel, OK, did my homework a little better, and I see that there is a section in the Beta forum with changes for the next release, where the save/restore programs bug was documented. Thanks - that's just what I had in mind. Still need to get my programs back somehow, though . . . mark

Michel, I'm using Beta release 2.6.1, and have recently been "victimized" by the bug where all my programs are gone after doing a restore. I've created dozens of IR-related programs, as well as others, and now see nothing in the list. If there is a way to recover this work, I would be very interested. Also, is there a section of the forum for known bugs with 2.6.1 (sort of like the "features in next release" section)? It would be nice to have a place to check first before going to the effort to troubleshoot a problem. (Sorry if it exists and I just missed it). Thanks, mark

IM, Thanks for the suggestions. Unfortunately, in all three scenarious in my house where there are double switchlinc's, they are all controlling two loads. Otherwise, the idea of doing a double tap for one of the lights, and a single for the other is very intriguing (in fact, exactly the sort of creative suggestion I was hoping to see when I posted the question). I guess I could still pull it off by sticking an in-line device in the box and covering the second switchplate with a blank. Of course, same problem with doing the keypadlinc - two loads to control. Additionally, two of the three locations are controlling fluorescent loads, so I'm reluctant to use keypadlincs. The other factor with keypadlincs is that I've really tried to avoid making them control any primary room lights, or more specifically I have maintained that when you walk into a dark room you can always just feel for a paddle switch and tap it to get some light. While the keypadlincs are very flexible and provide many interesting possibilities (I have 19 of them), they do take more "focus" from the user to get a light turned on vs. a switchlinc. However, one switchlinc and one keypadlinc would represent a pretty good solution for the room with incandescent lights, as it would be really hard to hit both a switchlink paddle and a keypadlinc button at the same time and I'd have two load-controlling switches. What to do with the other buttons . . . Once again, thanks so much for the ideas. As Michel stated, there's really no way to "fix" this problem, so alternatives like those you suggested are great, since they circumvent the issue entirely. mark

Michel, Thanks for the response. I understand that if both switches are pressed, and neither message gets through, then the only possible fix would be to poll the switch status, which if done with any frequency would generate a lot of traffic. While I occasionally see both switch presses lost, most of the time one of the transitions does get through. So I was polling both switches whenever one changed to check if the other had too, then comparing the switch status to other devices in the scene, and if different setting the scene to match the switch. The biggest problem I ran into with this scheme (at least what I think the problem was) was that the act of polling the switches following a press (played with delays from the "control" event of 0 to 5 seconds) in fact just created another window where the status request could interfere with the second switch correctly reporting status in the first place. I'm not quite ready to give up, but this is turning out to be more of a challenge than I thought, and I believe I'll have to settle for a reduction in the frequency of problems rather than a real solution. My next idea was to cut down on the status traffic by being more specific in my polling (if switch A changes, read status of switch B, and if switch B changes read status of switch A, where before I was looking for switch A or B to change, then reading the status of switches A and . Second, I was going to concede that I couldn't correct the scene too quickly without interfering with switch presses that were only slightly offset from each other, so looking at the delay before detecting inconsistency in the scene and adjusting it to something more like 10 seconds may be better. I suspect that if I looked at several days worth of event logs I would see that the time between successive switch presses is typically a few seconds or less (mostly coming from the physically adjacent switches) or a random distribution of much longer times (normal lightswitch usage patterns for non-adjacent switches) In the end, of course, as long as it is possible for switch transitions to get lost, it's not possible to completely prevent inconsistent status between devices - I am just trying to reduce the frequency by as much as possible. My approach is generally similar to other threads in the forum where people are trying to keep scene status indicators correct following manual changes in the scenes. The fun of having the ISY is that I don't necessarily have to accept all of the shortcomings inherent in Insteon. I really didn't expect you to have the answer (this is, after all, not a problem with your product), but I was assuming that others were bothered by the same issue, and that perhaps someone with more experience with the ISY and Insteon and/or more creativity than myself might come up with an approach with fewer side effects. Thanks as always for the great support, mark

Thanks, Michel. I had suspected that messing with the switches during programming was ill-advised, but didn't enforce it too strictly. I will now. Do you have any insight into when the post-v1.6 KPL's will be available? I intend to get the five that I recently received replaced when something more stable is available, but don't want to initiate that until I know I'll get something better. Also, do you know how to confirm that a PLM is indeed the newer, 2000-link version? I bought mine after the website announced the new version, but how can I tell? (It has a sticker with "2.75" on the back.) Thanks again for your help, mark

Mike, Thanks for the suggestion. It certainly wouldn't have occurred to me to do a restore PLM when my KPL's misbehave - I'll try that the next time. On my older KPL's (pre 1.5/1.6), the biggest issue seemed to be missing links after I programmed them, and repeated restores eventually got the whole thing right (although it sometimes took several tries - no idea why). The 1.6's have more serious issues. I didn't try resetting the device then reloading, and I haven't tried removing the device from ISY then re-adding. All of these things, quite frankly, take a lot of the fun out of the whole process, as any simple change may produce days of frustrating recovery attempts. A possibly related question - when the ISY is programming the devices over the powerline, is it OK to be using the switches, or should I taking steps to keep family members from touching any light switches until the process is complete? I'm suspicious enough of Insteon's overall robustness that I wouldn't be suprised if pressing buttons could cause errors in the programming process, although I certainly hope this isn't the case. Thanks again for the ideas, mark

Michel, Thanks once again for an amazingly quick reply. Does the beta release also support the ISY/99? mark

I've got several rooms in my house where there are two adjacent Switchlinc dimmers. If these are pressed close to simultaneously, it seems that messages to other devices linked to these switches are lost (thus keypad buttons that are supposed to indicate light status in remote rooms don't track). I'm no expert on the Insteon protocol, but this seems to be an issue where a device won't send status when it sees the network is busy (if true, not the best choice, but reality nevertheless). So, I've been trying to write a series of programs in ISY which watch for this occurrance and correct the scenes. My basic plan was to have a program which looks for "on" or "off" control on either switch in the pair, then executes a status check command on both switches. (basically if either switch in the pair changes, assume the other might have but didn't report). Probably not relevent, but in my case these switches all control the loads. Then, separate programs compare the status of the switch to the status of keypad buttons or other linked switches, and if different set those to match the state of the switches queried in the first program. Needless to say, so far I haven't been successful in getting this to work very well. Has anyone else come up with a solution to this problem? If an interesting topic, I can post the programs I've tried and describe how they've fallen short of perfection, but I'm hoping that someone else has already solved this and I can stop straining my brain and just copy another's good work.

Is there any way ISY could implement a "verify links" command, where a device's links are read back and compared with what the ISY intended them to be? I am dealing with some KPL 1.6's right now (waiting for the new version), and it seems every time I add/change a link I have to dump the whole thing out again or the keypad misbehaves badly. Sometimes it takes several tries, and in involved scenes the verification is time consuming and flashes a lot of lights in the house (annoying others who don't think lighting with "behaviors" is a good thing). So, what I'm envisioning is another option, like "restore device", that simply reads the devices links and alerts you if they don't match ISY's understanding. (or perhaps an option of doing this automatically after ISY sends the links to the device, although this would presumably extend this somewhat slow process even more). This would really help isolate whether a given problem is due to bad programming on the user's side or bad links in the switch. I have had other circumstances where I thought the links in the device were bad, but it was me forgetting to add a device to a scene, etc.