ISY994i Stopped Commanding Insteon Devices

[Thomas Roach]

My house is functioning again, but I'd like some ideas to diagnose the problems if they reoccur. I don't know all the ins and outs of the system, and I really do not want to devote myself to in-depth study. I just wanted some help as I continue to grow old.

Here is a summary of events, some possibly irrelevant:

I started adding POE IP cameras and an NVR to my network, assigning ports in the 25000 range.

Alexa began having issues turning off lights on Insteon dimmer modules. I often had to repeat commands.

I established a dynamic DNS account or external access to the cameras, using software already present in my LinkSys router.

The ISY suddenly stopped controlling all Insteon switches and relays. It would update the status on the counsel, but commands produced a "Cannot Communicate with XXXXXXX. Please Check Configuration" message. X-10 devices still worked. The mini-remote pad also worked so I had manual control.

I read about issues with the PLM at the 2-year point. Although my PLM is 16 months old, I tried restoring it without success and then ordered a new PLM from Amazon.

I substituted the new PLM and used the "Restore PLM" command. The system continued to act in the same way. I reinstalled the original PLM and turned off all power to the new camera system, unplugged everything, and checked the whole-house surge protector (I also have the phase bridge installed). 

Since the problem seemed to lie in the ISY and an upgrade from 5.0.15A was available, I downloaded and installed 5.0.16C. No change. I do, however, now have a blank error message window that pops up when the Admin Counsel is started, along with a long-standing error message about the hidden open-close sensor that has a 24-hour heartbeat.

I tried adding new devices under Link Management, ignoring the "already added" message and keeping all the established links. I could then control the Insteon devices from the Admin Counsel. After deleting and re-adding re-linked controllers to my scenes, the scenes also started functioning again.

So now I have a spare $100 PLM and not a clue as to what caused the problem in the first place. Any ideas? What should I look for if it happens again?

 

[lilyoyo1]

24 minutes ago, Thomas Roach said:

My house is functioning again, but I'd like some ideas to diagnose the problems if they reoccur. I don't know all the ins and outs of the system, and I really do not want to devote myself to in-depth study. I just wanted some help as I continue to grow old.

Here is a summary of events, some possibly irrelevant:

I started adding POE IP cameras and an NVR to my network, assigning ports in the 25000 range.

Alexa began having issues turning off lights on Insteon dimmer modules. I often had to repeat commands.

I established a dynamic DNS account or external access to the cameras, using software already present in my LinkSys router.

The ISY suddenly stopped controlling all Insteon switches and relays. It would update the status on the counsel, but commands produced a "Cannot Communicate with XXXXXXX. Please Check Configuration" message. X-10 devices still worked. The mini-remote pad also worked so I had manual control.

I read about issues with the PLM at the 2-year point. Although my PLM is 16 months old, I tried restoring it without success and then ordered a new PLM from Amazon.

I substituted the new PLM and used the "Restore PLM" command. The system continued to act in the same way. I reinstalled the original PLM and turned off all power to the new camera system, unplugged everything, and checked the whole-house surge protector (I also have the phase bridge installed). 

Since the problem seemed to lie in the ISY and an upgrade from 5.0.15A was available, I downloaded and installed 5.0.16C. No change. I do, however, now have a blank error message window that pops up when the Admin Counsel is started, along with a long-standing error message about the hidden open-close sensor that has a 24-hour heartbeat.

I tried adding new devices under Link Management, ignoring the "already added" message and keeping all the established links. I could then control the Insteon devices from the Admin Counsel. After deleting and re-adding re-linked controllers to my scenes, the scenes also started functioning again.

So now I have a spare $100 PLM and not a clue as to what caused the problem in the first place. Any ideas? What should I look for if it happens again?

 

You really should take the time and read the wiki and isy cookbook as knowing how your system work will be the best thing for getting it up and running (when things happen) as well as preventing issues from the start. 

We can assume what the issue is and you'll probably get a different response from each member here, which can make troubleshooting harder if you don't take the time to learn what you are using.

The issue was probably never your plm which is why things continued. Most jump on the plm first as it's easiest to blame when there are normally other things going on. Most likely one of the new added equipment was causing noise on your powerline causing the signal to lock up.

[Goose66]

Probably not helpful, but that’s pretty much the world of Insteon. I’ll have everything working just swimmingly for months and then all of a sudden everything will go to $h!te. Been that way for the 15+ years I’ve had Insteon. There are absolutely no tools for debugging Insteon signaling problems and there never have been. These days I just grin and bear it and in a week or so things will return to normal. 
I know it makes no sense, especially coming from an engineer, but I can only bang my head against the wall for so long before just going with the flow. If proper tools were ever made available to diagnose Insteon signaling, I would be all over it, but until then I just live with it until I have the money to scrap it all and build a whole new system.

[larryllix]

Quick guess is you lost a few links to your devices. It takes at least one link for each direction so one-way might still work.

Factory reset any device and then restore it from the admin console. Takes about 15 seconds each end.

Battery devices must be placed in linking mode before restore.

Sent using Tapatalk

[Thomas Roach]

It seems that the issues are happening again. The ISY refused to generate an error log, but I captured a Level-3 event listing.

The first listing shows the ISY failing to turn on a switch and the results of a Query. It also shows the switch being tripped by the mini-keypad. Finally I went to link management, clicked add, and hit the set button on the switch. After that process, the ISY could once again control the switch.

The second listing is another add, links, hit set buttons, and finish (keeping links each time). those devices also respond now.

Any insights?

ISY-Events-Log.v5.0.16C__Sun 2020.03.01 04.35.45 PM.txt ISY-Events-Log.v5.0.16C__Sun 2020.03.01 04.38.56 PM.txt

[larryllix]

1 hour ago, Thomas Roach said:

It seems that the issues are happening again. The ISY refused to generate an error log, but I captured a Level-3 event listing.

The first listing shows the ISY failing to turn on a switch and the results of a Query. It also shows the switch being tripped by the mini-keypad. Finally I went to link management, clicked add, and hit the set button on the switch. After that process, the ISY could once again control the switch.

The second listing is another add, links, hit set buttons, and finish (keeping links each time). those devices also respond now.

Any insights?

ISY-Events-Log.v5.0.16C__Sun 2020.03.01 04.35.45 PM.txt 8.52 kB · 1 download ISY-Events-Log.v5.0.16C__Sun 2020.03.01 04.38.56 PM.txt 9.71 kB · 0 downloads

If there are no errors logged in the file, ISY kind of craps out and doesn't report anything.

[Michel Kohanim]

@Thomas Roach,

If clicking on the set button on a switch fixes the problem, and if you haven't changed the PLM, the the issue is with the switch or signal noise related.

With kind regards,

Michel

[Thomas Roach]

21 minutes ago, Michel Kohanim said:

@Thomas Roach,

If clicking on the set button on a switch fixes the problem, and if you haven't changed the PLM, the the issue is with the switch or signal noise related.

With kind regards,

Michel

It's not just clicking on the set button...

It's going to the Link Management menu, using the Start Linking command, and then holding down the set button to put the device in linking mode.

It's then adding the Already Added devices while Keeping Existing Links.

Nor does it make sense for it to be the switch when 5 devices go out at once.

If it's signal noise related, then why am I getting the responses captured in the Event Viewer? And why does it suddenly start working again once the ISY has relearned the links?

Not knowing the structure of this system or where things are stored, my suspicions are that the links table is being corrupted. If this is stored on the SD card, then it could be as simple (or complex: what's involved in replacing the card?) as a defective card.

I've worked in machine language on the Z80 processors, but that was 40-some years ago. I can tear this thing apart if I wanted to invest considerable time into understanding it. But I really hoped I was buying a consumer-level controller, not an experimental kit. If no one else has had this problem and no one can readily interpret the events captured by the event viewer, then I will reconsider my options.

 

[lilyoyo1]

8 hours ago, Thomas Roach said:

It's not just clicking on the set button...

It's going to the Link Management menu, using the Start Linking command, and then holding down the set button to put the device in linking mode.

It's then adding the Already Added devices while Keeping Existing Links.

Nor does it make sense for it to be the switch when 5 devices go out at once.

If it's signal noise related, then why am I getting the responses captured in the Event Viewer? And why does it suddenly start working again once the ISY has relearned the links?

Not knowing the structure of this system or where things are stored, my suspicions are that the links table is being corrupted. If this is stored on the SD card, then it could be as simple (or complex: what's involved in replacing the card?) as a defective card.

I've worked in machine language on the Z80 processors, but that was 40-some years ago. I can tear this thing apart if I wanted to invest considerable time into understanding it. But I really hoped I was buying a consumer-level controller, not an experimental kit. If no one else has had this problem and no one can readily interpret the events captured by the event viewer, then I will reconsider my options.

 

It is a consumer level controller. Troubleshooting HA (as troubleshooting anything) does require one to be willing to take the time to understand what you are using. Not to come across as sounding like a smart alec, if that's not something you're willing to do, this isn't something to invest time in. 

[Thomas Roach]

So no one knows why the ISY would suddenly start issuing commands to 3E.33.FE instead of 3E.1C.87?

And no one knows where these addresses are stored?

And there are no diagnostic flowcharts or procedures?

 

[larryllix]

39 minutes ago, Thomas Roach said:

So no one knows why the ISY would suddenly start issuing commands to 3E.33.FE instead of 3E.1C.87?

And no one knows where these addresses are stored?

And there are no diagnostic flowcharts or procedures?

 

Those addresses are unique and nobody else has them. Most never read the event log or need to.

The addresses are stored inside ISY firmware, in the PLM, and the respective devices having those addresses.

There is a wiki full of information, as well as some troubleshooting techniques and suggestions.

[Thomas Roach]

7 minutes ago, larryllix said:

Those addresses are unique and nobody else has them. Most never read the event log or need to.

The addresses are stored inside ISY firmware, in the PLM, and the respective devices having those addresses.

There is a wiki full of information, as well as some troubleshooting techniques and suggestions.

The addresses are unique, but why would the ISY suddenly start using the wrong address? (There is a 3E.33.FE, but it was not the device I was commanding on the Admin counsel.)

Where is there any documentation on the PLM? Does it have processing capabilities or it strictly a modem? Does it have storage?

Where is the ISY994iz "firmware" stored then: in cache, in ram, on board, or on the SD? The wiki mentions SD card replacement for ISY99i, but do those procedures pertain to the ISY994iz? For that matter, can the ISY994iz handle a 32Gb or greater card, or must I replace it with one 16Gb or less like the ISY99i?

BTW addresses are NOT stored in the event log, as I have found to my dismay. If needed,  they must be captured via the Event Viewer at the Level 3 setting.

None of the troubleshooting (or even documentation} in the Wiki appears to address this problem.

[lilyoyo1]

The plm is strictly a modem. The only thing it does is send out the insteon command to insteon devices. 

The isy firmware is stored on the SD card. All Isy's are the same. They just have additional capabilities. 

A quick Google search bought up this link for your question

 

[larryllix]

8 hours ago, Thomas Roach said:

The addresses are unique, but why would the ISY suddenly start using the wrong address? (There is a 3E.33.FE, but it was not the device I was commanding on the Admin counsel.)

Where is there any documentation on the PLM? Does it have processing capabilities or it strictly a modem? Does it have storage?

Where is the ISY994iz "firmware" stored then: in cache, in ram, on board, or on the SD? The wiki mentions SD card replacement for ISY99i, but do those procedures pertain to the ISY994iz? For that matter, can the ISY994iz handle a 32Gb or greater card, or must I replace it with one 16Gb or less like the ISY99i?

BTW addresses are NOT stored in the event log, as I have found to my dismay. If needed,  they must be captured via the Event Viewer at the Level 3 setting.

None of the troubleshooting (or even documentation} in the Wiki appears to address this problem.

What makes you think ISY is addressing your modem with two different addresses?  Look in your device summary and find out what device each address really is.

[DennisC]

Next time try right clicking the switch and selecting restore. If the problem is corrected by doing this there is probably noise on the network corrupting the device. Then it is up to you to find the issue.

[lilyoyo1]

9 hours ago, Thomas Roach said:

So no one knows why the ISY would suddenly start issuing commands to 3E.33.FE instead of 3E.1C.87?

And no one knows where these addresses are stored?

And there are no diagnostic flowcharts or procedures?

 

Experience is your diagnostic flowchart. Different situations require different steps.

If something appears to be communication based with a full system, I'm looking at my environment around the plm. If it's a single device, I'm looking at the environment around the switch. There are plenty of posts on here for both that I'm not going into details of different steps. 

If a device is acting up or I'm getting unexpected results, I will factory reset, test, and re-add. If do get the same probably after re-adding, I look at my system. It may be a misconfigured device or improperly set program. 

[Thomas Roach]

1 hour ago, larryllix said:

What makes you think ISY is addressing your modem with two different addresses?  Look in your device summary and find out what device each address really is.

Because the Event viewer showed commands addressed to 3E.33.FE instead of 3E.1C.87, the address of the device I intended to command and the address used after I had the ISY "relearn" the link.

3E.33.FE is another switch, one that 98% of the time is controlled at the same time as 3E.1C.87 (they are both wall switches for outside lights, but in different buildings).

 

[larryllix]

Because the Event viewer showed commands addressed to 3E.33.FE instead of 3E.1C.87, the address of the device I intended to command and the address used after I had the ISY "relearn" the link.

3E.33.FE is another switch, one that 98% of the time is controlled at the same time as 3E.1C.87 (they are both wall switches for outside lights, but in different buildings).

 

That sounds confused. If it is the address of the device you are attempting to command then it is not your PLM address. It can't be both.

 

Is there actually something that is not functioning?

 

 

 

Sent using Tapatalk

 

 

 

[Thomas Roach]

1 hour ago, lilyoyo1 said:

Experience is your diagnostic flowchart. Different situations require different steps.

If something appears to be communication based with a full system, I'm looking at my environment around the plm. If it's a single device, I'm looking at the environment around the switch. There are plenty of posts on here for both that I'm not going into details of different steps. 

If a device is acting up or I'm getting unexpected results, I will factory reset, test, and re-add. If do get the same probably after re-adding, I look at my system. It may be a misconfigured device or improperly set program. 

Experience IS NOT a flowchart. Flowcharts use a logical sequence of tests based upon historical failures, equipment capabilities, and test availabilities. They are then structured in a format for sharing with those less versed in system and design familiarity.

Since neither of your two suppositions apply here (the problem did not affect the full system and DURING the problem the ISY could communicate with the affected devices and read their status; at the same time the ISY could not command at least 5 devices, then 1 device, then 3 devices), your recommendations do not seem to pertain to this issue. Again, I checked for noise. The Event Viewer also did not show evidence of excessive hops. No recent programming changes have been made. There is evidence, however, of commands directed at the wrong devices.

 

[larryllix]

Unfortunately high tech devices these days never have troubleshooting charts. By the time a team of writers finish the version the device will Have changed enough to make the docs nonsense.

Read some posts here from three years ago and already much of it doesnt apply to current day ISY. The wiki is your best bet and I doubt you digested over a thousand pages in one night. It contains many tips and tricks for troubleshooting and has had a team of writers working on it casually for years.
Windows tried this, for years now, and anybody with experience knows a cloud service can never resolve problems with your network connection. AAMOF I have never had a positive result from its automatic help system. You have to figure it out yourself, get help and understand the problem first, or just pray.

Sent using Tapatalk

[Thomas Roach]

5 minutes ago, larryllix said:

That sounds confused. If it is the address of the device you are attempting to command then it is not your PLM address. It can't be both.

 

Is there actually something that is not functioning?

 

 

 

Sent using Tapatalk

 

 

 

Where did you expect to see the PLM address?

3E.33.FE.1 is a (2466S) ToggleLinc Relay v.41, but not the device I tried to turn on in the Admin Counsel.

3E.1C.87.1 is a (2466S) ToggleLinc Relay v.41, the device I was trying to turn on but not the address used by the ISY until after I had relearned the link.

44.8C.E7.6 is a (2342-222) Mini Remote Keypad, 8 Scene v.39 that I was able to use to turn 3E.1C.87 on and off regardless.

Everything appears to be functioning normally now. However, since this issue occurred and re-occurred, there appears to be an intermittent failure... of what?

 

[Thomas Roach]

2 minutes ago, larryllix said:

Unfortunately high tech devices these days never have troubleshooting charts. By the time a team of writers finish the version the device will Have changed enough to make the docs nonsense.

Read some posts here from three years ago and already much of it doesnt apply to current day ISY. The wiki is your best bet and I doubt you digested over a thousand pages in one night. It contains many tips and tricks for troubleshooting and has had a team of writers working on it casually for years.
Windows tried this, for years now, and anybody with experience knows a cloud service can never resolve problems with your network connection. AAMOF I have never had a positive result from its automatic help system. You have to figure it out yourself, get help and understand the problem first, or just pray.

Sent using Tapatalk
 

I shouldn't need to digest one thousand pages at all, since most of the wiki deals with equipment I do not possess. I have read through what appear to be the relevant sections and used the search engine.

This could still be a PLM issue, if it somehow is capable of corrupting the ISY address database. Or it could be a bad memory location either in the SD card or the ISY's basic memory. It could also be a rare bug in the firmware, or a Portal command that was either scrambled or the result of server errors, or something I haven't even considered yet.

 

[lilyoyo1]

1 hour ago, Thomas Roach said:

Experience IS NOT a flowchart. Flowcharts use a logical sequence of tests based upon historical failures, equipment capabilities, and test availabilities. They are then structured in a format for sharing with those less versed in system and design familiarity.

Since neither of your two suppositions apply here (the problem did not affect the full system and DURING the problem the ISY could communicate with the affected devices and read their status; at the same time the ISY could not command at least 5 devices, then 1 device, then 3 devices), your recommendations do not seem to pertain to this issue. Again, I checked for noise. The Event Viewer also did not show evidence of excessive hops. No recent programming changes have been made. There is evidence, however, of commands directed at the wrong devices.

 

There isn't a one size fits all approach to things when it comes to automation. The statement I made isn't about the definition of a flow chart. It's in reference to your lack of desire to learn your system which is a major impediment towards troubleshooting.

My advice wasn't in reference to your actual issue. It was an example in reference to how I approach problems that I need to troubleshoot. The same could apply to you if you took the time to learn. 

 

[Thomas Roach]

52 minutes ago, lilyoyo1 said:

There isn't a one size fits all approach to things when it comes to automation. The statement I made isn't about the definition of a flow chart. It's in reference to your lack of desire to learn your system which is a major impediment towards troubleshooting.

My advice wasn't in reference to your actual issue. It was an example in reference to how I approach problems that I need to troubleshoot. The same could apply to you if you took the time to learn. 

 

Since no one else seems to have experienced this issue (or isolated it if they have), then either I abandon the system, fix it, or put on the popular band-aids every time it happens again.

Now let's talk about learning the system. Where's the source code, is it on GitHub? The schematics? What's the programming language, or the processor for that matter. Do any breakdowns of the database exist, since it looks more and more like a pointer issue? Where do I find the link structure and PLM protocols? Where's a good spot to patch in some diagnostic programs, say to get a better grasp on the actual communications instead of summaries and interpretations? How about the Portal protocols? The information I need does not appear to be readily in the wiki, nor is the wiki up to date.

And yes, that is the level of learning that I DID NOT want to get into if I could avoid it. I do not want to re-engineer the firmware. I do not want to learn about power and other control systems for components that I have a slim chance of recouping my investment costs during my remaining lifetime. I just want my lights and garage door to work, especially when I'm not home or I'm incapacitated.

 

[Teken]

@Thomas Roach

I'm only going to offer some reference points and hope some of this will be helpful to you so here is the long version.

- Micro SD Card: The maximum capacity to be used is 32 GB.

- Trouble Shooting: It goes without saying one must focus on one item at a time. Doing otherwise will make identifying root cause extremely hard if not impossible. If this was my site and based on your initial feedback about adding in new hardware to the homes infrastructure. I would immediately remove all of these new devices to at least isolate the condition. Next, below is how I normally trouble shoot and this stems from having installed hundreds of sites over the course of ten years.

- Bridging / Coupling: Always verify that the split single phase electrical system is bridged / coupled by following using the full users manual for that specific device to complete the *4 Tap* beacon test. I always complete the 4 tap test in every room, floor, zone, etc and note any problems.

- Hard Reset: Any new installation prior to the physical installing I hard reset the device per the full users manual. Doing so ensure any test links, test programming, are removed. Anytime a device starts to act odd, none responsive, slow to react, etc. In an existing system I delete the device, hard reset, add it back, and enroll it back to any scenes. This at least gives you a clean slate to reference to.

- Loads: Every home is unique and has varying degrees of noise makers / signal suckers. Regardless of what anyone tells you just because Insteon is dual band (RF&PLC) neither of these will ever supersede the need to remove, replace, filter, said noise makers / signal suckers. Over the years from observing various loads the most common effects are these in no specific order of importance or relevance:

Light turns on, but won't turn off, Lights react slowly to turn on, lights never turn on, the switch makes a beep / noise, switch LED ramp up and down, KPL buttons pulse / flicker. All of these are the most common issues seen with the hardware when one of several conditions exist. Also, never assume an existing load that worked perfectly fine for years isn't the root cause. I don't need to preach to you but we no longer live in an era where things are built to last, or to quality.

Generally speaking any light bulb that pulses, flickers, strobes, buzz, hum, is going to be a problem. Keep in mind on the rare occasion even when none of the indicators exist that bulb (can) is secretly causing disturbance within the Insteon network.      

- Load Type: It should be noted not every Insteon device supports LED bulb technology. While others call out only resistive loads or worst case a minimum load is required to function.

- Firmware: Generally speaking one should always be using the latest firmware on the controller. But, one should never just upgrade to the next Beta / RC while existing issues persists. There are too many elements to consider never mind this is going to add another moving part to the equation that you must consider and compensate. Your UI and Firmware in the *About* should always match. The instructions to clear the Java cache and use the correct Launcher / Admin need to be used otherwise this gives you another headache to worry about.

- Filters: Using filters where it makes sense always needs to be considered in a highly electronic homestead. You can use any of the Insteon branded or X10-Pro for those 20 amp higher loads. Even the smallest USB charger from a cell phone can generate untold grief to you and the Insteon network. 

In the same vain those who have and use ceiling fans may be impacted by CEMF and such appliances (IF) identified as locking up or causing damage to a switch etc. You may try to install a *RC-Snubber*. This device is wired in parallel normally at the fixture but can also be installed at the switch. This specific device absorbs the reverse voltage spikes from the fan / motor.

2413S PLM: What can be said about a device that was poorly designed and built with the cheapest parts known to man?? If you have the latest iteration, know moving forward its been advertised as having better parts! Now you have a spare so it simply goes into the parts bin until needed.

2466S: This is probably the last known single band switch Smartlabs makes. It hasn't been updated for years and thus offers very little in ways to better technology and performance. As noted up top this device is NOT spec'd to use LED bulbs only incandescent / inductive loads. Unless you're fixed to this look and feel replacing these with the latest generation of SwitchLinc will offer higher reliability, performance, and service life. 

Voltage: Every day your home will experience voltage sags vs voltage surges. The latest Insteon technology now supports 120-240 VAC and many have listed as using some form of surg protection. The 2466S is still a single band 120 VAC device which does not incorporate any advertised surge protection. The home is constantly seeing surges / spikes from the likes of fans, sump, freezer, fridge, HVAC, etc.

Anytime you see a lock up more often than not this is related to a sag / surge event. Keeping in mind a voltage sag is one of the most detrimental electrical event your home can ever have. As when voltage drops, current rises and thus the end result is the magic smoke to be released. There is nothing you can do to protect your home from a voltage sag unless you have a online 24.7.365 UPS.

Which leads to the below ->

SPD: Every home should have at the minimum a Type 2 SPD (Surge Protective Device) installed at the service panel. Ideally all three layers should be used as each SPD only offers protection within a well defined region and does not offer the same protection within the home. This is why a Type 1 SPD should be installed at the service entrance to absorb the bulk of the surge before it enters the building electrical system. A Type 2 SPD should be installed at the service panel while a Type 3 *Point of Use* should be installed at the or near the target devices. Following such a layered approach offers the most protection and can be the difference between pass / fail. As noted up above a SPD of any type will not protect a home from a voltage sag except when it incorporates an AVR (Automatic Voltage Regulation) which some UPS AVR rated systems offer

PLE: If your home is using any form of Power Line Ethernet and not to be confused with POE (Power Over Ethernet) its been seen and reported depending on version, hardware, model, brand. These devices can interrupt the PLC signal traveling down the electrical wiring. 

Scene Test: You can never go wrong by using the scene test to help determine how robust / not your system is. As you noted watching the level 3 logs while you test various pieces of hardware is also helpful. If your lady friend is available doing scene test makes this easier and faster to complete.

Flashing LED: If any device flashes its LED indicating whether it be the switch / remote. This normally indicates a piece of hardware is missing from the system and its best to delete, hard reset, and add back the offending hardware.

TSTAT / Motion Sensor: If you're rocking some of the oldest hardware from Smartlabs / Insteon and (IF) you have any T1700 ~ T1900 TSTATS which use the dongle. Be aware there was a period where that dongle would flood the Insteon network. Older motion sensors when the battery is low will also flood the network with rapid On's. Any battery operated device regardless of production date should be inspected to insure the battery is at the correct voltage levels. Unless the vendor has designed the hardware in such a way to compensate for a low voltage condition you can run into the first example I called out above.

Good luck, and keep pressing on . . .