Help understanding insteon comm messages

[johnnyt]

I'm trying to understand event viewer entries a little better in the hope it will help me understand comm problems and potential fixes better.

 

The trace below is an excerpt from the attached file that was created by doing a Show Device Links Table for an Icon Relay (the value brand version of the ApplianceLinc that's no longer being sold) with address 16.AB.AF. It is in a place where it doesn't always do what it's told.

 

I can see that there are comms issues with Max Hops=3, Hops Left=0 and these happen even when I put an access point on the same circuit. Q1: Shouldn't an access point fix that?

 

Q2: Why would the commands alternate so consistently between hops left=2 and hops left=0, i.e. perfect one time and terrible the next? Wouldn't things be more clearly one way (hops left=2) or the other (hops left=0)? why no hops left=1 sometimes?

 

Q3: It also looks to me like a number of commands are duplicates or an echo of a previous command - is that right? If so, are they from the RF insteon signal, which I think I read somewhere are a half second (or is it half a Hz) after the powerline signal?

 

Q4: Generally speaking, can/should I just add more Access Points or can/will they make things worse sometimes? Should I stick to the minimum needed, i.e. one per phase and only where needed for RF only devices.

 

Currently I have 5 access points installed, 2 on one phase and 3 on the other. I sometimes use a spare PLM I keep as a backup as an access point for testing (I assume it works fine for that purpose, is that right?). I have very few dual band devices and metal junctions boxes that render all but the wall wart variety (Lamplinc and IOLinc) useless.

 

Any info would be appreciated.

 

 

Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:14 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:14 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:14 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F8

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F8 06 PEEK (F8)

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F9

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F9 06 PEEK (F9)

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 00 PEEK (00)

Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:16 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:16 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:16 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FA

Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:16 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FA 06 PEEK (FA)

Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 1E PEEK (1E)

Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:17 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 1E PEEK (1E)

Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:17 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:17 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:17 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:17 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FB

Tue 04/15/2014 06:43:17 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FB 06 PEEK (FB)

Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 48 PEEK (48)

Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:18 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 48 PEEK (48)

Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B 48 PEEK (48)

Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:18 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:18 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:18 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:18 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FC

Tue 04/15/2014 06:43:18 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FC 06 PEEK (FC)

Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B AD PEEK (AD)

Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:19 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:19 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:19 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FD

Tue 04/15/2014 06:43:19 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:19 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:19 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B FD 06 PEEK (FD)

Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B FF PEEK (FF)

Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:20 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B FF PEEK (FF)

Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:20 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 04/15/2014 06:43:20 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B FE

Tue 04/15/2014 06:43:20 PM : [ Time] 18:43:22 1(0)

Tue 04/15/2014 06:43:20 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:20 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 04/15/2014 06:43:20 PM : [uNKNOWN ] 02 AF

ISY-Events-Log.v4.1.2__Tue 2014.04.15 06.44.18 PM.txt

[LeeG]

I don’t know to stop this but can explain what is happening.

 

A Set MSB command (0x28) is issued and gets an ACK with Hops Left=2 which is as good as it gets.

 

Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:14 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

Tue 04/15/2014 06:43:14 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:14 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

The next command, a Peek (0x2B), is issued. Now the problem. A duplicate ACK from the previous Set MSB command (0x28) is received with a Hops Left=0.

 

Tue 04/15/2014 06:43:14 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F8

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F8 06 PEEK (F8)

 

This is a duplicate ACK from the previous Set MSB command.

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

This is the ACK from the Peek command.

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

The duplicate ACK gets the analysis of the responses out of sync. The ISY does a recovery process by going back to the Set MSB.

 

Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 28 0F

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 28 0F 06 SET-MSB(0F)

 

Unfortunately two duplicate ACKs from the previous Peek with a Hops Left=0 are now received.

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 2B A2 PEEK (A2)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

Now the expected Set MSB ACK with a Hops Left=2 is received

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

A Peek is issued but this gets a duplicate ACK with Hops Left=0 from the previous Set MSB

 

Tue 04/15/2014 06:43:15 PM : [iNST-TX-I1 ] 02 62 16 AB AF 0F 2B F9

Tue 04/15/2014 06:43:15 PM : [iNST-ACK ] 02 62 16.AB.AF 0F 2B F9 06 PEEK (F9)

 

Tue 04/15/2014 06:43:15 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 23 28 0F SET-MSB(0F)

Tue 04/15/2014 06:43:15 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

 

Followed by the expected ACK with Hops Left=2 for the previous Peek.

 

Tue 04/15/2014 06:43:16 PM : [iNST-SRX ] 02 50 16.AB.AF 1E.48.AD 2B 2B 00 PEEK (00)

Tue 04/15/2014 06:43:16 PM : [std-Direct Ack] 16.AB.AF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

The explanation for the duplicate ACKs would only be a guess. They may be the result of the old ICON Relay or the result of an Insteon network that does not pick up on the fact that the ACKs with Hops Left=0 are actually duplicates from a command that has already completed and should be ignored. The old Set MSB/Peek/Poke command sequence used by the older devices could be a contributor. Could be the PLM should pick this up and ignore the duplicates. What part do the metal boxes have to do the duplicates?

 

Lots of possibilities and no good answers.

 

I would start the analysis by using an I2CS device where the ICON Relay now sits. The I2CS device does not support old Set MSB/Peek/Poke commands so that is an easy way of eliminating one of the variables. If the I2CS device does not produce the duplicate ACKs then I would put the old ICON Relay in the recycle box and stay with the newer devices.

[johnnyt]

The explanation for the duplicate ACKs would only be a guess. They may be the result of the old ICON Relay or the result of an Insteon network that does not pick up on the fact that the ACKs with Hops Left=0 are actually duplicates from a command that has already completed and should be ignored. The old Set MSB/Peek/Poke command sequence used by the older devices could be a contributor. Could be the PLM should pick this up and ignore the duplicates. What part do the metal boxes have to do the duplicates?

 

Lots of possibilities and no good answers.

 

I would start the analysis by using an I2CS device where the ICON Relay now sits. The I2CS device does not support old Set MSB/Peek/Poke commands so that is an easy way of eliminating one of the variables. If the I2CS device does not produce the duplicate ACKs then I would put the old ICON Relay in the recycle box and stay with the newer devices.

Thanks, LeeG. The problem is not limited to the Icon Relay. I've attached event viewer logs for device link query of a v41 i2CS KPL and a v.36 KPL. While not on the same circuit both occasionally suffer from not doing what they're told although less often. The v.36 KPL seems to struggle just as much as the Icon Relay here while the v41 KPL doesn't seem to struggle as much with hops left but there are a number of unexpected responses. Things certainly finish faster with the i2CS device. It's quite painful waiting for a 70-80 link KPL to get through it's table - and with the problems I'm having it usually needs more than one attempt in order to get through it.

 

To compare, I also queried the device links table of an v36 IOLinc that is about 30 feet away from the PLM on the same phase and not in what I consider a problematic area of the house. A few hops left=0 are seen but they appear to be related to the echo / duplicate commands that occur.

 

Another thing I noticed as I check device links tables is that most I've checked so far end up with record mismatches when compared to the ISY links tables. I went through a round of device updates about a year ago after finding mismatches in a number of devices that I never got to the bottom of and just let go. I might revive that thread with some up to date info (viewtopic.php?f=27&t=10577). I'm wondering, though, if it wasn't/isn't related to this issue and perhaps if I can fix this the other problem won't happen.

 

The reference to metal junction boxes was just to say that any hard wired dual band devices I have, such as the v41KPL I queried for this, do not add (or benefit) notably, if at all, to the RF portion of my insteon network. Not saying it adds anything; just putting it out there as I know this scenario is not common in the US.

ISY-Events-Log.v4.1.2__IOLincv36.ClosetoPLM.txt

ISY-Events-Log.v4.1.2__KPLv4.1DeviceLinksQuery.txt

ISY-Events-Log.v4.1.2__KPLv36DeviceLinksQuery-partial.txt

[IndyMike]

Hello Johnnyt,

 

Your V.36 KPL and IOLinc are being read in standard message mode (I1). Both of these devices are extended message capable (I2).

 

You apparently have your ISY set to "Automatic" message mode where it selects what it believes is the most compatible mode (I1 or I2). This is what UDI recommends.

 

You can "force" I2 communication by going to Link Management/advanced options and selecting "device reported" mode. The ISY should then use extended messaging (I2) during your link table reads. I have been using this since I2 came out - but it is not the recommended mode.

 

This will speed the link table reads by 8X.

 

It may not be compatible with your Icon switches (won't do any harm). The newer Icons have a smaller link table and may generate an error "Unexpected Response (i.e. DB range): ignored" when read using I2. Switching back to automatic mode will resolve this.

[LeeG]

The Icon Relay is an extreme on the bad end with duplicate messages after practically every message. The I/O Linc is almost an extreme on the good end with 144 Standard messages and 11 duplicates. The V36 KPL is about in the middle with 80 messages and 44 duplicates. The surprise is the V41 KPL

which is an I2CS device with 36 Extended messages, 8 Standard message duplicates and 6 Extended message duplicates. Although not an absolute I think the duplicates with the I2CS device means the duplicates are not caused by the individual device.

 

I would look at the circuit layout. Where are the better devices located compared to the bad devices. Where are the Access Points located regarding the good and bad devices. Is the PLM newer or older. I have no guess as to why the duplicate messages but with duplicates on Standard and Extended messages across several devices I would look at the Insteon network in general rather than an individual device such as the Icon relay or I2CS KPL.

[johnnyt]

You apparently have your ISY set to "Automatic" message mode where it selects what it believes is the most compatible mode (I1 or I2). This is what UDI recommends.

 

You can "force" I2 communication by going to Link Management/advanced options and selecting "device reported" mode. The ISY should then use extended messaging (I2) during your link table reads. I have been using this since I2 came out - but it is not the recommended mode.

what's the downside or risk of using i2? why is it not recommended? is there any chance of device corruption that can't be fixed with a return to i1 and a restore?

[johnnyt]

One downside of using the "Device Reported" setting for i2 support and the fact that it can't be set at the device level is that it doesn't work with my Icon devices when reading device links table. ISY ends up using i2 and sending extended messages, which doesn't work. I guess it's not a big deal to change it back and forth when I'm reading device links table given it's not something I do often. However is it safe to say this inability to truly know the i2 compatibility of the device affects things when setting/changing scenes with devices that ISY interprets as i2 compatible even though they're not?

 

Also, can someone clarify whether the i1/i2 setting impacts - positively or negatively - the day-to-day use of my devices, i.e. just turning them on/off and executing scenes.

 

I will say things certainly do work much better with i2 for devices that support it when it comes to reading device links table. Turns a 20+ minute process for my KPLs that sometimes has to be restarted into a 5 min affair.

[LeeG]

Forcing I2 (Extended messages) may not work but does not physically damage the device. There are devices that indicate supporting an I2 Engine which is accurate for device configuration but those same devices do not support I2 for link database management. Most of the issues will be apparent in that the device no longer sends state change messages or some KPL buttons no longer send state change messages. Those devices can have issues with Scenes as the link records needed to support Scenes are not written or written in the wrong location. As long as you understand how the link database works, how to evaluate the accuracy of the link database records, where the link records should be written, and so on. I2 does improve performance of reading/writing of link records for the devices where it works.

 

Note that changing to I2 is not the solution to the duplicate record problem as duplicates are happening on an I2CS device and it’s Engine accurately works with Extended commands. Something is producing the duplicate records or they are not being seen as duplicates. The overall communication of your Insteon network is good for the devices that have been traced. If the duplicate records can be eliminated the Insteon network would be fine.

 

I thought I had posted this earlier but I must not have clicked Submit. Using I2 has no affect on Insteon Direct device On/Off as these are all Standard commands. It could affect Scenes if the link records are not written in the correct location.

[johnnyt]

Thanks, LeeG. I may just use i2 when I need to read/restore devices that support it.

 

Earlier today I removed all but 2 Access Points and there are still duplicate messages. In fact I noticed what looks like two duplicates in one case. See attached screenshot.

 

I may try to unplug or pull the air gap out of all my dual band devices and pull out all a phase coupling AP to see if it goes away then add in one DB device at a time...

[LeeG]

There is at least one case in the earlier traces where two dups of same message was traced. I like your idea about pulling the Dual Band devices, adding them back one at a time. Let us know how that goes. I wish I had an idea of what is causing the dups but have no idea.

[IndyMike]

Thanks, LeeG. I may just use i2 when I need to read/restore devices that support it.

 

Earlier today I removed all but 2 Access Points and there are still duplicate messages. In fact I noticed what looks like two duplicates in one case. See attached screenshot.

 

I may try to unplug or pull the air gap out of all my dual band devices and pull out all a phase coupling AP to see if it goes away then add in one DB device at a time...

 

johnnyt,

 

That's the point I was trying to get you to. I guess I misunderstood what you were trying to accomplish. I thought you had link table mis-matches and were trying to correct using I1 messages. In my experience, I2 is actually more reliable in reading/writing the link tables. You are writing the tables 8x faster and are therefor less likely to have problems with transient noise (motors starting, etc).

 

If you are trying to eliminate the multiple responses, I agree that disabling the dual band devices is a good approach. I do not see any doublet/triplet responses in my system. I have very few (3) dual band devices installed and have a hardwired coupler at the PLM. No clue if this has anything to do with my NOT seeing multiple responses.

 

Other than slowing down the read process, I'm not sure that the duplicates harm anything.

[ELA]

Hello Johnnyt,

 

I have experienced this "Duplicate" message phenomenon a few times in the past.

The first time was with a problematic APL. It was having difficulties communicating. When monitored it exhibited these "duplicate" messages. That APL eventually failed and had to be replaced.

 

During investigations at that time I found that I could readily reproduce that behavior with a known good device by purposely creating a marginal communications environment.

In a more recent test I monitored a device immediately adjacent to a sending PLM using the extended "2F" command.

When the communications environment was pristine the "duplicate" messages were never seen. I then moved that receiving device only 8 ft away from the sender ( as the crow flies) and about 30ft electrically. I moved it to an outlet with a computer and monitor that are large signal suckers (purposely left unfiltered).

I would now readily get the "duplicate" messages.

 

From my testing I am hesitant to refer to these extra message reports as duplicates since I have found that they are not so much extra messages as reports of other hops that are normally present, but not normally reported. I have referred to them as extraneous reports.

 

The problem with the ISY logging is that it only provides a 1second resolution. I have logged these messages with a finer resolution and that shows that these extraneous reports occur at or near the normal time of the other hops that are always occurring when a message is sent with 3 max hops. Under normal circumstances the PLM only reports the message up to the host at the hop number and time occurrence that it first detects a legitimate message.

 

Under abnormal communications situations the PLM is reporting some the other hops up to the host as well.

It is not really slowing anything down ,as those hops are always present, just not normally reported.

 

Not being privy to the the lowest level details of Insteon I am left to speculate as to why this occurs. I believe that it may be a timing issue caused by various delays in the Insteon network. These delays can be aggravated by a large capacitive load ( signal sucker) such as I introduced in my test. There is a finite time window in which the protocol expects to see hops. I am speculating that If they should fall just outside that window they may then be reported up to the host whereas they would not normally.

 

I have observed "2F" message exchanges on an oscilloscope over extended periods in a marginal environment and you can observe time shifts as well as simulcast variations that occur at the time that the extraneous reports occur.

 

As long as you are not experiencing outright communication failures I would chose to ignore it. As always I recommend identifying and filtering any large signal suckers to help a network perform at its best.

[johnnyt]

Thanks for your insights, ELA and IndyMike,

 

I may spend a little time focusing on potential signal suckers I've overlooked. I already have about a dozen filters on various loads, including computers, UPS'es, amplifiers (sonos, powered sub, AV equipment), motors (fridge, HRV freezer, dehumidifier, microwave oven) but I've left a few wall warts alone (2 cordless phone charging cradles and an ipad charger come to mind right now).

 

As I don't have any spare filters handy, what existing filters might be worth sacrificing to isolate the phone/ipad chargers? I know I'm stealing from Peter to pay Paul but is there a chance I don't really need filters on one or more of my fridge, freezer, HRV, microwave, and dehumidifier? I think I was doing it to filter out noise more than signal sucking, particularly since they are on their own circuits (except for dehumidifer). I don't have a way to test for noise so was only guessing they might be a source of problems in the first place. I also recently heard that induction motors, often used in fridges and HVAC equipment (like HRV?), are not a major source of noise...

 

ELA, I can't find the great post you had on signal suckers. (Of course, you've had a few great posts on comms issues but I'm thinking of the one where you provided a list of signal suckers and their relative signal sucking ability.) Would you be able to point me to it?

 

Finally, it's my understanding filters are signal suckers too and, therefore should only be used on something that is a known (worse) signal sucker or noise maker. Is that valid?

[ELA]

johnnyt,

I would not move any of the filters you have listed for the chargers. So many things are signal suckers it is very difficult without the ability to measure them to gauge what equip. might require them. Hopefully the list will be of some help.

 

The list you referred to is now available here along with some other info that might be helpful:

http://www.elavenue.com/insteon_test_data.html

 

Yes Filterlincs suck some signal as well so you do not want to waste them on something like a EMI filtered Surge-strip only. Unless of course there are large signal suckers plugged into it.

 

I have an Ipad charger that I have never tested because it is on a plugstrip that is already filtered for a laptop power supply ( known sucker) that is also plugged into it.

I will try to test the Ipad charger to let you know.

Addition: 4/22/14: Tested small white cube style IPAD charger and did not detect any signal sucking properties.