Hi guys.

I'm using Indigo Pro 5.1.0. Occasionally I'll see some INSTEON communication failures (send failures due to no acknowledgment). These errors always cause Indigo to withhold and queue all INSTEON command sending for about 10 seconds (though it continues to receive INSTEON commands from other modules). Outside of the need to resolve the communication errors (which are more likely communication collisions due to my setup, as all the modules react to the commands), is there any way to reduce the send failure timeout in Indigo? It's really rather frustrating to have motion activated lights not come on for 10+ seconds while moving throughout the house, then to suddenly have all of them come on at once when Indigo finally times-out on the 1 failed send INSTEON command. Perhaps a tunable parameter in the Preferences, or maybe something that can be changed with the command-line "defaults" command? It seems like this timeout increased with one of the later 4.1.x patches a while ago.

Which PowerLinc are you using?

matt (support) wrote:Which PowerLinc are you using?

It's the 2413U (Connected to a Mac mini running 10.7.3, if that helps).

Unfortunately, there is nothing Indigo can do on its side. There is no 10 second wait in Indigo.

Indigo does wait until the PowerLinc tells it that the power line is idle, but that delay is less than one second and without that delay there will be signal and PowerLinc communication issues.

The delay you are seeing is just the PowerLinc trying multiple times to reach the module and get an ACK back from it. Each time it retries it increases the hop count, which makes that message send take longer. 10 seconds seems a bit long for that process -- are you sure it isn't closer to 6 or 7 seconds?

Looking at my logs, yes, it's between 6 and 8 seconds between the send attempt and the error message. Example log excerpt:

Code: Select all

2012-04-20 00:07:54   Received INSTEON   "Entryway Motion" on (button 1)
2012-04-20 00:07:54   Trigger   Entryway Motion Lights On
2012-04-20 00:07:54   Sent INSTEON   "Entryway Light" on to 100 at ramp rate 0.3 sec
2012-04-20 00:07:54   Trigger   Entryway Auto Unlock Front Door
2012-04-20 00:07:54   Trigger   Entryway Motion Set Time
2012-04-20 00:07:54   Trigger   Update MostRecentIndoorMotion
2012-04-20 00:07:54   Trigger   Entryway Auto Spoken Greeting
2012-04-20 00:07:56   Received INSTEON   "Kitchen Motion" on (button 1)
2012-04-20 00:07:56   Trigger   Kitchen Motion Set Time
2012-04-20 00:07:56   Trigger   Update MostRecentIndoorMotion
2012-04-20 00:07:56   Trigger   Kitchen Motion Lights On
2012-04-20 00:08:01   Schedule   Entryway Auto Unlock Front Door (delayed action)
2012-04-20 00:08:01   Schedule   Entryway Auto Spoken Greeting (delayed action)
2012-04-20 00:08:02   Error   "Entryway Light" raw insteon command; send failed (no acknowledgment)

The "Sent INSTEON 'Entryway Light' on to 100 at ramp rate 0.3 sec" line was generated by my BrightenWithRate AppleScript attachment, not Indigo, and is called from within an action in the "Entryway Motion Lights On" trigger. This example shows about an 8 second delay which is pretty typical of what I'm seeing.

If it's something that's internal to the 2413U, perhaps it's simply a function of me having so many INSTEON devices on the network (54 in all)? Perhaps I started noticing it around the later 4.1.x Indigo version because that's when I started adding more modules (or perhaps a misbehaving module?) to my network?

Another log excerpt to illustrate the issue:

Code: Select all

2012-04-20 00:28:34   Received INSTEON   "Dining Room Motion" on (button 1)
2012-04-20 00:28:34   Trigger   Dining Room Motion Set Time
2012-04-20 00:28:34   Trigger   Update MostRecentIndoorMotion
2012-04-20 00:28:34   Trigger   Dining Room Motion Lights On
2012-04-20 00:28:34   Sent INSTEON   "Dining Room Light" on to 75 at ramp rate 0.3 sec
2012-04-20 00:28:37   Received INSTEON   "Dining Room Door to Garage" on (button 1)
2012-04-20 00:28:37   Trigger   Dining Room Door to Garage Open Too Long
2012-04-20 00:28:37   Trigger   Dining Room Door Open Garage Lights On
2012-04-20 00:28:37   Trigger   Dining Room Door Open Set Time
2012-04-20 00:28:38   Received INSTEON   "Garage Motion" on (button 1)
2012-04-20 00:28:38   Trigger   Garage Motion Set Time
2012-04-20 00:28:38   Trigger   Update MostRecentIndoorMotion
2012-04-20 00:28:38   Trigger   Garage Motion Lights On
2012-04-20 00:28:45   Error   "Dining Room Light" raw insteon command; send failed (no acknowledgment)

Again, the "Sent INSTEON 'Dining Room Light'..." line is from my script, not Indigo. From the "Dining Room Motion Lights On" trigger time to the error message is 11 seconds. Could some of that be due to all the triggers as well?

I have had quite a few noise issues to resolve in my house. The most common problem they were causing, was what you described, if the light came on at all. Filters have helped immensely, as did careful placement of the 2413U itself, in terms of which circuit it is on.

The other thing that has helped reliability a lot, is putting a delay of .02 minutes on the trigger (.01 doesn't seem to 'take'). That equates to a 1.2 second delay on the light turning on. Given the positions of my motion sensors, that is plenty of time to get the light on before I enter that area of the house. (i.e., the motion sensor in my living room, 'sees' me coming down the hall, well before I actually get to the living room, etc.)

Interestingly enough, it only seems to be a problem with sending commands to my switchlinc dimmers. Other devices don't seem to suffer. In my case, adding the slight delay to the trigger, put it to the point where I would call reliability good.

Don't know if that helps you at all, but I know in my early days of setting up the first few devices, I was frustrated to the point of nearly giving up. A trigger/action might work reliably for a week, and then not work at all for a week or more, full of the (no acknowledgement) messages.

Greg

Greg's tips are good ideas. Motion sensors that cause Triggers which send INSTEON commands have been issues before because the outbound INSTEON command from Indigo can collide with clean-up commands from the motion sensor. The best advice is to make sure the motion sensor is only linked with Indigo (PowerLinc) and no other modules (to prevent a longer cleanup sequence), and if you still have no ack errors frequently on the outbound command from the Trigger then use a small delay as Greg mentioned.

Hi Greg and Matt.

Thanks. I'm reasonably sure actual noise isn't much of a problem. I have FilterLincs on every piece of major (and most minor) electronics in the house. I think most of my issues are communication collision related. I also introduce artificial delays as well, though not as long as yours, which do help some. I try to keep the artificial delays to a minimum though, as I need the lights to come on as quickly as possible once motion is detected. Also of some interest is that the INSTEON raw commands I'm sending (to get per-action brighten/dim rates) seem to be much less reliably acknowledged than standard ON and OFF commands. I had almost zero acknowledgement errors until I started using raw commands, so I suspect that the SwitchLincs themselves aren't processing the command responses as reliably as the more common ON/OFF commands. Running the iHealth 1.2 tool on my devices indicates very good RTT on every device, but the standard deviation is somewhat wide on a seemingly random few modules each time the tests are run, which indicates to me that there are either intermittent noise spikes coming from somewhere on the INSTEON network (power line or RF), or it's just communication collision being reflected in the iHealth test results (motion sensors being activated during iHealth test runs).

I'd hoped the send command response timeouts were tweakable, but if it's a firmware/design related issue in the 2413U, I guess that's not really an option.

Do any of you folks know if there are commands that could be sent to the 2413U to change how it handles INSETON no ack conditions? Perhaps links to a tech doc on serial commands I could send to it myself?

There is no such command, at least not documented. I doubt it exists at all though.

matt (support) wrote:There is no such command, at least not documented. I doubt it exists at all though.

Alright. Well, I do appreciate all the feedback nonetheless.

matt (support) wrote:There is no such command, at least not documented. I doubt it exists at all though.

Hmmm... Looking into the details of INSTEON commands, it appears the "flags" byte (the byte that comes after the responder address bytes and just before the command1 byte) contains 2 bits for max hops and 2 bits for hops left. Couldn't those bits be set to something like 0101 (1 retransmit remaining out of a max of 1) before sending the data string to the PLM? That'd effectively reduce the TTL and thus NACK delay?

Indigo already does that. Commands are sent with an initial hop count of 1, which is enough to get the single hop needed from one dual-band module to another dual-band module on the other power leg.

What you are seeing isn't because of the initial hop count. It is because the commands fails, so the INSTEON engine retries the command again with an increased hop count. It then repeats that until the hop count is maxed out, and sometimes even repeats it again with the max hop count a few times.

All of that is totally beyond the control of Indigo.

Right. Gotcha. Just being thorough.