I have begun upgrading my sister's 1992 vintage "dumb" X10 system with an Insteon system and yesterday replaced her X10 transceiver with an EZX10RF, linking all 16 buttons on her A code Palmpads to Indigo and then creating triggers from each button group to each device, after which I started replacing the X10 switches with switchlincs, redefining each device as I replaced it. They all seemed to work, but this morning, Katie said that there was a BAD lag last night when she tried to turn off everything from her bedroom last night. I looked at the log and found:

2011-12-24 00:55:29 Received INSTEON "X10 Link" off (button 3)
2011-12-24 00:55:29 Trigger Playground X10 Off
2011-12-24 00:55:30 Received INSTEON "X10 Link" off (button 3)
2011-12-24 00:55:30 Trigger Playground X10 Off
2011-12-24 00:55:30 Sent X10 "Playground" off
2011-12-24 00:55:31 Received INSTEON "X10 Link" off (button 3)
2011-12-24 00:55:31 Trigger Playground X10 Off
2011-12-24 00:55:32 Sent X10 "Playground" off
2011-12-24 00:55:32 Received INSTEON "X10 Link" off (button 4)
2011-12-24 00:55:32 Trigger Streetlight X10 Off
2011-12-24 00:55:33 Received INSTEON "X10 Link" off (button 4)
2011-12-24 00:55:33 Trigger Streetlight X10 Off
2011-12-24 00:55:34 Sent X10 "Playground" off
2011-12-24 00:55:35 Received INSTEON "X10 Link" off (button 5)
2011-12-24 00:55:35 Trigger Small Stall X10 Off
2011-12-24 00:55:36 Received INSTEON "X10 Link" off (button 5)
2011-12-24 00:55:36 Trigger Small Stall X10 Off
2011-12-24 00:55:38 Received INSTEON "X10 Link" off (button 6)
2011-12-24 00:55:38 Trigger Frosty X10 Off
2011-12-24 00:55:39 Received INSTEON "X10 Link" off (button 6)
2011-12-24 00:55:39 Trigger Frosty X10 Off
2011-12-24 00:55:41 Received INSTEON "X10 Link" off (button 7)
2011-12-24 00:55:41 Trigger Chute X10 Off
2011-12-24 00:55:42 Received INSTEON "X10 Link" off (button
2011-12-24 00:55:42 Trigger Tack Shack X10 Off
2011-12-24 00:55:47 Error "Streetlight" off; send failed (no acknowledgment)
2011-12-24 00:55:48 Sent INSTEON "Streetlight" off
2011-12-24 00:55:49 Sent X10 "Small Stall" off
2011-12-24 00:55:51 Sent X10 "Small Stall" off
2011-12-24 00:55:51 Sent INSTEON "Frosty's light" off
2011-12-24 00:55:52 Sent INSTEON "Frosty's light" off
2011-12-24 00:55:53 Sent X10 "Chute" off
2011-12-24 00:55:54 Sent INSTEON "Tack Shack" off

Analyzing, it looks like she held down each of the buttons down for a second or two (historically, the X10s don't respond that quickly, part of the reason I'm replacing them). The Playground X10 off signal was sent before her finger came off the button, but the first insteon device (Streetlight) off signal was probably sent around 55:32, but the ack got lost in further button traffic, with the result that NOTHING further got handled for a full 15 seconds while Indigo tried to recover from that failure... have you ever considered that if there are additional Commands in the queue, the dispatcher should just repost the failed command to the end of the list rather than the OCD "I'm not doing anything else till I get THIS done."?

It isn't Indigo trying to recover from the failure. It is the PowerLinc resending the command using increased hop counts and waiting for the power line to be idle so the command can go complete. But because the incoming commands kept coming, it kept having to wait. The outgoing commands all wait their turn in the queue for the command before them to complete or fail. Unfortunately, I don't know of a good solution to this, other than using a W800RF32 for the incoming X10 RF commands (which won't have to go on the power line at all -- it is very fast).

Something else to consider - when she needs to turn off a set of lights, use an INSTEON group instead of individual commands. Press one button, Indigo sends a single group OFF command, and all lights go off at the same time.

support wrote:It isn't Indigo trying to recover from the failure. It is the PowerLinc resending the command using increased hop counts and waiting for the power line to be idle so the command can go complete. But because the incoming commands kept coming, it kept having to wait. The outgoing commands all wait their turn in the queue for the command before them to complete or fail. Unfortunately, I don't know of a good solution to this, other than using a W800RF32 for the incoming X10 RF commands (which won't have to go on the power line at all -- it is very fast).

OK, so it IS still the 2414 that is doing the retries even when slaved to Indigo... When I had read this in another thread, I had assumed that once standalone mode was disabled, all of that came from the Mac:

support wrote:This sounds like a power line noise issue. Perhaps there is more noise at night time, or more INSTEON commands that increase the likelihood of collisions (motion sensors, etc.).

Also when Indigo is running, it is a bit more polite about trying to wait for the power line to be idle before sending commands so that will increase reliability a bit in some circumstances. And it retries commands whenever the PowerLinc detects an incoming command. In standalone mode it isn't as robust.

And as far as using a group trigger or direct X10RF to USB , 4 of the 10 devices are lights in the horse stalls which need to be left on if horses are put up there (which changes night to night; that's why buttons 1 and 2 aren't included). And the palmpad is over 100 yards from the Mac... and BTW, you guys work way too hard; I see that even Jay took off, poor Matt had to stick it out through Christmas.

Indigo waits until the PowerLinc says it can accept a command, indicating the power line is idle, before it requests the command to be sent. In your example above, I believe the "Streelight" command wasn't sent on to the power line until around 55:42 (not 55:32) because there were so many commands flying around on the power line. That command then failed (possibly because the remote button was pressed again and there was a collision) and was automatically retried by the PowerLinc with increasing hop counts. Those PowerLinc internal reties took around 5 seconds (and failed probably because of signal collisions), until it finally gave up and reported an no ACK error back to Indigo.

None of that explanation helps the situation, unfortunately. It is just an FYI what is occurring under-the-hood.

Thanks for the detailed blow by blow; I had assumed from your earlier posts that the USB and powerline sides of the 2414 were completely asynchronous and the "Trigger" entries in the log were when Indigo sent the command to the interface, with the "sent" entries were when the interface sent the X10 commands (since there are no Acks involved in those) and when the ack occured for Insteon commands. Which would have meant that the Streetlight command got sent to the powerline as soon after 55:32 as there was a break in the incoming stream and once the first Ack got lost, the 2414 began contributing the the chaos by increasing the hop count (meaning that echos from intermediate devices KEPT slamming the acks that the streetlight was trying to send even after the button pushes stopped). But once the 2414 gave up at 55:47 and processed the second streetlight off trigger that had been setting around forever with a reasonable hop count, everything started working perfectly. Automatically assuming that upping the hop count, even in times of heavy traffic, is going to help matters kind of looks like a glitch in the Insteon protocol; and hopefully will be fixed by telling my sister to wait a second or two to make sure the system isn't just a little slow.