Communication Woes 0-60 in a Day

[ncoig]

Long post, sorry, but here goes:

 

Insteon Setup ISY-994, migrated from 99 years ago.  9-year old install.  Original PLM (single band) that was obtained with ISY-99 purchase.  Never had issues.  Against advice, the PLM has been plugged into an old UPS with limited filtering, and has worked just fine, reaching all but perhaps one or two modules reliably.  I kept this on the UPS so power to my ISY wouldn't go out, forcing a reboot, on every brownout before my generator kicked on after delay.  Again, hadn't been an issue, but I do understand why it's inadvisable.

 

So now, 9 years later, I suddenly (overnight) see the light on my PLM flashing constantly, and it can no longer communicate with most of my modules.  I have added nothing of note, anywhere that I can think of in the house, besides changing a hard drive in my CCTV DVR on which it shares an outlet.  I unplug the PLM from the UPS, and plug it into the wall and the flashing subsides, but I still cannot get reliable communication.

 

I now assume the PLM is deceased or diseased.  I order a new dual-band version, plug it in, and comm errors persist on the UPS, (no flashing, but I don't think the LED serves the same function here) so I plug it directly into the wall and it still has trouble, but does somewhat better.  I try it at various locations near my panels, on circuits with NOTHING else on them, all to no appreciable difference, still nowhere near as reliable as in the previous 3,285 days.

 

Of note, when plugged in the PLM near the DVR and I look at the comm log, I see tons of repeated X10 (I use nothing on J10 or much of any X10 at all, really); so I assumed a noise issue, and have ordered a Filterlinc.

 

While I've been waiting for it to arrive, on two occasions, I have had the following, VERY TROUBLING issue -- one of my garage doors opens itself, (an IOLinc) and my water control valve shuts off.  Both of these devices are on the only circuits (and a separate panel) that are near to ones that have had some comm trouble in the past, but nothing like this.

 

CLEARLY I can no longer trust Insteon to keep my house safe now with the ISY -- my garages lead straight inside -- and have unplugged the PLM indefinitely awaiting some solution.  The logs show NO indication of anything firing off those two modules near those times.  So what gives?  I thought Insteon was far too particular on addresses and such to have some oddball noise actually trigger devices?  It seems infinitesimally possible that two modules could fail in the same fashion at the same time, so what can this be?  Is my ISY bad?  Sending phantom signals to my PLM and logging nothing?  Seems unlikely, but I have exhausted my searching and troubleshooting.  I love my ISY dearly, but this thing's going straight into the trash if it's going to expose my garage to thieves and intruders.

 

Missed and unreliable signals are one thing; opening my family to the world without my consent is bull****.  

 

What could I be missing here?  Again, the logs show NOTHING related to these modules, except "ERROR 0" or "ERROR 1" when polling for status...

 

Thanks in advance for any insight.

 

-N

Edited October 21, 2018 by ncoig

[kclenden]

Troubleshooting Insteon communication issues is not fun.  I think some people have resorted to using the circuit breakers at the power panel as trouble shooting aids.  You could shut everything off except one breaker that has the ISY + PLM and another Insteon device to see if you get reliable communication between the two, then start flipping breakers on until you start having communication problems.  Or you could start the other way and leave all breakers on and cycle through turning one breaker off at a time to see if the communication issues resolve.  Keep in mind that it's also possible that noise is coming in from outside your house.

Most of the posts I've seen on the forum recommend against using Insteon devices for anything security or mission critical.  If you've had two instances of the garage doors opening themselves, I'm not sure unplugging the PLM is enough.  I'd suggest disconnecting the IOLinc from the garage door opener.

Edited October 21, 2018 by kclenden

[Brian H]

Putting the PLM on an UPS can be a problem. Most of them have a power line filter on them that absorbs the Insteon power line signals. If you have a 2413S and a few Dual Band  modules. The 2413S may still communicate with the system. Through the Insteon RF commands.

From your description. You also may have power line noise. Like the constant of X10 messages you are seeing. Try and unplugging electronics devices or the breaker cycling and  see if things improve.  Electronic devices like the computing equipment , entertainment equipment or the PLM on the same AC outlet as the UPS. Can cause issues. That is why my PLM is on the unfiltered AC outlet of a FilterLinc and the UPS is on the filtered outlet of the same FilterLinc.

The garage door issue. Has been mentioned here. Are you using the Sensor Reversed option in the setup?

[ncoig]

On 10/21/2018 at 5:51 AM, Brian H said:

Putting the PLM on an UPS can be a problem. Most of them have a power line filter on them that absorbs the Insteon power line signals. If you have a 2413S and a few Dual Band  modules. The 2413S may still communicate with the system. Through the Insteon RF commands.

From your description. You also may have power line noise. Like the constant of X10 messages you are seeing. Try and unplugging electronics devices or the breaker cycling and  see if things improve.  Electronic devices like the computing equipment , entertainment equipment or the PLM on the same AC outlet as the UPS. Can cause issues. That is why my PLM is on the unfiltered AC outlet of a FilterLinc and the UPS is on the filtered outlet of the same FilterLinc.

The garage door issue. Has been mentioned here. Are you using the Sensor Reversed option in the setup?

Yes, I have to because Smarthome's stupid kit came with the wrong (IMO) NO vs NC contact switch.  Regardless, that fails to address how an Insteon module (or two, in this case) can spontaneously flip themselves.  The IOLinc for the Water Valve isn't reversed...

 

Also bears noting that after unplugging the PLM, I had an Insteon switch turn itself off that is a member of no scenes as I sat in the room. ???  Again, am I wrong in thinking that an Insteon device has to be identified by unit ID and a command?  How could noise be misinterpreted as such?!?

 

Thanks for your input.

 

-N

[ncoig]

On 10/21/2018 at 4:04 AM, kclenden said:

Most of the posts I've seen on the forum recommend against using Insteon devices for anything security or mission critical.  If you've had two instances of the garage doors opening themselves, I'm not sure unplugging the PLM is enough.  I'd suggest disconnecting the IOLinc from the garage door opener.

Certainly, and your points are well taken, but my concern lay mostly with the apparent much-less-than-I-thought precise nature of the comm to Insteon devices. 

 

To your point about "security" or "mission critical" purposes, your point is well taken, however -- the ISY is tightly integrated with my ELK (by design), and Smarthome sells a kit specifically for a garage door by the boatload, which invariably houses things of "security" import, so to say we are expected not to use it for such tasks is cheeky at best.

 

-N

[mwester]

2 hours ago, ncoig said:

... Smarthome sells a kit specifically for a garage door by the boatload, which invariably houses things of "security" import, so to say we are expected not to use it for such tasks is cheeky at best...

I hope you are referring to Smarthome, and not the forum members.  We may be a lot of things, but "cheeky" isn't one of them (honest, annoying, straightforward, even argumentative, yes -- but not "cheeky")!

Yes, Smarthome sells the kit intended (by their marketing department) to be for automating a garage door.  However, the fact that their marketing department has packaged together a switch (the wrong kind, as it turns out) along with a length of wire, and an IOLinc, doesn't make it so.  The "kit" that they sell is not only not safe for security use, it's also not code-compliant.  Caveat Emptor and all that. 

Here's your choices on that thing:

a) remove it, and replace it with a *proper* "barrier" type device intended for operating garage doors -- such a device would have the required warning sound and lights with a short delay before closing the door, and would have appropriate secure communications built-in.  A lot of Z-Wave devices meet this need, no Insteon devices meet this requirement.

b) remove it, and replace it with nothing.  You remain secure, but you'll have no automation.

c) remove the operating wire, but leave the sensor.  You'll avoid the issues with the door opening on its own, and you'll be code-compliant, and you'll have the ability to monitor if the door is open or closed (but you can't have your automation operate it anymore).  You'll still have the reversed sensor thing at the 3AM query -- that's part of the botched sensor reverse firmware in the IOLinc, and you can't fix it, nor easily work around it.

d) as with c, but replace the sensor switch with one of the correct type.  Now you'll correctly be able to read the status of the door, without worrying about that firmware bug in the IOLinc that sends the wrong info when queried with trigger reverse enabled.

e) call forum members "cheeky" for providing information that Smarthome's marketing team would rather you don't have.  This choice, alas, doesn't solve any of the problems, though.

 

[kclenden]

19 hours ago, ncoig said:

Also bears noting that after unplugging the PLM, I had an Insteon switch turn itself off that is a member of no scenes as I sat in the room. ???  Again, am I wrong in thinking that an Insteon device has to be identified by unit ID and a command?  How could noise be misinterpreted as such?!?

Is it possible that your Insteon switch has an X-10 address assigned to it?  Random noise on the power line could more easily form an X-10 command than a valid Insteon command that would be accepted by the switch.  Early in my Insteon experience, I had a switch that came on and went off seemingly by itself.  Eventually I found that it had an X-10 address assigned, even though I hadn't assigned one.  Other forum members indicated that switches sometimes come from the factory with X-10 addresses assigned and that all Insteon devices should be "factory reset" upon installation.

Edit: Also perhaps it's an older switch that responds to All On/Off commands.  I don't know for sure, but maybe All On/Off commands don't include unit id and thus would more easily be formed from noise on the line.

Edited October 23, 2018 by kclenden

[oberkc]

At the risk of derailing this conversation, I am one who use the IOLinc for garage door control.  I don't know that I would do this if I lived in a high-threat location, but I don't.  I don't think there is a one-size-fits-all answer to this one.

Back to your problem....I don't know why, but my initial reaction was to suspect the UPS itself.  How old is it?  Could it be degrading over time and, itself, causing comm problems?  I always look for easy solutions first, so I would temporarily unplug this and see if that helps.

[apostolakisl]

I think the x10 commands you are seeing in your log are the root of your problem.

oberkc I think makes a good point about the UPS.  You might take it offline first and see what happens.

kclenden also makes a good point.  Most of us will do a factory reset on all of our Insteon devices upon receipt from SH just to be certain they have clean memory.  It is a simple matter with an ISY to  factory reset all of your switches and do a "restore device" from your ISY (I would only do them a few at a time though).  There really is no reasonable way in the world that noise could ever be misconstrued as a valid Insteon command, they are just too long and specific.  X10 on the other hand are much shorter/simpler commands.

If you are getting a bunch of mystery x10 commands showing in your log, and this is a constant thing, it would be very easy to track down.  As mentioned earlier, circuit breaker test is the quickest way to narrow it down.  Get your laptop, head over to the panel, and then turn off breakers one at a time until the ISY log stops showing x10 commands.  As mentioned, x10 commands can come from outside your home (ie neighbor).  It could be your neighbor just installed something.

[ncoig]

11 hours ago, kclenden said:

Is it possible that your Insteon switch has an X-10 address assigned to it?  Random noise on the power line could more easily form an X-10 command than a valid Insteon command that would be accepted by the switch.  Early in my Insteon experience, I had a switch that came on and went off seemingly by itself.  Eventually I found that it had an X-10 address assigned, even though I hadn't assigned one.  Other forum members indicated that switches sometimes come from the factory with X-10 addresses assigned and that all Insteon devices should be "factory reset" upon installation.

Edit: Also perhaps it's an older switch that responds to All On/Off commands.  I don't know for sure, but maybe All On/Off commands don't include unit id and thus would more easily be formed from noise on the line.

I actually had just read some posts on that issue.  Because the IOLincs are BOTH responding and happen to be from two different vendors and different vintages, it seems highly unlikely, and because ISY can't manipulate that bit of data, there's no easy way to determine if they have an address without blanking them, which seems unnecessary considering the foregoing.  

 

I will say that even with the PLM unplugged I watch another switch turn itself off the other day, so there's definitely something going on...

 

As to the ALL OFF bit - they are both IOLinc .41, which I think is pretty current, but maybe.  That's not something with which I'm familiar.

 

Thank you for the ideas.

 

-N

[ncoig]

11 hours ago, oberkc said:

At the risk of derailing this conversation, I am one who use the IOLinc for garage door control.  I don't know that I would do this if I lived in a high-threat location, but I don't.  I don't think there is a one-size-fits-all answer to this one.

Back to your problem....I don't know why, but my initial reaction was to suspect the UPS itself.  How old is it?  Could it be degrading over time and, itself, causing comm problems?  I always look for easy solutions first, so I would temporarily unplug this and see if that helps.

 

The UPS is quite old; which is why it doesn't filter much and worked with the PLM, I plan to put the entire shebang behind the Filterlinc when I get it.  You may be correct, but given that unplugging the DVR prevented the switches from strobing out and so on, I'm led to believe it has something to do with that...

 

When the FL comes in, I'll check that out, too.

 

Thank you!

 

-N

[ncoig]

6 hours ago, apostolakisl said:

I think the x10 commands you are seeing in your log are the root of your problem.

oberkc I think makes a good point about the UPS.  You might take it offline first and see what happens.

kclenden also makes a good point.  Most of us will do a factory reset on all of our Insteon devices upon receipt from SH just to be certain they have clean memory.  It is a simple matter with an ISY to  factory reset all of your switches and do a "restore device" from your ISY (I would only do them a few at a time though).  There really is no reasonable way in the world that noise could ever be misconstrued as a valid Insteon command, they are just too long and specific.  X10 on the other hand are much shorter/simpler commands.

If you are getting a bunch of mystery x10 commands showing in your log, and this is a constant thing, it would be very easy to track down.  As mentioned earlier, circuit breaker test is the quickest way to narrow it down.  Get your laptop, head over to the panel, and then turn off breakers one at a time until the ISY log stops showing x10 commands.  As mentioned, x10 commands can come from outside your home (ie neighbor).  It could be your neighbor just installed something.

Well, I would tend to agree, but when the PLM is in the wall and not on the UPS where it was having the issues, the X10 commands no longer showed up.  Moreover, due to the extremely unlikely happenstance that two IOLincs manufactured months if not years apart would both have an identical and errant X10 address, I'm having trouble thinking that is the issue.  Add to that the now third unit that randomly went off without a PLM connected, and, well...

 

Funny thing is, I tried using some old X10 devices at some point and they wouldn't work in my house -- at all.  Too much racket and interference to use them at all, so that somehow they could be receiving X10 commands when X10 modules themselves wouldn't work is ... laughable?  I don't have a word for that, LOL.

 

Your indication that noise can't be misconstrued is well taken and what I thought to be the case.  I guess I just wanted some validation on that issue before moving further down that rabbit hole, because then SOMETHING is issuing an Insteon command...  without a PLM attached, the question is what?

 

Thanks!

-N

[apostolakisl]

If you have something that is throwing out massive amounts of "x10" like noise into the system it could be giving fits to multiple devices that may have x10 addresses that are totally different.  

Again, I would factory reset your Insteon devices and restore them.  It is simple to do.

[ncoig]

On 10/22/2018 at 1:00 PM, mwester said:

I hope you are referring to Smarthome, and not the forum members.  We may be a lot of things, but "cheeky" isn't one of them (honest, annoying, straightforward, even argumentative, yes -- but not "cheeky")!

I meant the *notion* that the capability would be touted, advertised, sold, etc., but then deemed somehow unfit.  I cast no stones at another forum member, I promise you.

On 10/22/2018 at 1:00 PM, mwester said:

Yes, Smarthome sells the kit intended (by their marketing department) to be for automating a garage door.  However, the fact that their marketing department has packaged together a switch (the wrong kind, as it turns out) along with a length of wire, and an IOLinc, doesn't make it so.  The "kit" that they sell is not only not safe for security use, it's also not code-compliant.  Caveat Emptor and all that. 

While I understand your premise, so long as the opener remains "code compliant" I would imagine finding another way to push the button would not affect that compliance.  But, I'm sure if you're stating that, you've read something that some legislator was paid to add to something to make life more difficult!   

On 10/22/2018 at 1:00 PM, mwester said:

Here's your choices on that thing:

a) remove it, and replace it with a *proper* "barrier" type device intended for operating garage doors -- such a device would have the required warning sound and lights with a short delay before closing the door, and would have appropriate secure communications built-in.  A lot of Z-Wave devices meet this need, no Insteon devices meet this requirement.

b

None of your solutions effectively replace it, so I'm all ears on this Z-wave solution - have a name or a link?  I won't be doing it on this house (7 overhead doors and I'm not about to walk those back) but may on my next house.

On 10/22/2018 at 1:00 PM, mwester said:

e) call forum members "cheeky" for providing information that Smarthome's marketing team would rather you don't have.  This choice, alas, doesn't solve any of the problems, though.

That's friggin' cheeky!!!

   

-N

[ncoig]

5 hours ago, apostolakisl said:

If you have something that is throwing out massive amounts of "x10" like noise into the system it could be giving fits to multiple devices that may have x10 addresses that are totally different.  

Again, I would factory reset your Insteon devices and restore them.  It is simple to do.

Is there any way to ascertain if a device has an X10 address without assigning such?

 

Do you happen to know if a Filterlinc would filter X10 "noise"?

 

-N

[Brian H]

The FilterLinc was originally designed for their X10 compatible modules. So it can filter out X10 interference from an offending electronic device.  I have one isolating my APC UPS from the system. UPS in the filtered outlet on the bottom and the PLM in the unfiltered outlet on the front.

I tested a FilterLinc and an X10 XPPF with a strong X10 signal from my XTB-IIR X10 repeater/coupler {>10 volt X10 signal}. With an XTBM X10 signal meter. It was quite effective on an X10 power line signal.

If you tried to use it on the PLM. It would most likely kill all the Insteon power line signals. To and from the PLM.

Jeff's Troubleshooting Tutorials are X10 related but most of the noise and signal coupling information. Can be used as Insteon uses a close signal frequency as X10.   http://jvde.us/x10_troubleshooting.htm

Edited October 24, 2018 by Brian H
More information

[apostolakisl]

6 hours ago, ncoig said:

Is there any way to ascertain if a device has an X10 address without assigning such?

 

Do you happen to know if a Filterlinc would filter X10 "noise"?

 

-N

Not that I know of.  Except maybe sending every x10 address to it one at a time and seeing if it turns on.  If you had the right software, this wouldn't be too hard seeing as there are only 256 total.

But I would just do a factory reset/restore on the switch and then feel confident that there are no x10 addresses on it (unless of course you have an x10 assigned to it in ISY).

[Brian H]

I did not see what X10 messages you are seeing . If it is by chance J Status Request. That is the code with all 1 bits in it. I could see how a noisy device could be falsely decoded as a J Status request and it really is not a true X10 message.

Edited October 24, 2018 by Brian H

[ncoig]

So in terms of an update, I ignored the advice here to "reset" all my Insteon devices in order to clear potential X10 addresses.  I let the problem linger, just to see what would happen, because statistically, that just didn't resonate with me.

 

I still would notice periodically a light would go on or off erratically, but then, as if a big "screw you" from my house, at 330AM one night, all 5 garage doors opened on their own, every light, every device in the house turned on, and scared the ever-living crap out of me and my wife.  Since then, these behaviors happens every so often, now at least once a day it seems, whereby either every device is triggered on, or off, and is accompanied by my thermostats referring to a different program as well.  Sometimes it's everything, sometimes it just shuts off my water, but frequently enough, everything is turned ON or OFF, and thermostats and all other modules are included in the fracas.

I see nothing in the log that looks out of the ordinary, and I've changed no programming recently.

 

Something else is clearly afoot, but I'm not sure how to track it.  I'm moving soon, so I may just light all this insteon stuff on fire and find something else to use, because I'm really not interested in chasing phantoms through the dozens of devices I have, and this type of malfunction is not only inconvenient, but harrowing. 

 

It would certainly seem to point to the ISY as the culprit, as the chances of EVERY device being triggered by something else seems HIGHLY unlikely, but as of now, I don't know where to look.

 

-N

[SteveKlos]

Unsure if this may help, but I was having issues with my ISY essentially getting DDoS issues from X-10 noise.  Took a while, but I figured out the issue for me - have a look at this posting - 

 

Cheers,

SK

[ncoig]

By way of an inconclusive update here, I sold the house in question and moved away.  Prior to the move, I had simply unplugged the ISY, leaving the PLM and all switches in place.  The issues vanished, and I never again had the phantom operations occur.  Thus, something was afoot in the ISY, or something was triggering the ISY to go bonkers.  I took the offending hardware and have employed it in a new location, wiped clean and started from scratch, taking care to factory reset every single of my 100+ Insteon devices before programming the first one.  So far, so good.

 

-N 

[Teken]

This problem will appear again as nothing has changed. The UDI WiKi provides good information to what is known to Insteon users as the *ALL ON* problem.

The only true solution is to purchase brand new Insteon hardware that omits the all on / all off command set. Smartlabs indicates this process began late in 2013. Regardless of that date if you purchase anything that has a manufactured date of 2020 - 2021 there is zero possibility it’s related to the all on / all off command as it physically doesn’t exist in the hardware.

You’re also correct this problem has only ever impacted the ISY Series Controller. There has never been a thread I’ve read where the same has impacted a 3rd party controller.

It behoves you to replace the I/O Lincs given the role they play to the largest entry point into the home.

If you also have any older generation motion sensors on hand. These are also prime candidates of causing the all on events to be seen. As older MS when battery was low would send endless on / offs throughout the Insteon network.

Read the WiKi as it pertains to best practices with respect to programs and linking.

[ncoig]

On 2/24/2021 at 8:40 AM, Teken said:

This problem will appear again as nothing has changed. The UDI WiKi provides good information to what is known to Insteon users as the *ALL ON* problem.

The only true solution is to purchase brand new Insteon hardware that omits the all on / all off command set. Smartlabs indicates this process began late in 2013. Regardless of that date if you purchase anything that has a manufactured date of 2020 - 2021 there is zero possibility it’s related to the all on / all off command as it physically doesn’t exist in the hardware.

You’re also correct this problem has only ever impacted the ISY Series Controller. There has never been a thread I’ve read where the same has impacted a 3rd party controller.

It behoves you to replace the I/O Lincs given the role they play to the largest entry point into the home.

If you also have any older generation motion sensors on hand. These are also prime candidates of causing the all on events to be seen. As older MS when battery was low would send endless on / offs throughout the Insteon network.

Read the WiKi as it pertains to best practices with respect to programs and linking.

 

This is true and good information, unfortunately, the link to the Wiki with the aforementioned information is darn near impossible to find, even knowing that it's there.  In fact, Michel had just pointed this article out to me a few days ago.  I still can't find it when I google, I'm just glad he hyperlinked it.  For those looking, it's here: https://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events

 

I did have several IOLincs that were  2009 vintage, but I still maintain the oddity of it was the sudden onset after 10 years of that never happening... search me.  Fortunately, I left those behind at the other house.

 

Knowing the instruction set is omitted in new hardware is also invaluable information.Just to beat the horse, I want to quote the wiki to make sure I (and subsequent users with this issue) understand -- the wiki states in pertinent part:

 

• You don't have any programs that use Control for a device and then send a Scene command to a scene which includes the same physical device. So different buttons from the same KPL are considered one device

• Don't Use a Control for a device which is already a Controller for some Scene and then have the program send other INSTEON commands to other devices/scenes. This basically causes two or more events arrive at the PLM at the same time

 

Now, I read this to mean, by way of example, that a program shouldn't turn ON a device, then also turn ON a scene with the same device as a member.  The qualification statement does confuse me, however - but I believe it means that if you have a KPL, you can't turn on the load with a command, then turn on a scene which has, as a member of the scene, one of the KPL's buttons.  I'm pretty sure I've done this before, and it severely hampers utility if you're verbotten to utilize the same physical switch for two different reasons - can this be mitigated by calling a second program to change the scene?

 

The second forbidden action is more confusing - can anyone offer a real world example of what this means?

 

-N