Understanding "retries" in ISY

[terschen]

First let me say that the ISY is fantastic! What an awesome combination of hard/software for Insteon. I'm very impressed, not only by the hard/software but also by the customer support UD provides here. Truly fantastic.

 

I would like to understand more about how the "retries" capability functions for both the PLM ( Advanced / PLM Communication) and devices ( Show Advanced Properties / Device Communication) setting options for the ISY 994. The ISY manual does not go into detail of how these settings compare to the "native retries" of an Insteon network without an ISY in it, nor how they affect the "native retries" of an Insteon network with an ISY in it. There does however seem to be a fairly strong warning about using a retries setting other than 0 (ISY defaults this value to zero. Please note that excessive group cleanup signals degrade performance and may cause interference and unwanted behavior. As such, extreme care should be taken when deciding to change this value.)

 

My network consists of ~125 Insteon devices. I am using an ISY 994i/IR Pro, firmware v4.0.5, UI v4.0.11. All of my devices have been "restored" via ISY so their internal link tables match ISY yet I always run my network with the ISY online as well. All of my PLM and scenes are set to 0 retries in ISY. I also use legacy X10 reliably throughout (filters/couplers/XTB-II etc...all the stuff needed to make X10 "reliable"...yuck) so every Insteon device/button also has an X10 address.

 

I would say my Insteon network scene capability, when executed by a keypad button press, currently functions with about 95% reliability. Prior to introducing the ISY and the device restores I would have said it was 100% reliable. The 5% difference seems to be that previously the 5% (say 1 out of 20 scene executions) would have 1 or 2 devices on a large scene (say 50 devices) that might not respond immediately to the scene, but then respond a second or so later as native Insteon device "clean-up" took place. I'm not sure, but I don't think that native Insteon clean-up occurs any longer in my network because I have all my scene devices set to 0 retries (and restored devices), thus if some device doesn't receive the command the first time around, it doesn't respond to the scene. A subsequent press of the scene button on the keypad typically resolves "the slackers".

 

So, I'm thinking I should likely set all of my scene devices in ISY to something like 1-3 retries (leaving the PLM retries at 0), but I'm not sure if that will do what I'm thinking it will or not...basically re-implement the same native Insteon "clean-up" that seemed to exist before I added in the ISY and restore device activities into my network. I don't want to "...degrade performance and may cause interference and unwanted behavior.", yet I want to get back to saying my network is 100% reliable with the ISY online.

 

Can someone please advise me on the proper retries settings for my network (if that's possible), and/or provide a more detailed explanation of how the retries settings in ISY affect both devices AND scenes activated from within ISY AND locally at the device?

 

Thanks a bunch!

[LeeG]

The concept of controlling retries was introduced with I2CS protocol. Only I2CS devices functioning as a Controller can control retries. For example, a button press on a non-I2CS KeypadLinc operates on the retry scheme Insteon has had forever.

 

No Tries means no Group Cleanup Direct messages. As the retry count is increased the number of possible Group Cleanup Direct messages increases. A high retry count on a marginal Insteon Mesh Network can result in an increase in Insteon traffic.

 

The retry count is stored in D1 (the first of the three data bytes) in Controller link records. A value of 0xFF which was a common value in the past results in no retries with an I2CS Controller.

 

I don’t think there is a proper setting per se. The lower the number the better as far as the volume of Insteon traffic. A marginal or unreliable Insteon Network would require more. I think it best to clean up a bad Insteon network than compensate by running with a high retry count.

[eataft]

Glad I discovered this post, because it sheds light on a matter that has long puzzled me.

 

I have a large home whose electrical system is noisy, not to mention having another power-line communication system using it. Consequently, it is understandable that occasional Insteon commands will be lost and need to be retried. I am depending on the Insteon protocol to achieve reliability in this environment.

 

Scene commands sent from KPLs work reliably. Occasionally, I notice a delay of a second or two after pressing a KPL button before the controlled device responds. I attribute this to a lost Insteon command that is automatically retried. In other words, the Insteon protocol is operating as designed.

 

Scene commands sent from the ISY to certain devices do not work reliably. From this forum post (and others), I have learned that ISY scene commands are not retried, although direct commands are. In other words, Insteon is not working as designed when controlled from the ISY.

 

Ideally, I would clean up my home power network so as to eliminate loss of Insteon commands, but this is easier said than done. I have replaced some Insteon devices with dual-band devices, but this has limited benefit for devices that are mounted in metal boxes. I have installed filters to eliminate the most obvious problems, but this becomes impractical to do everywhere as I replace incandescent lighting with CFLs and LEDs and as home electronics become more ubiquitous.

 

The fact of the matter is that portions of my network are marginal, but they are well within the Insteon protocol's capabilities when it is being operated as designed. I am sure that many other people will encounter similar issues as they install more electronic devices in their homes.

 

I am curious to learn why the ISY doesn't retry scene commands, as it does for direct device commands. I suspect that there is a concern about tying up the PLM for too long while checking the status of all devices in a large scene. But it would be useful for the ISY to provide an option to retry specific scenes, or to retry scenes only up to a certain size, or something of that sort.

[LeeG]

"curious to learn why the ISY doesn't retry scene commands"

 

The Group (Scene) message flow that would enable retry introduces large variations in how long a Scene may take to execute. The delays (waits) that would be required in Programs to insure the Scene was actually complete makes Program logic very difficult to implement. If the Insteon network is generally unreliable the Set Scene can be issued multiple times to achieve a higher degree of success.

[kevkmartin]

Couldn't the ISY "interpret" the scene and issue the sequence of more reliable single device commands?

 

I realize this wouldn't help "device triggered" reliability, but would add reliability to ISY initiated scenes, without disturbing the built in Insteon device functions.

 

 

Sent from my iPad using Tapatalk HD

[LeeG]

Not using an ISY Scene as a Scene. I guess anything is possible but that seems unlikely.

 

A major aspect of an Insteon Scene is that all responders normally react at the same time. If that was changed to use Direct commands it could take several seconds before the last responder reacted.

[larryllix]

As I understand it Insteon devices/responders must respond with an "Ack" message to the controller in order for the retry logic to work.

 

That being said, with scenes with multiple devices involved it would next to impossible to sustain the logic to invoke a retry communication technique. Each and every device would have to respond with an "Ack", arbitrate who would send their "Ack" or "Nack" first, second, third...umpteenth. This could bog down Insteon communications for quite some time, especially with retries and possibly retries on detected collisions for the "Ack/Nack" process.

 

I think I can now understand why scenes would not support retries.

[eataft]

Based on my limited understanding of the Insteon protocol, the way scenes work is:

 

1. The controller issues a scene command, which normally all responders act upon immediately.

 

2. The controller issues a "group cleanup" command to each responder in turn. The responder acknowledges this to report whether it acted upon the scene command. (I'm not sure what is the remedial action if the responder missed the scene command.)

 

This protocol has the benefit that scene commands ordinarily take effect immediately. But if a responder missed the scene command, the "group cleanup" phase of the protocol takes care of the problem eventually. This combines the immediacy of a scene with the reliability of a sequence of direct commands.

 

When I asked "why the ISY doesn't retry scene commands", I really meant to ask "why the ISY doesn't follow the regular Insteon protocol for issuing scene commands reliably".

 

I have employed the workaround of creating ISY programs to issue a scene command followed by direct commands to the devices in the scene. But this seems rather clunky and really shouldn't be necessary if the ISY were following the normal Insteon scene protocol in the first place.

[LeeG]

An Insteon Scene executes as follows ....

 

The application issues a Scene On/Off message

 

The PLM sends a Group Broadcast message which all Responders should see and react to. This message is not ACKed as many devices may react to this message.

 

The PLM sends a Group Cleanup Direct message to the first device in the Scene. The device should ACK this message. If no ACK is received the PLM sends another Group Cleanup Direct message to the same device. This is repeated up to three times.

 

The PLM sends a Group Cleanup Direct message to the second device in the Scene. The same sequence described above is possible. Each device in the Scene is sent a Group Cleanup Direct message by the PLM. How long this process takes depends on the number of devices in the Scene and how many Group Cleanup Direct messages are required for each device.,

 

When all Group Cleanup Direct messages have been sent (including retries) the PLM sends a message back to the application indicating the success/failure of the Scene message originally sent by the application.

 

Writing a Program that has to take all this variation into account is very difficult. The ISY has chosen not to expose the Program to this volatility. The ISY issues a Group Broadcast message directly rather than issuing the Scene message.

 

There are some additional capabilities available when the Controller is an I2CS device.

 

EDIT: the PLM cannot receive another application message while the Scene is being processed so either the Program execution is suspended until the Scene completes or additional responsibility is transferred to the Program. Activity such as emails, variable updates, anything that does not lead to PLM activity can still be done but that would require the Program track the progress of the Scene the PLM is working on. I have written applications that work in this environment. They are much more complex even when other activity is not desired.

[eataft]

LeeG, Thank you for describing in detail how a scene works. You have essentially confirmed my previous understanding, but I was unsure about what is done by the ISY and what is done by the PLM. You have clarified the picture there.

 

What I think you are saying is that if the ISY commands the PLM to perform a Scene command, the PLM becomes busy until all devices have acknowledged the Group Cleanup messages (or have timed out). This could tie up the PLM for quite some time and would delay subsequent ISY activities.

 

I can see that this would be a real problem for a scene that includes many devices. But for a scene that includes only a few devices, the time required for the PLM to perform the scene protocol is comparable to the time to perform direct commands to the devices -- a few seconds at most. This seems as if it should be manageable.

 

I wonder if it would be possible for the ISY to provide an option to issue a Scene instead of a Group Broadcast in select cases -- say, for specific scenes that I designate, or for all scenes that are smaller than a certain threshold number of devices, or something like that.

 

This would be a great help in my situation, where there are only certain scenes that are troublesome. It would be a lot cleaner and less clunky than my current workaround, which is to follow each scene command with direct commands to the individual devices in order to ensure that they respond.

 

Can someone at UDI say if this idea would be practical to include in a future firmware release?

 

On a related matter, I think that the ISY documentation could be a lot better on this matter. It was very puzzling to me -- and I'm sure to lots of other people -- why scenes invoked from the ISY are unreliable, even though the same scenes invoked from a KPL are reliable. It is especially misleading that the ISY log file shows that the devices in the scene changed status, when in fact the ISY has no way of knowing what the status of those devices is.

[Michel Kohanim]

Hello eataft,

 

Thanks so very much for the details and thanks to LeeG for a great response.

 

We have dabbled with this situation multiple times and in all cases sending a group command actually made things much worse: not only devices that didn't respond before didn't respond using scene commands but also we ran into major delays causing all sorts of issues with ISY programs such as collisions.

 

The reason the PLM is not as reliable as other devices is because of the location of the PLM. The first thing I suggest is to move the PLM to a different location. In short, commands from the PLM must be as reliable as others.

 

With kind regards,

Michel

[shannong]

I"m not currently dealing with an comm issues but this thread was very valuable to understand ISY Scene behavior vs Insteon scenes along with Group Broadcasts and retries.

[eataft]

Michel, Thank you for the definitive answer. It is interesting that you found that sending scenes from the PLM worked poorly. It seems that we are dealing with a PLM deficiency more than an ISY deficiency.

 

My PLM is on a dedicated circuit and it has RF connectivity to AccessPoints on each phase of every sub-panel in my home. I've experimented with moving it to other places and it made no difference.

 

The real issue in my network is that occasional Insteon messages are lost due to interference. Scenes initiated from a KPL are reliable, in spite of the interference, because the KPL retries lost commands. Scenes initiated from the PLM are not reliable, because lost commands are not retried.

 

I don't really know the source of the interference, but I suspect that it is a combination of things that together are degrading the signal to noise ratio for Insteon powerline communication. CFL and LED lights are high on my list of suspects; I've noticed a gradual decrease in reliability as I've installed more of them in place of incandescents. Ultimately, I suspect that the only solution will be to replace all of my Insteon powerline devices with dual-band devices.

 

Anyway, I do have a workaround (described in my earlier post) that seems to be effective.

[Xathros]

Michel, Thank you for the definitive answer. It is interesting that you found that sending scenes from the PLM worked poorly. It seems that we are dealing with a PLM deficiency more than an ISY deficiency.

 

My PLM is on a dedicated circuit and it has RF connectivity to AccessPoints on each phase of every sub-panel in my home. I've experimented with moving it to other places and it made no difference.

 

The real issue in my network is that occasional Insteon messages are lost due to interference. Scenes initiated from a KPL are reliable, in spite of the interference, because the KPL retries lost commands. Scenes initiated from the PLM are not reliable, because lost commands are not retried.

 

I don't really know the source of the interference, but I suspect that it is a combination of things that together are degrading the signal to noise ratio for Insteon powerline communication. CFL and LED lights are high on my list of suspects; I've noticed a gradual decrease in reliability as I've installed more of them in place of incandescents. Ultimately, I suspect that the only solution will be to replace all of my Insteon powerline devices with dual-band devices.

 

Anyway, I do have a workaround (described in my earlier post) that seems to be effective.

 

Since you are well covered by access points, you might try putting the PLM behind a Filterlinc to force it to use RF only. See if that brings up your reliability any.

 

-Xathros

[shannong]

In my house, I don't think I was dealing with noise as much as "signal suckers". The experiments and testing done by ELA is very valuable knowledge when troubleshooting your own network even if you can't measure signal strength. http://forum.universal-devices.com/viewtopic.php?f=28&t=5923 It's a long thread but don't skip the middle parts like I did at first. There is a lot of great info about noise and signal suckers and the types of devices that contribute.

 

Approximately 85% of my 130 Insteon devices are dual-band and no room is without at least two.Theoretically, I shouldn't need to rely upon the powerline at all. Despite that, I still had comm issues until I identified and filtered out the major signal suckers. I mention that because of you're hopes and plan to resolve issues by adding more dual-band devices. I'm not saying it won't help but don't expect Insteon magic to happen just because you think you'll have a complete full-mesh RF network that will allow you to ignore the powerline issues.

 

I still have the flickering LEDs in my house lighting to deal with. Of the 3 major LED bulbs I've purchased, only one of them experiences it. Unfortunately, its the one I had purchased the most of before Insteon was in my home. There is a thread on here and at Smarthome that lists LEDs known to be the least problematic with Insteon.

[shannong]

Since you are well covered by access points, you might try putting the PLM behind a Filterlinc to force it to use RF only. See if that brings up your reliability any.

 

-Xathros

 

Hmm... Interesting idea. I think I'll try that.

[polo1420]

eataft,

 

Is there any chance you can post an example of your work around?  I am in exactly the same boat as you.  All LED's in my house, lots of PC that need UPS, etc... so I have a noisy network.  For the most part everything works, but I have some large scenes, such as the ALL ON and ALL OFF button in my basement that controls a lot of devices.  It is annoying when the scene runs if one room or a couple of devices don't respond.  I tried making a program for an switch being turned on and being turned off.  It will trigger the scene multiple times with a wait between repeats, but then you cannot adjust any of the dimmers, as it always forces the switch to the scene setting. 

 

So I was curious to see how this looks in implementation and will give it a try on my set-up:

 

"I have employed the workaround of creating ISY programs to issue a scene command followed by direct commands to the devices in the scene. But this seems rather clunky and really shouldn't be necessary if the ISY were following the normal Insteon scene protocol in the first place."

 

 

Thanks!