Jump to content

Suddenly having issues with Insteon on my EISY


Recommended Posts

Hi folks,

I switched from my ISY to the EISY last October and my EISY manages a mix of ~30 Insteon devices plus ~10 Z-Wave devices. Up until recently everything has been working flawlessly, but I recently returned from vacation (gone for a bit more than a week) and since returning, I've noticed that most of my EISY automations are unreliable or just not working at all. So I pulled up the IoX console and was spammed with a ton of "Failed Communicating With" messages from just about every Insteon device. My Z-Wave devices seem fine.

When I tested what was going on, it doesn't appear to be 100% communication failure. For example, my lights still respond to my light level sensor and come on at dusk and go off at dawn, and they appear to respond to my Z-Wave motion sensor... however there is a delay. I assume they have to retry a few times before the command gets through.

The first thing I did was to power cycle the PLM and reboot the EISY. Checking the PLM Info/Status, it shows as connected (v9E). To rule out an IoX issue, I also upgraded from IoX 5.7.1 to 5.8.0. It changed nothing, but I really didn't expect it to. Beyond that, I'm at a bit of a loss. It doesn't appear to be an outright PLM failure, given that the PLM shows connected and devices are responding, albeit it may take a few tries. I suppose it could be intermittently failing or something. It is an older serial PLM communicating via the USB to serial adapter after all. As it happens, I have a brand new in the box USB PLM ready to go as a backup if needs be, but I'd prefer to avoid pulling that out if I don't need it yet. Is there any way to confirm or rule out the PLM?

I guess it is possible that there is something interfering with the communications, but we've never had that problem in the past. Plus, I don't see any errors like corrupt packets in the logs or in the event monitor (though I don't know if stuff like that is logged). Most of the devices are dual band devices so they should be able to use RF if the wired communication fails, right? When I do a query, I just see the INST-TX-I1 commands that don't get a reply. Interestingly, every minute I do see an X10 event and X10-RX event, which seems weird since I don't have any X10 devices; I assume X10 may be used by the EISY or as a backup for some device perhaps?

In any case, as we didn't introduce any new electrical devices into the system while I was on vacation, or shortly before leaving. Nor did we move the EISY around or anything like that. So I don't know what could be causing sudden interference. That's usually things with motors, or regulating power supplies, or CFL bulbs, etc. Right? The only thing I can think of similar to that is that I moved a portable dehumidifier from our basement to the garage shortly before we left, but we've had that running for months without issue, and half the time it doesn't even need to turn on. Of course, I tried powering it off and then ran some Query commands, but the results are the same. So I don't think that was the culprit anyway. Most of my bulbs are LED, but I have tried running queries with all the lights off, and that didn't help either.

I have tried querying random devices while watching the event viewer. The interesting thing is that sometimes the query results in 3 INST-TX messages without replies, and other times I will see an INST-ACK (LTSREQ LIGHT), but the EISY doesn't appear to acknowledge it. At least, the red "!" doesn't disappear and I don't see any changes in the status info for the device. In one case, I saw an INST-ACK and then 2-3 minutes later an INST-SRX / Std-Direct Ack from the same device towards the PLM. I don't fully understand the protocol but that sounds weird to me.

Also, it doesn't appear to impact every device. For example, if I trigger my Insteon Motion Sensor II, it gets picked up right away with no delays; but it is an RF only device.

At this point I am out of ideas. I welcome any advice.

Thanks!

P.S., I have looked at https://wiki.universal-devices.com/INSTEON:_Troubleshooting_Communications_Errors and tried several of the suggestions in https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Troubleshooting_Flowchart but I haven't found anything that looks like a smoking gun.

Edited by Merlin
added additional details
Link to comment

I don't think I saw this in write up, did you compare the links table between PLM and iox, and also look at your link table count? 

One of the reasons that some things like Motion sensors and light switches may be working is that they can be device-device programmed scenes and the PLM&eisy have no role in their operation. Is the MS you mention setup to trigger the associated light(s) directly? This could explain some of what you're reporting.

  • Like 1
Link to comment

Paul's suggestion of checking the PLM links is a good one.  It will give you a general idea of the health of your PLM.  In order to get an accurate count of the PLM links, you need to keep the system quiet (disable programs, no powerline or RF activity).  That's not necessary here as you are simply trying to asses if the PLM has totally dumped it's link table (10 link records = bad, over 100 link records probably ok).

The 3 Inst-TX messages that you see in the event viewer sound like the Eisy is sending messages and getting no-response (timeout) and retrying the transmission.  For each TX you should see an INST-ACK (plm Acknowledging) as follows.  This is a query of a device that I removed from my system:

Mon 03/04/2024 08:52:10 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:10 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:19 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:19 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:28 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:28 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:32 AM : [D2D EVENT   ] Event [54 A1 F5 1] [ERR] [1] uom=0 prec=-1
Mon 03/04/2024 08:52:32 AM : [  54 A1 F5 1]      ERR   1

Please post an example of your event viewer query (level 3).  If you are not seeing the ACK's, try power cycling the PLM.

Also post examples of the periodic X10 communication.  I never like seeing this in a system with no X10 devices.  At best, it slows down insteon communication.  At worst, it corrupts the powerline.

Since you are seeing widespread communication issues, the most likely culprit is the PLM - or at least something near it.  You could try moving the PLM, or using an extension cord to plug it in somewhere else.

 

Link to comment
7 hours ago, paulbates said:

I don't think I saw this in write up, did you compare the links table between PLM and iox, and also look at your link table count? 

One of the reasons that some things like Motion sensors and light switches may be working is that they can be device-device programmed scenes and the PLM&eisy have no role in their operation. Is the MS you mention setup to trigger the associated light(s) directly? This could explain some of what you're reporting.

 

I have looked at the PLM Links Table output. There are 73 entries there. Which seems appropriate given I only have about 30 Insteon devices configured at the moment. I'm not entirely sure how to compare against the others, since when I bring up the Show Device Links Table or Show ISY Links Table, it just prompts me with a dropdown for every device I have in my ISY network. Not sure what I should be looking for, and what the difference is between what should be in the Device or Links table outputs.

The motion sensor has a light sensor and motion sensor. It is Z-Wave and AFAIK cannot communicate directly with the Insteon lights. I have a program that monitors light levels and motion, and uses those to turn lights on/off or adjust brightness as needed. So it all routes through the ISY.

I also note that if I flip a light on/off, the ISY gets the notification and removes the "!" in front of the device in the IoX admin console. But that doesn't mean it can communicate back.

5 hours ago, IndyMike said:

Paul's suggestion of checking the PLM links is a good one.  It will give you a general idea of the health of your PLM.  In order to get an accurate count of the PLM links, you need to keep the system quiet (disable programs, no powerline or RF activity).  That's not necessary here as you are simply trying to asses if the PLM has totally dumped it's link table (10 link records = bad, over 100 link records probably ok).

The 3 Inst-TX messages that you see in the event viewer sound like the Eisy is sending messages and getting no-response (timeout) and retrying the transmission.  For each TX you should see an INST-ACK (plm Acknowledging) as follows.  This is a query of a device that I removed from my system:

Mon 03/04/2024 08:52:10 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:10 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:19 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:19 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:28 AM : [INST-TX-I1  ] 02 62 54 A1 F5 0F 19 00
Mon 03/04/2024 08:52:28 AM : [INST-ACK    ] 02 62 54.A1.F5 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 08:52:32 AM : [D2D EVENT   ] Event [54 A1 F5 1] [ERR] [1] uom=0 prec=-1
Mon 03/04/2024 08:52:32 AM : [  54 A1 F5 1]      ERR   1

Please post an example of your event viewer query (level 3).  If you are not seeing the ACK's, try power cycling the PLM.

Also post examples of the periodic X10 communication.  I never like seeing this in a system with no X10 devices.  At best, it slows down insteon communication.  At worst, it corrupts the powerline.

Since you are seeing widespread communication issues, the most likely culprit is the PLM - or at least something near it.  You could try moving the PLM, or using an extension cord to plug it in somewhere else.

 

When I see an response to the INST-TX request, I typically get a single LTSREQ (LIGHT) after the first INST-TX request, but never see a reply after that.

Mon 03/04/2024 12:44:12 AM : [INST-TX-I1  ] 02 62 56 3E BA 0F 19 00
Mon 03/04/2024 12:44:12 AM : [INST-ACK    ] 02 62 56.3E.BA 0F 19 00 06          LTSREQ (LIGHT)
Mon 03/04/2024 12:44:24 AM : [INST-TX-I1  ] 02 62 56 3E BA 0F 19 00
Mon 03/04/2024 12:44:33 AM : [INST-TX-I1  ] 02 62 56 3E BA 0F 19 00

I have powered the PLM at least twice over the last week or so as I have been trying to debug this issue. But that doesn't seem to do anything. It almost seems like the PLM can receive communication from the Insteon devices but is having problems being heard by them.

As for the X10 messages, I am looking at it now and seeing them coming in like once per second. When I have looked in the past, it is usually less frequent (like once per minute or so) but has been there for at least several months. I assumed it was just a backup communication protocol used by the EISY and/or Insteon devices. Here is a 30 second snippet...

Mon 03/04/2024 11:06:45 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:48 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:48 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:50 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:50 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:51 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:51 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:52 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:52 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:54 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:54 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:54 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:54 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:55 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:55 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:56 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:56 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:59 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:59 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:04 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:04 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:06 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:06 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:07 AM : [            Time] 11:07:08 1(0)
Mon 03/04/2024 11:07:12 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:12 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:15 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:15 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:22 AM : [X10-RX      ] 02 52 FF 80

I can move the PLM elsewhere, though I am limited by proximity to the EISY and the length of the USB serial cable. That said, even if I move it, there are only two circuits accessible from that part of my house. It is currently on an isolated circuit that is shared by my network/security/automation gear. Alternatively, I can move it to the general circuit used for stuff in my garage. That said, I would hope I don't need to relocate it, given I have never had any issues with communication previously in its current location and circuit.

Thanks to you both for your feedback and advice!

Link to comment

@Merlin

Under the admin console file menu do a "restore devices". This will rewrite the link tables stored in ther EISY to all your devices. If you have any battery operated  devices then first disable write to battery devices.

If you still have issues after the restore devices, then I would focus on the PLM and possible communication issues such as noise being generated by other electronic devices on the same circuit as the PLM including X10 devices

 

Edited by Techman
Link to comment
2 hours ago, Merlin said:

As for the X10 messages, I am looking at it now and seeing them coming in like once per second. When I have looked in the past, it is usually less frequent (like once per minute or so) but has been there for at least several months. I assumed it was just a backup communication protocol used by the EISY and/or Insteon devices. Here is a 30 second snippet...

Mon 03/04/2024 11:06:45 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:48 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:48 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:50 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:50 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:51 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:51 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:52 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:52 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:54 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:54 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:54 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:54 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:55 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:55 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:56 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:56 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:06:59 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:06:59 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:04 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:04 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:06 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:06 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:07 AM : [            Time] 11:07:08 1(0)
Mon 03/04/2024 11:07:12 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:12 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:15 AM : [X10-RX      ] 02 52 FF 80
Mon 03/04/2024 11:07:15 AM : [             X10]       J/Status Request (10)
Mon 03/04/2024 11:07:22 AM : [X10-RX      ] 02 52 FF 80

Wow, that's a lot of X10 traffic.  That alone can bring your system to it's knees.  It may also explain why wireless devices function while powerline is intermittent.

The Status request isn't a normal X10 device - that's a controller function.  If you don't have any X10 controllers installed (garage door, alarm panel, etc) you may have an Insteon device that's failing (although I've never seen one put out Status requests).

Unless you can come up with a list of likely suspects, the normal way of isolating is to start turning off breakers until the X10 transmission stops.  One you find the suspect circuit inspect/remove devices until you find the culprit.  It's time consuming, but now all that hard.  Best to do when family members are not around to avoid plummeting approval factors.

 

Link to comment
1 hour ago, Techman said:

@Merlin

Under the admin console file menu do a "restore devices". This will rewrite the link tables stored in ther EISY to all your devices. If you have any battery operated  devices then first disable write to battery devices.

If you still have issues after the restore devices, then I would focus on the PLM and possible communication issues such as noise being generated by other electronic devices on the same circuit as the PLM including X10 devices

 
 
 

Sure. Is there any risk of doing this? I assume not, since I'm already having issues, but I don't want to corrupt what I have now if this doesn't work as expected due to PLM issues, or whatever is creating this sudden communication problem. I have purposefully avoided backing up the EISY since I discovered this problem; I don't see the value in backing up a configuration that isn't working properly. My last backup is over a month old, but it was working well at that time.

5 minutes ago, IndyMike said:

Wow, that's a lot of X10 traffic.  That alone can bring your system to it's knees.  It may also explain why wireless devices function while powerline is intermittent.

The Status request isn't a normal X10 device - that's a controller function.  If you don't have any X10 controllers installed (garage door, alarm panel, etc) you may have an Insteon device that's failing (although I've never seen one put out Status requests).

Unless you can come up with a list of likely suspects, the normal way of isolating is to start turning off breakers until the X10 transmission stops.  One you find the suspect circuit inspect/remove devices until you find the culprit.  It's time consuming, but now all that hard.  Best to do when family members are not around to avoid plummeting approval factors.

 
 
 

I am not aware of any X10 devices, but I do have a "Smart" garage door (Chamberlain) which is internet connected via an internet gateway fob, but AFAIK it operates over RF only. I also have an Elk M1 Gold security panel which used to be connected to the ISY back before we upgraded to this EISY in October. But, I never migrated the Elk configuration or license. Not to mention, it is currently unplugged (and battery removed) until I can figure out how to deal with a faulty sensor that won't reset. That said, it communicated via ethernet, not X10 AFAIK. We only purchased the house last summer, so it is possible that there may be some other X10 device(s) in the house that I haven't discovered. There are a number of "smart appliances" in the house though, so I suppose there could be an X10 controller in an appliance or something.

I don't suppose there is any way to get an idea of what kind of controller it could be based on the response (02 52 FF 80)? Not sure if that is an address or whatnot, or if address ranges are assigned by company like MAC addresses.

Link to comment

There's no risk in doing a restore devices, it just rewrites the link tables stored in your controller back to the devices

Were any of your devices, or PLM, purchased used, if so they might contain an X10 address.

Also take a look at your error log to see if there's any indication of an issue.

 

Edited by Techman
Link to comment
Just now, Techman said:

There's no risk in doing a restore devices . 

Were any of your devices, or PLM, purchased used, if so they might contain an X10 address.

Also take a look at your error log to see if there's any indication of an issue.

 

Most of the Insteon devices conveyed with the house. The balance (4-5 devices) were added by me and ordered from Insteon directly. I've spoken to the previous owner, and according to him, the devices were all purchased direct from Insteon/SmartHome prior to them going out of business.

Why would an X10 address be active on a used device? Because they may be older? Is there a way to add/remove an X10 address from an Insteon device? From my understanding, most of these devices were added in the mid to late 2010's and where possible, he only installed dual band devices, so I wouldn't expect any of them to use X10 protocols if it is age based.

I've reviewed the error logs and real time event logs and didn't see any obvious errors. It could be that the system is showing problems but I am not sure what to look for. I have looked for places where it says something other than ERR (0) but beyond that, I am just looking for things that stand out or don't look like they should. Which is hard until you hide all the X10 messages, which fill 90% of the log file.

Link to comment

I might agree that there is a Low risk in doing a device restore.  Unfortunately it WILL NOT eliminate X10 address programming and it is likely to fail with the X10 traffic present on your system.

AFAIK, the ISY cannot "un-program" an X10 address.  There are devices that can (Houselinc) but you don't have them.  The "easy" way to eliminate a X10 address in an Insteon device would be to perform a factory reset (eliminate the x10 address) and then restore it.

I would not factory reset anything while the X10 traffic is present.  As I said above, the restore is likely to fail (just as your queries are failing).  You need to locate the source of the traffic and eliminate it.

Since this just started happening recently, chances are that you have a device that is dying or just in an unhappy state.  Cycling power may correct things.  I think the best approach is to shut off breakers until the offender goes silent. 

As far as why Insteon devices would have X10 addresses - there was a period of time where new devices were received with X10 address from the factory.  Not sure why, test escapes or whatever.  It became so prevalent that "best practice" was to factory reset every device prior to installation.  This was probably many years ago (seems like yesterday), not sure if it applies to any of your devices.

Used devices could have had X10 addresses programmed by their previous owners.  The addresses would NOT be eliminated by linking to the Eisy.  They are in a section of memory that is separate from the device link table.  

Edited by IndyMike
Link to comment
7 hours ago, IndyMike said:

I might agree that there is a Low risk in doing a device restore.  Unfortunately it WILL NOT eliminate X10 address programming and it is likely to fail with the X10 traffic present on your system.

AFAIK, the ISY cannot "un-program" an X10 address.  There are devices that can (Houselinc) but you don't have them.  The "easy" way to eliminate a X10 address in an Insteon device would be to perform a factory reset (eliminate the x10 address) and then restore it.

I would not factory reset anything while the X10 traffic is present.  As I said above, the restore is likely to fail (just as your queries are failing).  You need to locate the source of the traffic and eliminate it.

Since this just started happening recently, chances are that you have a device that is dying or just in an unhappy state.  Cycling power may correct things.  I think the best approach is to shut off breakers until the offender goes silent. 

As far as why Insteon devices would have X10 addresses - there was a period of time where new devices were received with X10 address from the factory.  Not sure why, test escapes or whatever.  It became so prevalent that "best practice" was to factory reset every device prior to installation.  This was probably many years ago (seems like yesterday), not sure if it applies to any of your devices.

Used devices could have had X10 addresses programmed by their previous owners.  The addresses would NOT be eliminated by linking to the Eisy.  They are in a section of memory that is separate from the device link table.  

 
 
 

I ran the device restore, which didn't really do anything to help, and now 9 of the devices show the little 1101 thing before their names in the admin console. Three of them are battery powered RF devices (Motion Sensor, Thermostat, and a Leak Sensor), though the Thermostat is technically DC powered. The other 6 are SwitchLinc v.45 dimmers, which seems weird given they're not battery powered devices. Though for the latter, it should be easy enough to write those multiple times until they eventually get through.

So, some older Insteon devices came with X10 addresses by default. In that case, it should be fairly easy to isolate which one is causing the problem since I don't really have that many devices it could be. But does it have to be coming from one of the Insteon devices? Can non ISY linked devices appear in the event log? Previously you mentioned that the status request was a controller function, so can that be coming from one of the Insteon devices? Could it be coming from the ISY itself in response to an X10 enabled Insteon device that may or may not be misbehaving?

At this point, this should be an inventory of the Insteon devices I have currently deployed. Can any of these be X10 controllers or more likely to be X10 enabled?

Battery/RF (can't be X10, since not powerline right?):

  • 2441ZTH Wireless Thermostat (USB + battery)
  • 2844-222 Motion Sensor II (USB + battery)
  • 2852-222 Leak Sensor

Wired/Dual Band:

  • 2472D OutletLinc Dimmer
  • 2475F FanLinc module
  • 2477D SwitchLinc Dimmer Switch x 15
  • 2477S SwitchLinc On/Off Switch x 3
  • 2477SA1 Normally Open 240V 30A Load Controller
  • 2334-222 (2487S) 6-button KeypadLinc Dimmer Switch
  • 2442-222 Micro Module Dimmer
  • 2443-222 Micro Module On/Off
  • 2663-222 On/Off Outlet

I don't have easy access to the Micro Modules or FanLinc Module to do any kind of factory resetting, but I don't expect them to be a likely candidate here anyway.

Link to comment

It's very likely not an Insteon device sending X10 as the messages are all Housecode "J", which is the X10 Housecode where all signal bits are set to "on" on the powerline.

In that case its one of two things:

  1. An appliance or some electrical device is emitting noise on a continuing basis that looks like all bits on all the time, that the PLM interprets as X10 house code "J"
     
  2. The PLM is losing its marbles and creating these messages in error. I've seen this one myself. I don't have the forum links handy, but it's not the first time I've seen a post about PLMs producing a flood of "J" messages
  • Like 1
Link to comment

As Paul indicated, this doesn't necessarily have to be an Insteon device producing the traffic.  I had an old (10+ years) Homelink receiver in my garage that was capable of Transmitting X10 - It went nuts one day and began spamming the powerline on housecode P.  It happens.

You could try air gapping (not resetting) your Insteon devices to see if the communication stops.  Unfortunately there are two that are difficult to access.

I still think your best approach is to turn off breakers one at a time until the noise goes away.  If you cycle through all the breakers except the circuit the PLM is on and still have the noise - move the PLM to another circuit and check the breaker on the former.

 

  • Like 2
Link to comment
6 hours ago, paulbates said:

It's very likely not an Insteon device sending X10 as the messages are all Housecode "J", which is the X10 Housecode where all signal bits are set to "on" on the powerline.

In that case its one of two things:

  1. An appliance or some electrical device is emitting noise on a continuing basis that looks like all bits on all the time, that the PLM interprets as X10 house code "J"
     
  2. The PLM is losing its marbles and creating these messages in error. I've seen this one myself. I don't have the forum links handy, but it's not the first time I've seen a post about PLMs producing a flood of "J" messages
 
 
 

It would be nice if there were a way to remove the PLM from the equation without having to switch to a new PLM and deal with remapping everything. That said, most of what you've said seems to be pointing there and it is the most accessible part of this. I also know the PLM is at least 5 years old at this point, which supports the idea that it could be starting to fail.

6 hours ago, IndyMike said:

As Paul indicated, this doesn't necessarily have to be an Insteon device producing the traffic.  I had an old (10+ years) Homelink receiver in my garage that was capable of Transmitting X10 - It went nuts one day and began spamming the powerline on housecode P.  It happens.

You could try air gapping (not resetting) your Insteon devices to see if the communication stops.  Unfortunately there are two that are difficult to access.

I still think your best approach is to turn off breakers one at a time until the noise goes away.  If you cycle through all the breakers except the circuit the PLM is on and still have the noise - move the PLM to another circuit and check the breaker on the former.

 
 
 

I was hoping to avoid cutting power to the circuits in my home. But If that is what I need to do, I guess I'll do it. I just need to find a good time to do so.

Too bad the Elk ESM1 X-10 scanner and TesterLinc are no longer sold. I'd welcome a tool to help me track this down. Assuming it isn't a bad PLM or Insteon device, it could be anything... a wall wart or misbehaving PSU, or a CFL or LED bulb, or who knows what.

Link to comment
13 minutes ago, Techman said:

Replacing the PLM is just an academic exercise. Instructions are attached.

Replace Modem (eisy_polisy).pdf 262.63 kB · 0 downloads

 

Thanks. I've read through the instructions for swapping PLMs and have a new USB PLM ready to go that I picked up as a backup in case I need to replace my old serial model. However, given the issue with the X-10 messages and/or electrical noise, do you think that replacing the PLM first makes sense? I guess I am just trying to avoid making things more complicated or obfuscate potential problems.

Of course, if I replace the PLM, at the least I'd know whether or not it is part of the problem; that would inform my next steps.

Thanks!

Link to comment

Make sure you have a current backup. 

Any 1011 errors mean that there are pending writes to that device. I don't think the PLM is the core of your problems. However if wouldn't hurt to install the USB PLM as the newer PLM's have updated hardware and firmware.  You should really focus on what's causing the communication issues. It could be a defective device that's creating powerline noise. Try pulling out the set buttons on all the non-battery devices that are showing pending writes and/or a red exclamation point then check your log to see if the X10 data stops.

Being that you bought the house with the Insteon devices it highly possible that one or more of the devices is causing an issue. You can also try factory resetting the devices, then doing a restore device to see if that clears up things. Do one device at a time then check your log to see if the X10 data goes away.

Link to comment
4 minutes ago, Techman said:

Make sure you have a current backup. 

Any 1011 errors mean that there are pending writes to that device. I don't think the PLM is the core of your problems. However if wouldn't hurt to install the USB PLM as the newer PLM's have updated hardware and firmware.  You should really focus on what's causing the communication issues. It could be a defective device that's creating powerline noise. Try pulling out the set buttons on all the non-battery devices that are showing pending writes and/or a red exclamation point then check your log to see if the X10 data stops.

Being that you bought the house with the Insteon devices it highly possible that one or more of the devices is causing an issue. You can also try factory resetting the devices, then doing a restore device to see if that clears up things. Do one device at a time then check your log to see if the X10 data goes away.

 

I have a backup from December before these issues started happening. I haven't backed anything up recently since I wasn't sure whether this would create a corrupted backup or not. Either way it sounds like it may be better to wait on the PLM swap until I've at least had a chance to test all the Insteon devices, now that I know that I can disable them individually by pulling out the set button (I assume this also means "air gap" that was referred to earlier).

I have access to all but 3 of the devices (the fan & micro modules are not super easy to get to as they appear to be in the walls/ceiling or maybe a j-box somewhere). I have never actually seen them myself. I am also pretty sure that not all the devices have a pull out set button (i.e., the 240V load controller we use for the baseboard heaters in our basement), so I'll need to look into how to disable those types of devices. That is all better than flipping breakers, though if the Insteon devices don't end up being the cause, I guess flipping breakers comes back on the agenda.

Just now, Techman said:
 

I already have that open in another window and read through it before I started posting here. In fact, my PLM used to be plugged into a UPS, but as one of the first troubleshooting steps, I plugged its power strip directly into a power receptacle instead. I am pretty sure the power strip doesn't have surge suppression, but I'll need to confirm that.

Link to comment

@Merlin,

If this happened all of a sudden, then I strongly recommend moving your PLM to a different outlet and one which is not shared with other transformers and power supplies.

In addition, if you have any INSTEON thermostats, unplug them (take off the faceplate) and also unplug SwitchLincs version 35, KeypadLincs 2A and 2D.

With kind regards,
Michel

Link to comment
3 hours ago, Michel Kohanim said:

@Merlin,

If this happened all of a sudden, then I strongly recommend moving your PLM to a different outlet and one which is not shared with other transformers and power supplies.

In addition, if you have any INSTEON thermostats, unplug them (take off the faceplate) and also unplug SwitchLincs version 35, KeypadLincs 2A and 2D.

With kind regards,
Michel

 

Hi @Michel Kohanim,

The only transformers and power supplies on that circuit right now are the ones for the EISY itself and some of my network gear, which is all behind a filtering sine wave UPS and has been since before I moved from the ISY to the EISY 6 months back. There is only one other circuit in the area that I can use, which should be mostly clear of traffic, but is used sporadically for garage stuff.

I do have an Insteon thermostat, but it is the 2441ZTH Wireless Thermostat which is battery+RF, so I don't think that would be relevant. As for the SwitchLinc's they are all v.45 so I assume those are fine. I only have one KeypadLinc (2334-222 (2487S) 6-button KeypadLinc Dimmer Switch v.44); I'm not sure if they are 2A or 2D but I don't see that in the model or name, so I assume it isn't one of those.

Thanks!

Link to comment
4 hours ago, Merlin said:

Hi @Michel Kohanim,

The only transformers and power supplies on that circuit right now are the ones for the EISY itself and some of my network gear, which is all behind a filtering sine wave UPS and has been since before I moved from the ISY to the EISY 6 months back. There is only one other circuit in the area that I can use, which should be mostly clear of traffic, but is used sporadically for garage stuff.

The UPS is a relevant piece of information.  Most of them have a EMI filter that will absorb Insteon signals.  Other units have been found to be noise generators.  Either way it should probably be installed on a filterlinc.  Check the current draw of the UPS before installing a filter.  

If you don't want to move your PLM to the garage circuit, you could move your UPS and equipment to that circuit as a test.

 

Link to comment

@Merlin,

I used to be able to run 5 miles a day and do 15 pull ups. As I aged, things rapidly deteriorated. The same is true for electronics especially power related, but with one difference: they start creating noise. So, please never ever count on "things used to work for n years".

With kind regards,
Michel

  • Thanks 1
Link to comment
Posted (edited)
8 hours ago, IndyMike said:

The UPS is a relevant piece of information.  Most of them have a EMI filter that will absorb Insteon signals.  Other units have been found to be noise generators.  Either way it should probably be installed on a filterlinc.  Check the current draw of the UPS before installing a filter.  

If you don't want to move your PLM to the garage circuit, you could move your UPS and equipment to that circuit as a test.

 
 
 

Yeah, the PLM is not under the UPS. It does plug into the same 4 way outlet that the UPS plugs into, and they share the same dedicated circuit.

I can certainly put a noise filter in front of the UPS as a test to be sure it isn't a device in that rack (UPS or other gear) that is introducing noise on the line.

The UPS has a 1500VA/1000W capacity, though its nominal draw is at or below 200-300W with the gear I have in there right now. If you can recommend a good filter, that would be helpful. I've seen a bunch of powerline noise filters on Amazon, but I don't know what type/model/frequency ranges I should be attenuating.

I don't have any issues with having the PLM on the garage circuit, other than the fact that stuff does occasionally get plugged into that circuit like battery chargers, power tools, etc. But for testing it wouldn't really matter since nothing is plugged into the garage circuit right now aside from the portable dehumidifier that I ruled out as a noise source earlier.

The two circuits are also on two different phases, so that could also be something to test I suppose. I don't know how well the Insteon devices manage bridging, but prior to a few weeks ago, I never noticed any issues reaching equipment so I assume it isn't an issue.

4 hours ago, Michel Kohanim said:

@Merlin,

I used to be able to run 5 miles a day and do 15 pull ups. As I aged, things rapidly deteriorated. The same is true for electronics especially power related, but with one difference: they start creating noise. So, please never ever count on "things used to work for n years".

With kind regards,
Michel

 
 
 

I get that... I work in tech and have a basic understanding of electricity, electronics, and cable signaling. Good enough to do basic electrical repairs and troubleshoot networking installs, etc. I'm just less familiar with the Insteon equipment, and assume they have a very high MTBF so everything should work as expected. :)

3 hours ago, oberkc said:

This is my experience as well.  UPS will mess with insteon signals.

 
 
 

Yeah... since this is a sinewave UPS, it cleans and filters the power coming in and going out for the stability of the equipment running under its power. So it should strip out any signals coming into the UPS, but pass any signals originating from UPS supported devices back out to the circuit untouched. But that is why the PLM is not under UPS power.

Edited by Merlin
Link to comment
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      36.5k
    • Total Posts
      367.7k
×
×
  • Create New...