IO Lincs mysteriously changing state

[johnnyt]

I have problems with IO Lincs mysteriously changing state. Here's an example (that happens with more than one IO Linc)

 

First here's what's supposed to happen (and mostly does) every day at 2:59:08 AM during the summer: A program turns an IOlinc ON (along with some keypadlinc buttons) that sets my HRV to run at high speed (usually the coolest time of the day).

 

Here’s what shows up in the log:

Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs	On	 	Mon 2013/07/08 02:59:08 AM
1-MISC (Non Lighting) / HRV / HRV High Speed	Status	100%	Mon 2013/07/08 02:59:08 AM
Outside / Back KPL.G - HRV High (XLink)	Status	100%	Mon 2013/07/08 02:59:08 AM
Outside / Back KPL.H - HRV High (XLink)	Status	100%	Mon 2013/07/08 02:59:08 AM

The HRV is supposed to remain on for 2.5 hrs (until 05:29AM) when another program turns it off and that’s exactly what happens most of the time. Intermittently, though, at different times in the middle of a cycle, the IO Linc ends up OFF even though no person or program turns it off (and there's no log entry showing an OFF command was sent).

 

It's found OFF by a query that runs either every 15 mins OR every time an HVAC-related IO Linc sensor monitoring heat or AC call triggers. The latter are different IO Lincs (not the HRV ones). I've had to put this safeguard program in place to catch these mysterious, intermittent occurrences and because the IO Linc sensors don't always report their change of state. In fact I've had to set the IO Lincs with the HVAC sensors to send an X10 signal whenever the sensor state changes which triggers a second program in case the first one (set to trigger when an insteon signal is sent) doesn't run. See image further below for a screenful of occurrences of that program running. Notice that it isn't every 15 mins or less so the main program is triggering properly most of the time.

 

For those naturally inclined to say that I might be having comm issues, note that the X10 signal is making it back to the PLM. While I'm not ruling out comm issues - occasionally there is the odd Hops Left=0 - mostly the hops left = 2 in that area of the house.

 

I've reported IO Linc mystery behavior before but I didn't have enough data to offer up so either something else was pointed to or I (and likely others) rationalized that it was user error. It could well still be but I'm at a lost to know what I could be doing wrong after two years of intermittent troubleshooting and building/tweaking workarounds for this. Personally I'm inclined to think this is a hardware problem but I'm a bit stuck with coming here (instead of Smarthome) because I only have ISY captured/generated info to troubleshoot with.

 

The entries below show the query that finds the "HRV High Speed" relay OFF followed by the result of the program that triggers when HRV High Speed is OFF but should be ON

 

Scene:1-MISC (Non Lighting) / HVAC / HVAC Relays	Status	Query	Mon 2013/07/08 05:02:40 AM
1-MISC (Non Lighting) / HRV / HRV High Speed	Status	0%	Mon 2013/07/08 05:02:40 AM
Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs	On	 	Mon 2013/07/08 05:02:59 AM
1-MISC (Non Lighting) / HRV / HRV High Speed	Status	100%	Mon 2013/07/08 05:02:59 AM

 

This also happens intermittently to a different IOLinc that sets my HRV to low speed. For all I know this is happening to other IO Lincs but I don't have the extensive set of checks and notifications set up for other ones so I can't pinpoint it for those.

 

The screenshot below shows all the times (going back to mid May) that my checks/notifications have reported my HRV related IO Lincs in the wrong state.

 

The screenshot below shows all the times I was notified that my second safeguard program ran/completed - this program should never get to the point of sending these notification.

[LeeG]

The ISY Log only shows the result, not the cause but I can recreate an I/O Linc Relay having the Status marked Off falsely. It is the result of extra messages being presented to the ISY from the PLM/IO Linc. A duplicate message from the I/O Linc with Hops Left=0 (which is believed to come from the previous Query of the Sensor) comes in after the Query for the Relay is issued. It gives all the appearance of a valid response to the Query of the Relay even though it has the Status of the Sensor.

 

You can see from this event trace the line marked in Blue indicates the Status of the Relay is being marked Off. The next Query in my looping Program marks the Relay back On because the Relay never actually turned Off.

 

The last time this was analyzed I picked up a new PLM with firmware v.9B to see if the latest PLM firmware might have resolved this. It did not.

 

It is assumed the extra message is coming from a long path (many Hops) back to the PLM so the PLM does not recognize it as a duplicate since a new outbound command has been issued.

 

Unfortunately I cannot provide a solution. It appears to be an issue with Insteon Mesh Network losing track of duplicate messages but that is only supposition at present.

 

 

Mon 07/15/2013 03:09:25 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01

Mon 07/15/2013 03:09:25 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01)

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00)

Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Mon 07/15/2013 03:09:25 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00)

Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Mon 07/15/2013 03:09:25 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT)

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00)

Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Mon 07/15/2013 03:09:25 PM : [ 1C FD D5 2] ST 0

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF)

Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

 

Mon 07/15/2013 03:09:28 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01

Mon 07/15/2013 03:09:28 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01)

Mon 07/15/2013 03:09:28 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00)

Mon 07/15/2013 03:09:28 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Mon 07/15/2013 03:09:28 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00

Mon 07/15/2013 03:09:29 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT)

Mon 07/15/2013 03:09:29 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF)

Mon 07/15/2013 03:09:29 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Mon 07/15/2013 03:09:29 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01

Mon 07/15/2013 03:09:29 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01)

Mon 07/15/2013 03:09:30 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00)

Mon 07/15/2013 03:09:30 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Mon 07/15/2013 03:09:30 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00

Mon 07/15/2013 03:09:30 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT)

Mon 07/15/2013 03:09:30 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF)

Mon 07/15/2013 03:09:30 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Mon 07/15/2013 03:09:30 PM : [ 1C FD D5 2] ST 255

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat Every  5 seconds
          Set 'IOLinc I2CS-Relay' Query
          Set 'IOLinc I2CS-Sensor' Query

Else
  - No Actions - (To add one, press 'Action')

[johnnyt]

Thanks LeeG. Very interesting. (FWIW, my PLM is v9B)

 

Not sure I understand all the inner workings at play. Is this a PLM issue, an IO Linc issue, or an ISY issue?

 

In the meantime, currently my IO Linc Query Scene requests the status of 11 IO Lincs. Might breaking the query up into smaller groups/scenes help reduce the risk/occurrence of the problem by helping spread out the insteon traffic?

[LeeG]

I was running a PLM with v.98 when this first surfaced. Switching to the v.9B PLM had no affect on the result.

 

I'm not sure if this is an issue with the I/O Linc, the PLM or the overall Insteon Mesh Network. Without independent tools to analyze what is flowing over the powerline versus what is flowing over RF its difficult to point to any one element. In fact there is nothing that we as end users can look at to know if that Hops Left=0 message is a powerline message or an RF message or some combination of both.

 

This could be a more general issue with the network that is seen only with an I/O Linc because it takes two Query commands to get the Sensor and Relay status. Although there are different cmd2 values outbound which identify whether the Sensor or Relay status is being asked for, the architecture of the response (the ACK) does not carry that Sensor/Relay identifier. The application can only assume the response provided by the PLM is the response to the last command issued. The three messages below, the first message is the response (ACK) from the Sensor Query, the second message is the response (ACK) from the Relay Query. They are exactly the same except for the last byte which shows Sensor Off (00) and Relay On (FF). The third is the duplicate Sensor Query response which looks just like the others except for the Hops Left bits which say nothing about whether this is a Sensor or Relay response. The duplicate message is a structurally perfect Insteon message seen on many networks.

 

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00)

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF)

 

Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00)

 

That is a long winded response to the ISY question. The ISY has nothing to look at in the response to know whether it came from the Sensor or the Relay. When the duplicate message comes back as the response following the outbound Relay Query. The ISY has no choice but to take it as a Relay Query response even though it is believed to be a duplicate Sensor response message. The advantage to being human with the ability to look at the messages that flowed before and several messages that flowed after allow the conclusion the message is a duplicate but that is far beyond what the ISY can conclude based on last Query issued and next response received.

 

My looping Program worked for several iterations before that duplicate message appeared and worked for several interactions after without producing another duplicate. It may be that adding a small amount of time between the Queries would help but that is all speculation. Nothing objective in the event trace supports that idea. Certainly worth trying.

[Xathros]

I wonder if the same conditions can be detected with other multi-node queryable items like KPLs or Fanlincs. Really seems like a design flaw in insteon not carrying a node id in the ACK message.

 

-Xathros

[LeeG]

Xathros

 

No room in the ACK message for a node (group) indicator. The Query returns a link database Delta number in cmd1 field and On Level (On/Off) in cmd2.

 

That is a good question about the FanLinc. I'll set up the same test I ran against the I/O Linc.

[LeeG]

That was a great question Xathros raised about would the problem be seen on other device types. Ran the same test against a FanLinc with the same results. The event trace below shows the FanLinc Motor being marked On because of a duplicate response to a FanLinc Light Query. The FanLinc Light is full On (FF), the FanLinc Motor is Off. The trace entry in Blue is the ISY marking the FanLinc Motor On as the duplicate FanLinc Light response changed the FanLinc Motor Status.

 

Tue 07/16/2013 10:44:27 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 00

Tue 07/16/2013 10:44:27 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 00 06 LTSREQ (LIGHT)

Tue 07/16/2013 10:44:28 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 00 FF (FF)

Tue 07/16/2013 10:44:28 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 07/16/2013 10:44:28 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 03

Tue 07/16/2013 10:44:28 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 03 06 LTSREQ (03)

Tue 07/16/2013 10:44:28 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 23 00 FF (FF)

Tue 07/16/2013 10:44:28 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Tue 07/16/2013 10:44:28 AM : [ 14 9E F5 2] ST 255

 

 

Update: added a 1 second delay between the Queries to see if that made a difference. This time the Query of the FanLinc Motor node produced the duplicate entry. This is a pretty simple case. The next Query command had not been issued because of the 1 second delay. The duplicate with Hops Left=0 was not recognized as a duplicate by the PLM.

 

Tue 07/16/2013 11:30:47 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 00

Tue 07/16/2013 11:30:47 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 00 06 LTSREQ (LIGHT)

Tue 07/16/2013 11:30:47 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 00 FF (FF)

Tue 07/16/2013 11:30:47 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 07/16/2013 11:30:47 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 03

Tue 07/16/2013 11:30:48 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 03 06 LTSREQ (03)

Tue 07/16/2013 11:30:48 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 19 00 LTSREQ (LIGHT)

Tue 07/16/2013 11:30:48 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 07/16/2013 11:30:48 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 23 19 00 LTSREQ (LIGHT)

Tue 07/16/2013 11:30:48 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

[Xathros]

Xathros

 

No room in the ACK message for a node (group) indicator. The Query returns a link database Delta number in cmd1 field and On Level (On/Off) in cmd2.

 

That is a good question about the FanLinc. I'll set up the same test I ran against the I/O Linc.

 

I do understand the limitation. I highly suspect that this wasn't a problem before the advent of Dualband devices. It was when I added my 2 Fanlincs that I started noticing double responses to various events. (Motion detectors triggering twice in the same second, RL2 buttons registering twice etc).

 

I don't see any way to resolve this beyond a delay to allow the duplicates to pass. I wonder if UDI could either insert delays between queries to the nodes of multi-node devices or shuffle the order of queries such that no two nodes of the same device are queried in sequence in the 3am query.

 

-Xathros

[Xathros]

LeeG-

 

Based on your previous findings, that is pretty much what I expected. Although, I would have expected the single query duplicate to be marked as such. I wonder if the PLM sees things differently if one ACK arrives on the powerline and another arrives via RF.

 

-Xathros

[johnnyt]

Would the following help or am I missing something?: (note: I have 11 IO linc and use the sensor input on 3 of them)

 

1. breaking up my queries into smaller groups/scenes, e.g. four scenes of 4, 4, 3 and 3, or maybe even smaller groups (down to querying each one individually?)

 

2. adding a suitable delay between each query request, say, 1 sec per IO linc in the scene?

 

Also, I was thinking of adding access point(s) in an attempt to reduce/eliminate intermittent comm problems (in other areas of the house). Am I understanding that adding RF devices could just increase the risk/occurrences of this problem? (I'm not worried about dual band devices as the metal junction boxes in my house render those useless.)

[LeeG]

I do not think the addition of Access Points will make the duplicate messages worse. Unfortunately there is no objective information to support that since we don't know the 'why' of all this. Add an Access point or two and see if it gets worse. Improving overall Insteon network reliability should be a good thing. In theory it should not be necessary to do any of these Queries if the Insteon Network was reliable.

 

As far as spacing the Queries between different I/O Lincs, not sure that will help after seeing the FanLinc test results. The I/O Linc is Queried twice, once for Sensor status and once for Relay status when either node is queried. I don't think a duplicate message from one I/O Linc will interfere with the Query of a totally different I/O Linc because the Insteon address would be different in the duplicate message.

.

[johnnyt]

The I/O Linc is Queried twice, once for Sensor status and once for Relay status when either node is queried

Really? I can't follow these insteon log entries like you can but doesn't the sensor only respond when you actually query it? What log entry shows that? I certainly have been querying both the relay(s) and the sensor(s) separately (like in your test program).

 

 

Sent from my iPad using Tapatalk

[LeeG]

Yes, the ISY queries both nodes when either node is queried. The code I posted effectively issued 4 query commands for each Repeat loop. Below I issued the single Query of the I/O Linc Relay. The event trace has a query of the Sensor followed by a query of the Relay.

 

Set 'IOLinc I2CS-Relay' Query

 

Thu 07/18/2013 09:36:54 AM : [ Time] 09:36:54 1(0)

Thu 07/18/2013 09:36:54 AM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01

Thu 07/18/2013 09:36:54 AM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01)

Thu 07/18/2013 09:36:54 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00)

Thu 07/18/2013 09:36:54 AM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Thu 07/18/2013 09:36:54 AM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00

Thu 07/18/2013 09:36:54 AM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT)

Thu 07/18/2013 09:36:55 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF)

Thu 07/18/2013 09:36:55 AM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Not sure I understand the question about the Sensor reporting only when queried. The I/O Linc Sensor reports state changes in real time. If the Sensor node does not show a state change either a link record problem exists or there is a comm problem preventing the state change message from reaching the PLM.

 

These are event entries from turning the Sensor Off and On after I did the query test.

 

Thu 07/18/2013 09:45:01 AM : [iNST-SRX ] 02 50 1C.FD.D5 00.00.01 CB 13 00 LTOFFRR(00)

Thu 07/18/2013 09:45:01 AM : [std-Group ] 1C.FD.D5-->Group=1, Max Hops=3, Hops Left=2

Thu 07/18/2013 09:45:01 AM : [ 1C FD D5 1] DOF 0

Thu 07/18/2013 09:45:01 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 41 13 01 LTOFFRR(01)

Thu 07/18/2013 09:45:01 AM : [std-Cleanup ] 1C.FD.D5-->ISY/PLM Group=1, Max Hops=1, Hops Left=0

Thu 07/18/2013 09:45:01 AM : [iNST-DUP ] Previous message ignored.

Thu 07/18/2013 09:45:02 AM : [iNST-SRX ] 02 50 1C.FD.D5 13.02.01 CB 06 00 (00)

Thu 07/18/2013 09:45:02 AM : [std-Group ] 1C.FD.D5-->13.02.01, Max Hops=3, Hops Left=2

Thu 07/18/2013 09:45:02 AM : [iNST-INFO ] Previous message ignored.

 

Thu 07/18/2013 09:45:05 AM : [iNST-SRX ] 02 50 1C.FD.D5 00.00.01 CB 11 00 LTONRR (00)

Thu 07/18/2013 09:45:05 AM : [std-Group ] 1C.FD.D5-->Group=1, Max Hops=3, Hops Left=2

Thu 07/18/2013 09:45:05 AM : [ 1C FD D5 1] DON 0

Thu 07/18/2013 09:45:05 AM : [ 1C FD D5 1] ST 255

Thu 07/18/2013 09:45:05 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 41 11 01 LTONRR (01)

Thu 07/18/2013 09:45:05 AM : [std-Cleanup ] 1C.FD.D5-->ISY/PLM Group=1, Max Hops=1, Hops Left=0

Thu 07/18/2013 09:45:05 AM : [iNST-DUP ] Previous message ignored.

Thu 07/18/2013 09:45:05 AM : [iNST-SRX ] 02 50 1C.FD.D5 11.02.01 CB 06 00 (00)

Thu 07/18/2013 09:45:05 AM : [std-Group ] 1C.FD.D5-->11.02.01, Max Hops=3, Hops Left=2

Thu 07/18/2013 09:45:05 AM : [iNST-INFO ] Previous message ignored.

[johnnyt]

So there's no need to query the sensor.... hmmm. Okay I'll remove that separate query from my program to reduce the insteon traffic. But it seems weird to me since sensors and relays are different nodes...

 

Not sure I understand the question about the Sensor reporting only when queried. The I/O Linc Sensor reports state changes in real time. If the Sensor node does not show a state change either a link record problem exists or there is a comm problem preventing the state change message from reaching the PLM.

 

It's intermittent. MOST of the time, the program I have that is triggered by the (insteon) sensor change of state works but OFTEN (see second screenshot in my post above) the backup program triggered by the X10 command that I've set the IO Lincs to send on sensor change is what runs to completion. So it's not a link record problem but it could be an intermittent comm problem. The weird thing is that the (I thought) weaker, non-repeated X10 makes it through... Of course, maybe the X10 command is interfering with the insteon command and causing the problem.

 

Hmm... looks like I'm not done troubleshooting this but many thanks for the info, LeeG.

[LeeG]

The ISY Query updates all the nodes for the device. Query a KPL and all the buttons are refreshed. Query the FanLinc and both nodes are queried. Otherwise 8 (or 5) queries would be required to sync a KPL. There may some Simplehomenet/Smartenit devices that operate differently because their command set is not standard.

 

It does seem odd that an X10 signal would reach the PLM but the Insteon message would not. Messages coming from a device signaling an On/Off state change are Scene (Group) messages. Insteon supports only one Scene (Group) in progress at a time. Is it possible that more than one I/O Linc would have its Sensor change state at the same time?

[johnnyt]

Is it possible that more than one I/O Linc would have its Sensor change state at the same time?

yes, absolutely, that happens. When my AC activates, it sets an IO Linc sensor monitoring the AC call AND it sets an IO Linc monitoring the Fan call (which is hard wired to occur at the furnace).

 

If that's a problem, why is it only happening intermittently?

 

Unfortunately, I didn't have notifications / log entries set up last winter to look back now and see if/when the "backup" X10-triggered program ran after a heat call (which does not come with a simultaneous fan call) so I can't say now if it was happening then.

[LeeG]

"If that's a problem, why is it only happening intermittently? "

 

Nothing electronic does the same thing in "exactly" the same way each time. I would think if a dual trace scope was used to monitor the Sensor inputs that could occur at the "same time" there would always be some variability as to when the signal reaches two I/O Lincs. Plus the electronics in the I/O Linc has a variation. That does not consider how much variation there is on a powerline circuit. Insteon is sharing wires meant to carry 120/240 volts around a house. Even a cat5 cable has some variation and it is much cleaner than a pair of 120 volt wires. In a race condition there is always a winner and always a loser.

 

Try running the Event Viewer at LEVEL 3 and create the situation where more than one I/O Linc Sensor is activated at the same time. By watching the Group messages that flow in that situation it should be possible to observe the interaction and interrelationship if any.