oberkc

I have played around a bit more and am going to write down my thought process. Feel free to comment, but not compelled. Removing X-10 module does not help. Removing lamps from the insteon module does not help. Retried plugging stubborn module directly immediately next to PLM and re-confirmed proper operation. So, unless this is one of those devices that requires an especially strong signal, I will assume that the module is functioning properly. The two modules in question are both part of two scenes. These modules are currently working very well when responding to a local switchlink dimmer on one scene (where a switchlink dimmer is the only controller), and somewhat well when activated via local keypad link (one of several controllers in second scene). They just haven't worked as part of a the second scene when activated by ISY via program. Turning off and on from admin panel is intermittent, but I find it very stragne that if I turn the scene on from the keypad link, I cannot then turn it off from the admin page without first repeating the on command from the admin page, even though the state shows already as on. This strikes me as a potential clue. Sometimes when I activate the scene via keypad link, the light flashes (which I understand to be a communication failure). Flashing light does not always mean that one or more devices in the scene fail to visibly respond as expected. Sometime the keypad light flashes, even though all other devices appear to respond. I am assuming that the flashing light indicates failure to recieve confirmation, even though the other devices activated and, perhaps, sent confirmation. One of these days, I may get very ambitous and simply start over. Adding devices one at a time may give some further clues. For now, I think that is as far as I feel like going tonight. Thanks for reading.

I will try removing the X-10 module, as suggested. Unfortunately, I have two stubborn modules and only one has the X-10 module in the pass-through. Because of that, I have tended to discount the X-10 module as the primary cause. Perhaps it is affecting both? They ARE on the same circuit. I must admit that I find it disappointing that the X-10 module works nearly 100% and the insteon does not. Yes, I understand that X-10 modules can absorb powerline signals. I have also played around a bit with positioning of the access points. In my house, I have four. Two of the four are already on that same circuit (one of the two is to bridge phases, the other I have recently added to try solving this current problem). While I consider likely that plugging a couple of extra access points directly into the module would improve performance, I consider such a solution to be one of masking the problem rather than solving the problem. I understand the need for access points for bridging phases and providing RF interface to the system. Unfortunately, I find the idea of powerline control appealing and would rather solve the powerline communication issue rather than rely on the RF side of the network. My original question on this post was dealing with a mismatch between ISY displayed state and actual insteon module state. I understood that insteon, unlike X-10, was 2-way communication and had assumed that the ISY would require positive feedback from each of the devices before displaying the state. From the responses to this post, I have come to understand that this is not necessarily the case and that the ISY can make some assumptions regarding state and does not necessarily rely on this feedback. Based on this new understanding, the mismatch of state is not the clue that I was hoping for. Through other posts, I believe I have read the suspicion of some that not all insteon modules are created equal. Some may be more sensitive than others. Some may be more interference prone than others. One of the things I intend to try is to swap modules, moving them from room to room, and seeing if other modules perform better in the location currently giving me problems. I have a pretty good number of insteon devices and also understood that increased numbers were supposed to increase reliability. My experience has been otherwise, but I now have increased confidence in my belief that this is a problem with powerline noise, despite the coverage of additional insteon modules. While it still may be a couple of bad modules, those modules do perform as expected when plugged in immediately next to the ISY's PLM (or whatever it is called). Because of that, I am tending to focus on the noise issue. I certainly have appeciated and even enjoyed the feedback and will contine to check in should anyone have additional thoughts.

It sounds like you believe that this is not an ISY (hardware or software) problem, and I accept that conclusion. I just wanted to be sure. My problems beginning so close to a software upgrade had me wondering. I assume that your reference to "device" having a corrupted database is to the plug-in module. I have removed from the ISY several times and performed a factory reset. I will try again, believing that this is what you are suggesting. The device (assuming, again, that you are refering to the plug-in module) is attached to two lamps, incadescent. There is also an X-10 module plugged into the pass-through outlet (the X-10 module works flawlessly). The second (of two stubborn) devices is driving one lamp, incadescent. While it has been a while, I think I have also tried moving the modules-in-question closer to the ISY. I think this eliminated the problems, making me think my basic noise, but I will try that again to confirm. If I can only identify the source of the noise. My house is full of TVs, computers, appliances, wall warts, CFL bulbs. The frustrating part is that this was also the case several months ago when things were working well and I think I have eliminated anything added over tha period. I will keep thinking and trying. Thank you for your feedback.

As suggested, I created a new scene (called "test") and attempted to add one of the two stubbon modules to that scene. It failed. The level three event view showed: 2009/03/02 17:30:13 : [PM LRF Livingroom Floor] Start : Adding to scene 'test' 2009/03/02 17:30:13 : [PM LRF Livingroom Floor] Making 'test' a Controller 2009/03/02 17:30:13 : [PM LRF Livingroom Floor] Making PLM group 28 a Controller 2009/03/02 17:30:14 : [MNG-LNK-RSP ] 02 6F 40 E2 1C 0E 78 F6 01 00 33 06 2009/03/02 17:30:14 : [PM LRF Livingroom Floor] Using engine version i1 2009/03/02 17:30:14 : [PM LRF Livingroom Floor] Using engine version i 2009/03/02 17:30:14 : [iNST-SRX ] 02 50 0E.78.F6 0D.FC.BA 27 28 0F SET-MSB(0F) 2009/03/02 17:30:15 : [standard-Direct Ack][0E.78.F6-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 2009/03/02 17:30:15 : [iNST-ACK ] 02 62 0E.78.F6 0F 2B B8 06 PEEK (B8) 2009/03/02 17:30:15 : [iNST-SRX ] 02 50 0E.78.F6 0D.FC.BA 27 2B 00 PEEK (00) 2009/03/02 17:30:15 : [standard-Direct Ack][0E.78.F6-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 2009/03/02 17:30:15 : [iNST-ACK ] 02 62 0E.78.F6 0F 29 A2 06 POKE (A2) 2009/03/02 17:30:16 : [iNST-SRX ] 02 50 0E.78.F6 0D.FC.BA 27 29 A2 POKE (A2) 2009/03/02 17:30:16 : [standard-Direct Ack][0E.78.F6-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 2009/03/02 17:30:16 : [iNST-ACK ] 02 62 0E.78.F6 0F 28 0F 06 SET-MSB(0F) 2009/03/02 17:30:25 : [iNST-ACK ] 02 62 0E.78.F6 0F 28 0F 06 SET-MSB(0F) 2009/03/02 17:30:34 : [iNST-ACK ] 02 62 0E.78.F6 0F 28 0F 06 SET-MSB(0F) 2009/03/02 17:30:38 : [PM LRF Livingroom Floor] Finish : Adding to scene 'test' was Incomplete I removed any unneeded electrical device from the adjacent plug (which IS FILTERED using one of those smarthome devices). After persistance in adding modules to a scene, I was eventually successful after several failed attempts. When a program ran this afternoon, turning on the newly-updated scene, the devices did not fire. After this, I tried manually firing the same scene, and one of the two devices turned on. Feel free to speculate on root cause.

I will do as suggested later this evening. Given the responses from you and others so far, I am definitely beginning to focus on communication issues. Also, the performance of the various devices are intermittent, which I conclude points to communication interference, rather than software. One of the frustrating aspects of all this is that I have an X-10 module plugged directly into the pass-through of one of the offending insteon modules. The X-10 module works flawlessly. I am starting to wonder if some of these filterlinks that I use are better at filtering X-10 interference and not as good at filtering insteon interference. Thanks, again, for your responses.

I apologize for responding less quickly than I should. Life events are forcing this problem to a lower priority right now. I was not able to identify an easy way to post the log, so this is copied and pasted from the log file, line-by-line. This is a query from one of the two stubborn modules: 2009/03/01 19:49:12 : [iNST-ACK ] 02 62 0E.78.F6 0F 19 00 06 LTSREQ (LIGHT) 2009/03/01 19:49:12 : [iNST-SRX ] 02 50 0E.78.F6 0D.FC.BA 2B 0D 00 (00) 2009/03/01 19:49:12 : [standard-Direct Ack][0E.78.F6-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 2009/03/01 19:49:12 : [ E 78 F6 1] ST 0 2009/03/01 19:49:12 : [iNST-ACK ] 02 62 0E.78.F6 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 06 (00) 2009/03/01 19:49:13 : [iNST-SRX ] 02 50 0E.78.F6 0D.FC.BA 27 2E 00 (00) 2009/03/01 19:49:13 : [standard-Direct Ack][0E.78.F6-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 2009/03/01 19:49:13 : [iNST-ERX ] 02 51 0E 78 F6 0D FC BA 11 2E 00 01 01 00 00 20 00 1B FE 16 3C 00 00 00 00 2009/03/01 19:49:13 : [Extended-Direct][0E.78.F6-->ISY/PLM Group=0] Max Hops=1, Hops Left=0 2009/03/01 19:49:13 : [ E 78 F6 1] OL 255 2009/03/01 19:49:13 : [ E 78 F6 1] RR 27 2009/03/01 19:49:13 : [iNST-ERX ] 02 51 0E 78 F6 0D FC BA 16 2E 00 01 01 00 00 20 00 1B FE 16 3C 00 00 00 00 2009/03/01 19:49:13 : [Extended-Direct][0E.78.F6-->ISY/PLM Group=0] Max Hops=2, Hops Left=1 Hopefully, I was able to separate the lines accurately. Thank you for your response. Ken

And now I removed the offending module from the ISY and performed a factory reset on the module. I then added the module back to ISY (while successful, it seemed to take a long time), then tried adding the module back to the scene. It failed that operation. The specific error message was "request failed". Unless y'all see something here, I continue to take this as a communication issue.

I was able to run a scene test, as suggested by Mr Fredricksen. One of three devices in the scene failed. I note that the scene state shown by ISY showed off, even though the device was still on. While I think I have already reset the devices and re-established via ISY running v2.7, I will attempt this, also. I will take this as confirmation of a communication issue. I sure don't look forward to isolating the cause of this problem.

OK. I have seen signs of communication issues and it sounds like the incorrectly displayed state is not necessarily evidence otherwise. I will attempt further troubleshooting and let everyone know how it turns out. It may be a few days before I can get to it. Thank you both for your insight.

I apologize that I was not clear about this. I am currently running v2.7 (having upgraded several times between 2.13 and now) and the problems persist. However, it was when I made the switch from 2.6.7 to 2.13 that I first began to notice the problems. I have always assumed that if the ISY shows a state, it must have recieved feedback from the module being controlled. Would the ISY show a state if there are communication errors between a given module? Can I assume that the display of a state indicates that the communication process was complete? Thank you for your time.

I have an ISY, several Keypad Links, Toggle Links, and plug-in modules. I also continue to use a number of X-10 devices (mostly wall modules). I started experiencing problems when moving from ISY version 2.6.7 to 2.6.13 (or thereabouts), but am considering the possibility that this may be coincidental. Regardless.... In a simple program that turns on a couple of scenes and sends a couple of X-10 commands, everything appears to work based on the adminsitrative console display. After the program is run, all the displayed states are displayed as I would expect (which is 40%) based on the just-executed program. Unfortunately, the physical state of the lamps (which are off) does not match the displayed state (which is 40%). If I run a query on the suspect devices, the displayed state is updated to match the physical state (off). There have been times when I am suspecting communication issues, and have been trying various combinations of factory resets, relinks, and the moving around of access points, but I can't help but suspect that the mismatch between actual state and that displayed by the ISY-99 admin console is a clue as to my problems. Unfortunately, I am not smart enough to reach any definite conclusions. Anyone experiencing this problem or have any thoughts?