oberkc

I have had this problem also, without resolution, having tried all the suggested remedies. Hopefully, this will fix mine, as well.

Yes, 200 amp service with two spare slot for breakers. Of course, if I am able to add all devices to a given scene (test or otherwise), that alone is some indication that things are working. One of my indications of communication problems is the inability to add devices to scenes. The two devices giving me the most consistent problems are incadescent. I have not been satisfied with dimmable florescent. The problems with these two modules have been the inability to add to scenes, failure to go on, failure to go off, going on when they should be going off, and scene test failures. Of course, not all these problems are 100% consistent. Sometimes they work. I did my taxes a month ago and recieved a refund in a couple weeks. One can now do taxes and e-file for free, regardless of income. What a concept....our government tries to encourage e-file, but up to now, charged for the privelege. Enjoy!

1. About 2700 sq feet, plus basement....Story and a half 2. about 1992 3. Active Repeater 4. X10 has been problematic over the few years I have been fooling around with this sort of stuff. Some days were better than others. 5. No boosterlinc that I know of Will revisit. I am not sure that I understand a "whole house" scene. Is this a scene that contains all the devices that I own? Once done, I assume I am looking for consistently bad actors via the scene test, which would in turn point to a bad circuits? Right now, the evening program ran without fault. Also everything turned off last night. Two-in-a-row! I am trying to balance the amount of effort I want to put into this with tolerance towards a few missed commands. An interesting thing happened the other night, though, when a light which was previously off at night was on in the morning. Yet, there are all commands overnight are to turn things off and I have a backup program which turns the whole "network" off. Missed commands are one thing. Wrong responses (or random occurances) are another. I will keep trying, but weather is warming and the yard work is backing up.

I have had a chance, now, to continue to troubleshoot. Tightening the physical connections to a couple of suspect switches and plugs did not solve the problem. I started the painful process of trying to identify devices in the house that may be contributing to communication problems. I unplugged all TVs, X-10 modules, wall power supplies, etc. I also unplugged the washer and dryer, as well as the X-10 bridge at the dryter 220V outlet. I also moved one of the two primary access point to a plug physically closer to the panel. After confirming that the second access point (adjacent to the PLM) was on the opposite leg, I installed access points three and four at locations dictated by the insteon remotes without regard for which leg they were on. All CFLs remained, but few were on. At one point, I was able to achieve reliable communication based on the ISY scene test results. All scenes appeared to operate properly. Then a few stopped. Perhaps an appliance came on? Perhaps it was the furnace? I started adding back a few devices. No single device appeared to create a problem, but when all were put back, scene tests were less than 100% passed. I understand that that is not necessarily a guarantee of failure, but it appeared to be evidence that the composite of electrical devices throughout the house contribute to some level of signal loss....sufficient, perhaps, to reduce insteon reliability to the level of minor frustration. I have also tried the "compare" function on a few of the devices. I did notice some mis-matches on one device, and another that appeared to match up pretty well. Unfortunately, that function takes a lot of time on my system, and to perform that test on all would consume hours. I added a few seconds pause between program commands. Perhaps there were some communication clashes. After all this, I will observe the system performance over the next few weeks and see if anything improves. I sure wish there was a reasonable way to measure power signal noise and signal strength, and the effect of adding and removing devices. The trial-and-error method is not very efficient. I sure don't see myself buying on o-scope but perhaps I will find other options.

Let me know if you need any more details.

Also, I do not percieve this as a GUI problem. Yes, the programs ran as scheduled. Yes, the ISY updated the sunrise/sunset times to reflect the DST condition. Unforunately, the ISY clock was an hour behind, and the programs executed one hour late compare to real time, including those based on sunrise and sunset. This does not strike me as a GUI problem. Everything ran per the ISY settings.

Yes, I am using a custom location. I see no cities from Ohio listed.

Do that you know all the details that I can think would be relevant.... I have had "daylight savings" button checked for as long as I have been using the device. I can't remember when I purchased it, but it is possible that this is the first daylight savings transition I have experienced with the ISY. I have always had the automatic time synch with internet checked, but it has never worked in my experience. I used the default site. As you suggested earlier, though, this may have been due to the fact that I have not always had internet access enabled. Internet access on my machine was activated a couple weeks ago, well ahead of daylight savings transition. This did not fix my synching problem. I was able to access my ISY from other locations using my laptop, which gave me some level of confidence that internet access was working. Daylight savings transition time came and went, and the ISY did not adjust time. It appeared, however, to recognize new sunrise and sunset times based on the one-hour advance in time. I unplugged the cat-5 cable/power from the back of the ISY in the hopes of "rebooting" the ISY. No synch. No DST. I noticed recently that there was a red exclamation point at the configuration tab where the daylight savings box is checked. I tried a couple of the other sites suggested on another threat for time and found one that appeared to work. It believe it was a numeral-based IP address. Unfortunately, I cannot confirm that because the ISY has now defaulted back to the pool.ntp.org site. At this point, there is no red exclamation point and the clock appears accurate.

My version is 2.7

I have both URC and harmony remotes. Both are relatively low-end within the range of products from these companies. The URC is the combo RF-20 / RF base station. The Harmony is the 550. Both have their advantages. I have NOT tried lighting with the harmony, yet, but I believe it could be easily adapted with a little creativity. I don't see where it directly supports insteon or X-10 as does the URC, but I am not sure that this matters. I prefer the URC for form factor (better feel with the buttons) and the fact that it is RF-based, as well as IR. I prefer the computer-based programming of the harmony. I like the soft keys of the URC. The URC directly controls X-10, but requires one of those -543 IR converters to introduce the X-10 signal into the powerline. The insteon IR reciever looks like it might be a better option, but I have not upgraded to that yet. One problem with the URC is that the pre-programmed soft key labels for the X-10 commands are complete nonesense, and you must figure out which of the keys does what. I found the phone support for URC in this matter to be marginal. In the end, I have learned that the URC directly outputs X-10 house codes A1 - A8, on, off, dim, and bright. The best solution for you is going to depend heavily on the locations of your various devices, including sound equipment, TV, ISY. Are all within IR line-of-site? Do you mind having to point the remote to different devices? Do you have IR repeaters? Do you need RF because your devices are at different locations throughout the house? Because my sound equipment is remotely stored, I use the RF base station near that equipment. This is also where the -543 IR converter is located as well. My ISY is in a different room from the TV and sound equipment. I have thought that it would be a great to get a second RF base station to relay the signals into the IR port of the ISY-99. Regardless, the X-10 communication path I currently have seems to work well. Having briefly looked over the manual for the insteon IR converter, it appears that this unit cares not that the signal from the remote is intended to be X-10 or insteon or anything at all related to home automation. Apparently, one simply has to select an unused function on the remote and program the insteon recieve to assign that signal to have a certain meaning. This being the case, one could theoretically use ANY remote to control your lighting. I have yet to take advantage of the IR input to the ISY, but I understand it works in similar fasion to the insteon IR converter. Someday, I will try that out.

The box was (and is currently) checked, and the access to the internet is enabled, and confirmed by my ability to access it remotely. I posted a similar comment on another thread (more related to the NTP thing) in which I also stated that the DST seemed to be fixed when I found a better NTP address. Go figure.

I, too have had continuous proplems synching to pool.ntp.org. (I was getting a red exclamation point on the configuration ta.) Until now I never spent many brain cells trying to figure that one out. I tried a couple more and found one that worked. Coincidentally, the DST suddenly corrected itelf. Despite the Daylight Saving box checked, it did not update automatically. Once I found a working NTP site, however, the time now accounts for DST.

I am just getting back from a week away, and noticed that my DST did not automatically adjust. For the record, my clock also has never synched with the pool.ntp.org, either. I cleared the java cache, and rebooted (unplugged, replugged) ISY. Still time is an hour off.

It is interesting you bring up the extended messages. Was this something introduced sometime between v2.6.7 and 2.7? If there is a potential relationship between extended messages and robustness of communication, perhaps the recent ISY software upgrades had an indirect affect on my reliability (or, more accurately, revealed deficiencies in my electrical system). Also, I understood that the "automatic" message configuration used standard message length for all but a few select devices such as the remote control. Perhaps I should choose only I1 messaging options for more robust communication if the extended messaging is less tolerant of noise or interference, and that there is no benefit in my application. Regardless, for now, I am still hopefull that tightening up a few wall plug and switch wires and wirenuts improved communication. So far, so good. Everything went off last night and came on this evening. It has been a while since that happened.

I have been trying to keep track of the extended message issue, but I am not sure how to identify devices with the extended message capability. I am curious...I don't think I have specifically mentioned this in previous posts....what evidence are you speaking about that lead you to this conclusion? FYI, the two modules in question show on the admin panel as v33. These are not the only v33 modules that I have, and the others appear to be working. I have set the insteon messaging option for automatic. I think I have tried I1 only, but I don't recall that having any affect. I understand the suggestion about the factory reset while installed directly on the PLM. I know that these modules appear to respond well from this location. I assume your suggestion includes adding it to scenes while there, then moving it to the final location. I will give that a try at the next sign of problems. I am missing the theory behind your suggestion with the appliance link. Are you suggesting installing an extra appliance link in the problem location and performing a factory reset on that device. If successful, then add the two problematic devices (which are lamplinc dimmers) back into their final location, keeping the appliance link in place? I am not following how that will help. Yes, I need to track down the noise or signal strength problems. Perhaps I found it earlier in the form of wire connections in the house electrical system. I wish there was a reasonable way positively troubleshoot and identify problems with signal strenght, signal noise, and faulty modules. That would be, in my mind, the single most important improvement we could make to this insteon-based system. Thank you for your time in responding.

OK...I tried moving one of the access points to the through plug of the PLM. No improvement. I also tried moving the stubborn module to another location, but not directly onto the PLM....success. I think I have eliminated the module as a potential problem. It works on the PLM, and it works at other parts of the house. I also think this tends to point away from interference near the PLM. I confirmed that the trouble area of the house is, in fact, on a different circuit at the panel than the computer itself. With my idea list becoming shorter, I opened a couple of the wall boxes to confirm solid contact with the various wire nuts and outlet attach points. While they appeared reasonably secure, they were not what I would have called tight. Considering the possibility that the low voltage signals were getting lost at faulty wiring connections to wall outlets and switches, I tightened them up and retored power at the panel. I then again attempted to add the stubborn modules to a test scene, and it now worked (at least this time). I removed the stubborn module from the test scene and that also worked. Do you suppose that loose house wiring has been the problem all along? I will probably declare success for tonight and watch over the next few days to see how things go.

Actually, the two problem modules that I have are two of my newest. And since I see enough problems reported out there, let me go on record that I have had very good performance with insteon (a couple of years) until the recent introduction of these two modules in this one room. Even through all this, the rest of my insteon system is pretty much flawless and I continue to rely on the ISY and insteon for lighting control. I am a little dissapointed in myself that I have not tried plugging an access point directly into the PLM. Good suggestion. I will give it a shot. My intitial instinct, though, is that this will not help. The other three access points appear to be recieving the signals already, based on the flashing of the LED. I will, however, try and see what happens. Your thoughts on the problem being the location of the PLM have also crossed my mind. My computer area is full of power supplies, routers, modems, wireless phones, and, of course, the computer. Everything except the PLM and an X-10 RF reciever is isolated using one of those smarthome noise filters, but that is still a pretty tough environment. Also, while not 100% reliable, the rest of my insteon system is nearly so. This includes devices that are much further away than the two problem modules. Because of that, I have tended to focus on other factors, but location of the PLM it is one that I will continue to consider. The suggestion about the access point may give a clue about this possibility.

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.