current state wrong

[oberkc]

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?

[MikeB]

If you're running 2.6.13, I would highly recommend upgrading to our release firmware 2.7.0.

 

Please post back if that does not resolve your issues.

 

Thanks

[oberkc]

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.

[Sub-Routine]

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.

 

The ISY sends a group command and the cleanup messages and assumes that the devices have responded.

 

If you have having communication issues the best way to discover which devices are having trouble is the new Tools/Diagnostics/Scene Test function.

 

Rand

[MikeB]

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.

 

You may want to consider running a 'restore device' on any problematic devices, especially if links on that device were programmed with 2.6.13. That firmware was using i2 commands to program newer i2-capable devices, but some users experienced issues programming links with those commands.

 

The newer firmware uses i2 commands only for devices which REQUIRE it (Motion Sensors, etc.), but any links programmed with 2.6.13 could still be corrupt.

 

Otherwise, you may be having typical comm issues as Rand pointed out above.

 

Please let me know how you make out.

[oberkc]

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.

[oberkc]

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.

[oberkc]

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.

[Michel Kohanim]

Hi oberkc,

 

Would you be kind enough to start Tools->Diagnostics->Event Viewer (Level 3), do a query on the device, save the log and paste it here?

 

With kind regards,

Michel

 

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.

[oberkc]

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

[Michel Kohanim]

Hello Ken,

 

Yes, thanks so very much. This tells me that you have good communications and that the status should be correct.

 

Now, what we have to figure out is why you get a failure message when you try to add this to a scene. Can you try adding this to a completely empty scene while keeping the event viewer on level 3?

 

Thanks and with kind regards,

Michel

[oberkc]

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.

[oberkc]

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.

[Michel Kohanim]

Hi Ken,

 

Thanks so very much. Based on what I see in the logs, I speculate the following (in the order of probability):

1. A corrupted database on your device ... please do a factory reset on it and retry the same case

2. noise ... if this device is attached to any load, remove the load. Other sources of noise are CFL, plasma, phone chargers, old computer monitors, etc.

3. Defective device

 

With kind regards,

Michel

[oberkc]

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.

[Sub-Routine]

 

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.

 

As a test I would suggest removing the X10 module.

 

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 that is the case then adding another AccessPoint may solve your issues.

 

Rand

[oberkc]

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.

[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.

[Sub-Routine]

I think you have done a great job on your write-up. Thank you.

 

And I guess this turned into Insteon Communication Issues, but...

 

It does seem odd the X10 works well and the Insteon does not. My experience has been the opposite.

 

Now that you mention starting over I do remember reading of one Insteon user who finally discovered some SwitchLincs that were broadcasting noise 100% of the time. I think with your experience you will find something, somewhere. And since you say Insteon has never worked well it could be one of your first devices.

 

I had very reliable PLC communication for about 2 years. When I switched to the PLM for the ISY I started having failed communications. I plugged an AccessPoint right into the PLM and was back to 100%. Perhaps it's not the LampLincs location but the PLM location. When the KPL flashes perhaps it's the PLM that's not responding. It shouldn't be an issue to use a longer Cat5 between the ISY and the PLM.

 

I hope we read good things soon.

 

Rand

[oberkc]

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.

[oberkc]

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.

[IndyMike]

oberkc,

 

A few observations -

1) Your new Lamplincs utilize Insteon Extended messaging for programming and queries (evidenced in your previous log posts). Extended messages may not be repeated (amplified) by your other Insteon units making the programming sequence more susceptible to noise/absorption. Your difficulty adding these devices to scenes is further evidence of this programming problem.

2) These devices use standard Insteon commands for on/off and scene activation. The fact that you are having difficulty with these functions implies that the programming was incorrect (corrupted by noise/absorption as Michel stated).

3) While the Insteon Filters do a good job of isolating/blocking noise from most devices, others require different "low pass" filters.

 

Please try plugging one of your Lamplincs directly into the PLM and perform a factory reset/restore. This should ensure that the programming is correct. Move the device back to it's original location and (hopefully) verify proper scene operation.

 

If the above works, you can try a variation with the second Lamplinc (if you're game). Unplug all of your possible noise/absorption offenders on the circuit. Install a Accesspoint on the circuit. Perform a factory Reset/Restore. If this programming functions properly you should be able to plug your devices back in and still have scene functionality.

 

If the above works, it's a temporary solution. Until, you track down the possible noise/absorption source (or boost your signal level) you will have difficulties each time you attempt to modify the programming of these devices.

 

Let us know how things are progressing,

IM

[oberkc]

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.

[IndyMike]

oberkc,

 

The query response below is an example of extended messaging.

 

The ApplianceLinc reference was a mis-type on my part. I meant Accesspoint. I've checked my accesspoints (V1.0) and they do repeat the extended message commands.

 

Loose connections can certainly contribute to signal loss, particularly if you have a signal absorber on the downstream side.

 

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

[oberkc]

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.