OutletLinc doesn't switch but reports that it did

[eataft]

I have an OutletLinc linked to a scene that is controlled from an ISY-99 timer program and also from a manual button. This OutletLinc behaves correctly nearly all the time. However, once in a while, I notice that it is on when it should be off, or vice versa.

 

When I look at the ISY log for that time period, it shows that the ISY sent the scene command; then the OutletLinc sent status indicating that it performed the command correctly. For instance, the ISY sent "Scene On" and the OutletLinc reported status of 100%. But I can see that the OutletLinc is not on, and if I query its status from the ISY console, it now reports 0%.

 

Somehow, the OutletLinc performs the command and reports status saying that it did so, but then it falls back to its former state. Either that, or some rogue command is telling it to go back to its former state. (I don't see any such commands in the log, though.)

 

This doesn't seem to be a garden-variety Insteon communication problem, since the commands do appear to be getting through and are acted upon. My system works very reliably except for this one peculiarity.

 

My first thought was simply that the OutletLinc is defective. I was about to replace it when I observed an occurrence of the same problem with a different OutletLinc. (Both OutletLincs have low-voltage landscape lighting transformers plugged into them.)

 

Any ideas for troubleshooting this problem?

 

Also, while looking at the ISY log, I noticed that it doesn't record commands sent from devices other than the ISY, although it records status sent from every device. I wonder if there is an option to record all commands no matter where they came from.

[oberkc]

Out of curiosity, what load is plugged into the outletlinc?

[eataft]

One OutletLinc has a landscape lighting transformer plugged in; the other has a water pump for a fountain plugged in. Both loads are well within the ratings for an OutletLinc.

[oberkc]

I have found that some loads (low power LED lighting, for example) to be TOO LOW for the outletlinc to work. When triggered the outlet often fails to respond as expected, even though it shows up as such on the ISY admin panel. The load can affect an otherwise normal outletlinc. I would not expect the devices you describe to be such a problem, however.

 

If you want to try a quick experiment, temporarily replace your transformer and pump with a simple incandescent (all resistance) bulb fixture of some type. See if this helps. While it probably won't, it is easy enough to try, just to eliminate the possibility.

[Teken]

What does the load have to do with the status of the device being operated? Could you clarify this point for me as I am having a hard time understanding how that would affect the state of the outletlinc device.

 

I ask, because I have several of these coming in the next week or so. And want to ensure I am fully aware as to the pro's and con's of connecting none resistive loads to these devices.

 

I appreciate the insight as always . . .

[LeeG]

The OutletLinc has “load sensingâ€. If it determines the load is Off the OutletLinc turns Off on its own. The OutletLinc has no Controller capability so it does not notify the ISY or any other device that it has turned Off. Try turning Off the load sensing.

 

The ISY shows the device as On as the last command it sent is On. Without Controller capability in the OutletLinc it takes a Query to see that the OutletLinc has turned itself Off.

[Teken]

Lee G,

 

I follow what you're saying and have read this similar answer before. But, what the OP is saying is that the state of the device has always worked before?

 

Can you comment on this portion as it does not reflect what you're saying to be true.

[LeeG]

I have no way of knowing with certainty why the OutletLinc is turning Off. That is why I suggested "Try turning Off the load sensing." The OutletLinc is turning Off as the subsequent Query indicates it is Off. Because the OutletLinc is not a Controller, the OutletLinc turning itself Off would not notify the ISY. There is no command activity traced that explains the result. If load sensing is causing this it would produce all the documented results. If turning Off load sensing does not resolve the problem then other things need to be investigated.

[Teken]

Load sensing by default is turned off from the factory correct? I am very interested in finding out the cause and the solution to this . . .

[LeeG]

Load sensing is Off by default.

 

I ran a test on an ApplianceLinc which is the closest thing I have to an OutletLinc. Load Sensing does turn the ApplianceLinc On but it does not turn the ApplianceLinc Off. I suspect the OutletLinc operates the same way which means Load Sensing is not a candidate for causing the OutletLinc to turn Off. Sorry for the misdirect.

[Sub-Routine]

Hi eataft,

 

If you disconnect the loads do the OutletLincs operate properly?

 

You should be able to turn them On and Off and hear a click each time. A Query on the device should report the current state.

 

Rand

 

One OutletLinc has a landscape lighting transformer plugged in; the other has a water pump for a fountain plugged in. Both loads are well within the ratings for an OutletLinc.

[Brian H]

I don't know how the OutletLincs are electronically, but can verify early ApplianceLincs with local sensing off. Could be false triggered on and off by inductive spikes. The later revision 4.1s I have are much more tolerant to spikes.

 

I would also try Rand's suggestion of what do they do with the transformers disconnected.

[fitzpatri8]

Have you tried a factory-reset on the OLs to verify they don't have an x10 address assigned (perhaps as part of factory testing)? They might be turning off in response to power line noise that looks like a programmed x10 signal.

[IndyMike]

I'm probably going to confuse the issue further, nonetheless here's my understanding -

 

I thought that Michel had established that the ISY does not send group cleanup requests for scenes. If that is correct, the log file entries for scene responders are "predictive". Said differently, the ISY sent the Scene on command and logged the state that the device should have been at.

 

What eataft is reporting below is what I would expect to see if a device simply didn't hear the Insteon scene command. It does nothing. Since the ISY is not requesting a cleanup, it assumes that the device went to an on condition. A follow up query confirms that the device did not respond.

 

Please try controlling the device directly from the device tree (direct command). This will use the full protocol (retries and acknowledges). If the Outletlinc does indeed turn on then off again, you may need to filter the load.

 

 

When I look at the ISY log for that time period, it shows that the ISY sent the scene command; then the OutletLinc sent status indicating that it performed the command correctly. For instance, the ISY sent "Scene On" and the OutletLinc reported status of 100%. But I can see that the OutletLinc is not on, and if I query its status from the ISY console, it now reports 0%.

 

Somehow, the OutletLinc performs the command and reports status saying that it did so, but then it falls back to its former state. Either that, or some rogue command is telling it to go back to its former state. (I don't see any such commands in the log, though.)

[eataft]

This is a belated followup to thank everyone who sent replies. I stopped following this thread after a few days (it was just before Christmas) and I looked at it again only now! I see that I missed several interesting and promising replies.

 

Of all the suggested explanations, the last one from IndyMike sounds the most plausible and I would like to explore it further.

 

My Insteon installation is totally reliable except for the two OutletLincs in question. Even for those, the malfunction occurs only once in a while -- perhaps 1 in 25 tries. However, it happens that both of those OutletLincs are wired downstream from GFI outlets, since they control outdoor circuits. I once read that a GFI outlet can attenuate an X10 signal quite a lot, and I assume that this applies to Insteon as well. So I can see how the signaling to those OutletLincs might be a bit marginal.

 

This is the first I've heard that ISY scene commands aren't transmitted with a robust protocol, the way direct commands are. Is there some documentation I can read about this? It seems terribly misleading for the ISY to log an event that didn't actually happen!

 

If it is true that scene commands aren't acknowledged and retried if lost, then it would seem advisable not to use scene commands at all. But perhaps this can be mitigated by programming the ISY to send "group cleanup" requests, whatever those are. Can anyone explain about this?

 

I already solved my problem by programming the ISY to send those scene commands twice. However, I will now experiment with sending direct commands instead of scene commands. Since the failures occur infrequently, it will be a while before I have conclusive results one way or the other.

[IndyMike]

Hello eataft,

 

Sorry to hear that you're still having problems with this circuit. On the flip side, I'm glad to hear that the remainder of your installation is performing well.

 

Regarding the ISY not using cleanup commands for Scenes - this is still my understanding and I can't say that I disagree with the implementation. It works well for my installation and apparently works well for most of yours. I am far from being an expert on cleanup commands (interrogating scene devices to make sure they have responded), but my understanding is that they can be interrupted (suspended) due to "other" activity on the powerline. As such, they would appear to be a "false" safety net. Beyond that, I'll let other more learned forum members comment.

 

The fact that your problem outletlincs are on a GFCI is significant. I have personally had problems with X10 devices on GFCI's long ago and had believed that modern devices were also a problem. Some time ago ELA challenged me to demonstrate this using current/modern GFCI's. In short - I could not show a problem with devices made within the past 10 years (I tried 3 GFCI's) unless they were connected to "unusual" loads.

 

There are differences in the construction of GFCI's. If your device is older (15 - 20 years) it could be of a different design and therefore be attenuating the Insteon communication. Please try the following -

 

• 
  [*:qw6pbh09]Remove your loads from the outletlincs and re-try your "direct" commands. If the outletlincs perform "significantly" better (hard to determine) it may indicate that your inductive devices (transformer/motor) loading communications. They may require a filter (tough to do outside).
  [*:qw6pbh09]If the above does not work (and you have an "older" GFCI) the outletlincs themselves may be drawing down the signal level due to the "impedance" through the GFCI. Try disconnecting one outletlinc to see if communications improve. If they do, replace the GFCI.

 

Were it me - I would change out the GFCI to a standard outlet and test the heck out of it. I can't suggest that since would be against code and would present a safety hazard. No way would I consider this to be a solution - simply a means of troubleshooting the circuit.

 

IM

[eataft]

A further update on this old matter --

 

I followed up on the suggestion that there simply was poor communication with the OutletLincs that were exhibiting the strange behavior. I relocated the PowerLinc Modem to a different circuit that is more centrally located in my home (and that is far from the ISY-99 and the UPS that it is plugged into).

 

This has resolved the problem. Since making this change several months ago, I have not observed any misbehavior of the controlled devices.

 

Apparently, OutletLincs are more susceptible than other devices are to problems caused by marginal Insteon communication. Either that, or it is coincidental that I observed only OutletLincs to misbehave.

 

I would still like to reiterate my earlier point about the misleading information in the log file, which claims that scene commands were successfully executed when they were not. It is easy to demonstrate this, simply by disconnecting a device and then issuing a scene command that controls the device. The log file shows that the device responded and there is nothing to indicate that the command wasn't executed.

 

This seems very misleading and it certainly led me astray when I was first troubleshooting the problem with my OutletLincs. Perhaps this can be fixed in a future ISY firmware release.

[LeeG]

The change in ISY device status when a Scene is turned On is the assumed result. No device specific command is issued when a Scene On is issued.

 

A Scene Test for that Scene would show a device error if the device is not available.

[Teken]

A further update on this old matter --

 

I followed up on the suggestion that there simply was poor communication with the OutletLincs that were exhibiting the strange behavior. I relocated the PowerLinc Modem to a different circuit that is more centrally located in my home (and that is far from the ISY-99 and the UPS that it is plugged into).

 

This has resolved the problem. Since making this change several months ago, I have not observed any misbehavior of the controlled devices.

 

Apparently, OutletLincs are more susceptible than other devices are to problems caused by marginal Insteon communication. Either that, or it is coincidental that I observed only OutletLincs to misbehave.

 

I would still like to reiterate my earlier point about the misleading information in the log file, which claims that scene commands were successfully executed when they were not. It is easy to demonstrate this, simply by disconnecting a device and then issuing a scene command that controls the device. The log file shows that the device responded and there is nothing to indicate that the command wasn't executed.

 

This seems very misleading and it certainly led me astray when I was first troubleshooting the problem with my OutletLincs. Perhaps this can be fixed in a future ISY firmware release.

 

Thank you for the follow up and end solution. I also agree on all points that the log file should reflect the actual state. Having said this, the outletlinc is a dumb device and perhaps future models will incorporate the two way communications as there are in other Insteon products.

 

Teken . . .