Insteon switches compete with Inidigo trying to change state

Is there a way for Indigo to tell whether Insteon light switch trigger was initiated by manual switch operation or by corresponding Indigo device using its software?

I have Insteon dimmer switches that control the same lights and the switches are linked to communicate directly synchronizing the state, but when I use Indigo software to adjust the light, only the switch that's connected to the load alone adjusts its state, other switched don't, so I created a trigger in Indigo to synch the other ones to the same state when the load switch changes its state. The problem is when I operate the switches manually the Indigo trigger is also trying to adjust the sates of the switches and often the lights go into a loop. If I could program Indigo Trigger to only trigger when the change was initiated by the software alone then that would solve the issue. Unless there is a different way of doing this perhaps?

[jay (support)]

I don't understand this part of your description:

often the lights go into a loop.

Your solution description is what most users do when using 3-way insteon configurations: when the main (load connected) device's state changes, you update each linked switch's state. When manually operated from the linked switch, this will cause Indigo to update the same switch, but since the switch is already correctly set it doesn't have any practical effect (i.e. turning a switch on that is already on does nothing).

So I don't understand where the loop is - I suspect maybe there is an error in your update logic that's causing it.

Sorry I am not describing this properly, will try with an example, might be a long read though:

I have 3 dimmer switches in the kitchen controlling the same light, one of them is naturally connected to the load.
When I adjust the light on any of the 3 switches the other 2 instantly pickup the state since they are all linked directly (without Indigo). The load-switch is configured in Indigo as an Insteon device. When I use Indigo Touch to operate the load switch it accordingly changes its state and sets the light to appropriate level, but the other 2 non-load switches don't seem to be aware of the load-switch state (or should they? maybe I am not linking those switches properly?). So in order to get the other 2 non-load switches to match the load switch state I created a trigger in Indigo that matches the state of the load switch with the other 2 switches whenever the load switch changes its "Brightness level". That way all the non-load switches synched to the same state of the load switch, and if I operate any of non-load switches manually after that, they know where is the "starting point" when I do dim/on/off.
That seems to work, at least most of the time. But there are instances when I would manually turn on/off the light using non-load switch - that instantly turns on load-switch, that triggers my Indigo Trigger, which I assume lags, and picks up the wrong state that in turn sends to the non-load devices.. I had a case when I would hit the switch to turn Off and watch how the lights would go Off, then On, then Off again, sometimes several times, all in 2 or 3 seconds apart, and that's what I meant by the "loop".
The "loop" doesn't seem to happen if I disable the Trigger so I thought if there was a way to create a "special" type of Trigger that would only be activated on non-manual switch operation (operated from software only) might solve the problem.

It could very much be my wrongdoing, just trying to figure where that might be..

In the screenshot: "Kitchen Lights" is the load-switch, "Kitchen Lights2" and "Kitchen Lights3" the other non-load switches.

[jay (support)]

I understand the scenario, and as I said above, your solution is the best solution.

1) There is no way to Indigo to know where a change originated (it's not in the Insteon API)
2) I don't know what is causing your issue with multiple incorrect commands. You might try adding a 1 second delay on the Match Brightness action to give the Insteon protocol time to get caught up (Insteon is super slow, and if you have collisions it can cause it to be even slower).

Thanks for the "delay" advice Jay, I think that did the trick.