someguy Posted September 7, 2020 Posted September 7, 2020 I just installed a couple of 2477 switchlincs and ISY offer me a setting option for "Retries". I have some questions: which devices get this option.? doesn't insteon automatically try three times? or is it three hops? I appreciate any discussion or comments on this.
larryllix Posted September 7, 2020 Posted September 7, 2020 1 hour ago, someguy said: I just installed a couple of 2477 switchlincs and ISY offer me a setting option for "Retries". I have some questions: which devices get this option.? doesn't insteon automatically try three times? or is it three hops? I appreciate any discussion or comments on this. Typically ...yes! Insteon devices will try up to three times if an ACK is not received back from the destination device. Less can reduce reliability. More can clog up protocol channels with excessive clutter that likely should be fixed. Scene signals do not support this technique as there is no ACK from destination devices, similar to the old X10 protocol. ISY guesses at results. Hops are a different beast, and often confused with retries. When a device attempts to communicate with another, every device that hears the package resends the package in synchronicity with the other devices. This is called a HOP. Typically they are set to 3 HOPS by the initiating device. Each device subtracts one from the count and sends it again. The communication between the initiating device and the target device is not counted as a HOP. This is why good Insteon comms are important. Think of this. 1 device talks to 8 devices and repeat it. Then another 25 devices repeat it again to the rest of the 100 devices. Now add in the three retries on top of that when it doesn't work. Now the fast Insteon protocol is bogged down with junk packets. Hope this helps. 1
lilyoyo1 Posted September 7, 2020 Posted September 7, 2020 7 hours ago, someguy said: I just installed a couple of 2477 switchlincs and ISY offer me a setting option for "Retries". I have some questions: which devices get this option.? doesn't insteon automatically try three times? or is it three hops? I appreciate any discussion or comments on this. Hops is less of a worry with insteon due to how it works. Their white papers explains it in much better detail. The retries is the bigger issue. To cut down on communication slowing down/distrupting your network, they allow you to lessen the amount of retries that you need. For some things, a single retry may work while others may need 3. If you need 3 retries, you have comm issues that should be investigated and fixed (if possible). If you have a single retry and it works then your great.
kclenden Posted September 9, 2020 Posted September 9, 2020 (edited) On 9/7/2020 at 7:46 PM, lilyoyo1 said: Hops is less of a worry with insteon due to how it works. In my opinion, it's actually opposite. If MAX HOPS is set to 3 then all devices must wait for the time it would take for the message to be repeated three times before they can respond, whether they heard the message the first time or not. They must wait so that they don't try replying while another device is possibly repeating the original message which would cause message collisions on the power line. On the other hand, RETRIES are variable. If a device sends a message and immediately receives a reply, the communication is done. It's only if the original message is not acknowledged that the original device will resend the message*. So on a clean powerline devices that use a retry value of 3 will use way less bandwidth on the powerline than devices that use a max hop value of 3. * - Most Insteon devices that use RETRIES will default MAX HOPS to 1 when they originally send their message. If they don't receive an acknowledgement then when they retry sending their message they will increase MAX HOPS by one (up to a max of 3). Edited September 9, 2020 by kclenden
lilyoyo1 Posted September 9, 2020 Posted September 9, 2020 27 minutes ago, kclenden said: In my opinion, it's actually opposite. If MAX HOPS is set to 3 then all devices must wait for the time it would take for the message to be repeated three times before they can respond, whether they heard the message the first time or not. They must wait so that they don't try replying while another device is possibly repeating the original message which would cause message collisions on the power line. On the other hand, RETRIES are variable. If a device sends a message and immediately receives a reply, the communication is done. It's only if the original message is not acknowledged that the original device will resend the message*. So on a clean powerline devices that use a retry value of 3 will use way less bandwidth on the powerline than devices that use a max hop value of 3. * - Most Insteon devices that use RETRIES will default MAX HOPS to 1 when they originally send their message. If they don't receive an acknowledgement then when they retry sending their message they will increase MAX HOPS by one (up to a max of 3). Theres always going to be differences of opinion in the best way to maximize one's system. Lessening hops could lead to system instability and long term problems while lessening retries improves things. As I stated earlier, the white papers explains it all so I wont go into details here. The problem starts when we think we know more about whats going on than the system that was designed to operate a certain way. Insteon devices are smart enough to know what it needs to ensure proper communication (this is why they do not need a controller for communcication). It;'s this intelligence that allows you to look at the event viewer and see how many hops you have left. The system KNOWS when to send more or less. Trying to outsmart it by saying send only 1 hop means only 1 hop gets sent....What if you need more at any given moment? Retries on the other hand is redundant. If it doesnt work the first time, the likelihood of it working the 2nd, 3rd, 4th, or 100th time goes down each time. If something is stopping the signal its going to keep stopping it.
kclenden Posted September 9, 2020 Posted September 9, 2020 4 hours ago, lilyoyo1 said: Lessening hops could lead to system instability and long term problems while lessening retries improves things. There is a maximum of three hops allowed. If lessening hops was going to lead to such instability, then Insteon would have allowed one more bit for MAX HOPS and increased the max to 8. Lessening retries will hardly ever improve anything. A device only uses a retry if it doesn't get an acknowledgement. If it consistently doesn't get an acknowledgement then it isn't working. If it isn't working, you'll notice it and fix it. If you don't notice it, then its use of retries apparently isn't causing you to notice a degradation in your home automation. 4 hours ago, lilyoyo1 said: As I stated earlier, the white papers explains it all so I wont go into details here. I've read the white papers many times. Typically I refer to them before making responses about how Insteon works. Thanks for not boring me with the details here. Your response both says that Insteon devices are smart and that the Insteon designers aren't. If those designers were smart, why would they include the ability change configuration parameters for devices that you say are smart enough to know when to send more or less? They included the ability because sometimes it helps, either for reliability or speed.
lilyoyo1 Posted September 9, 2020 Posted September 9, 2020 (edited) 3 hours ago, kclenden said: There is a maximum of three hops allowed. If lessening hops was going to lead to such instability, then Insteon would have allowed one more bit for MAX HOPS and increased the max to 8. Lessening retries will hardly ever improve anything. A device only uses a retry if it doesn't get an acknowledgement. If it consistently doesn't get an acknowledgement then it isn't working. If it isn't working, you'll notice it and fix it. If you don't notice it, then its use of retries apparently isn't causing you to notice a degradation in your home automation. I've read the white papers many times. Typically I refer to them before making responses about how Insteon works. Thanks for not boring me with the details here. Your response both says that Insteon devices are smart and that the Insteon designers aren't. If those designers were smart, why would they include the ability change configuration parameters for devices that you say are smart enough to know when to send more or less? They included the ability because sometimes it helps, either for reliability or speed. Being that I've had the opportunity to work with the designers many times I'll go off what they say. What you say makes absolutely no sense. For insteon to be smart it's designers would have to be smart since they designed it. Insteon was designed first to be independent of a controller which is why things hops and so forth are built into the protocol itself. Because the RF is tied to the power line, it's more important to let insteon manage the hops because it knows a lot better than you what it sees and will manage the hops on its own. You trying to do so would only mean constantly trying to change things to improve when changes are dynamic when insteon does it on its own. As with retries, too many hops will cause more issues than it solves which is why they limit it. A controller constantly retrying things wouldn't help as it would simply cause unnecessary communication which probably wouldn't help. As most people on here say, a clean system is the best system regardless. Edited September 9, 2020 by lilyoyo1 1
larryllix Posted September 9, 2020 Posted September 9, 2020 (edited) Trouble is a "white paper" is only a proposal and not necessarily how the protocol was implemented. Many companies do this to throw competitors off the trail. It is done with patents frequently, where some detail is changed to slow down copying. This was discovered by our friend failing to prove Insteon protocol was easily hacked. He didn't understand what a white paper was either. Edited September 9, 2020 by larryllix 1
lilyoyo1 Posted September 9, 2020 Posted September 9, 2020 32 minutes ago, larryllix said: Trouble is a "white paper" is only a proposal and not necessarily how the protocol was implemented. Many companies do this to throw competitors off the trail. It is done with patents frequently, where some detail is changed to slow down copying. This was discovered by our friend failing to prove Insteon protocol was easily hacked. He didn't understand what a white paper was either. Whatever happened to him? Lol
kclenden Posted September 9, 2020 Posted September 9, 2020 2 hours ago, larryllix said: He didn't understand what a white paper was either. Do I have a "kick me" sign on my back today.
kclenden Posted September 9, 2020 Posted September 9, 2020 (edited) 2 hours ago, lilyoyo1 said: What you say makes absolutely no sense. Or, perhaps, you fail to understand. 2 hours ago, lilyoyo1 said: it's more important to let insteon manage the hops because it knows a lot better than you what it sees and will manage the hops on its own 2 hours ago, lilyoyo1 said: You trying to do so would only mean constantly trying to change things to improve when changes are dynamic when insteon does it on its own. Older Insteon devices do not manage things on their own. The dynamic management of hops was a later addition. Even then, my understanding is that doesn't happen between the PLM and devices (feel free to correct me on that). 2 hours ago, lilyoyo1 said: As most people on here say, a clean system is the best system regardless. On that we agree. And I'll say it one more time and leave it at that - a clean system won't require retries or multiple hops. Edited September 9, 2020 by kclenden
lilyoyo1 Posted September 9, 2020 Posted September 9, 2020 1 minute ago, kclenden said: Or, perhaps, you fail to understand. I understand but we simply differ on opinions Older Insteon devices do not manage things on their own. The dynamic management of hops was a later addition. Even then, my understanding is that doesn't happen between the PLM and devices (feel free to correct me on that). I'm not talking about older devices. It's been so long since I've dealt with older stuff Id be doing an injustice to speak on it. Let's be real, older stuff sucked all around. On that we agree. And I'll say it one more time and leave it at that - a clean system won't require retries or multiple hops. I wholeheartedly agree. We can drink to that 1
someguy Posted September 9, 2020 Author Posted September 9, 2020 I apologize for bringing up a topic that created some conflict. I know I benefit from the discussion. I feel like a kid listening to adults discussing a topic that I know very little of. I have some questions: 1) which devices do we consider "older devices"? (Perhaps I'll upgrade some of my devices.) 2) a "clean system is the best.." but, in my opinion, cleaning a system is very difficult. Has the ability to clean up a system changed in the past five years? New devices to help find the trouble? or just better devices? and are they just better because of them being dual band or are there other improvements? (yes, this is kind of the same as my first question)
lilyoyo1 Posted September 9, 2020 Posted September 9, 2020 45 minutes ago, someguy said: I apologize for bringing up a topic that created some conflict. I know I benefit from the discussion. I feel like a kid listening to adults discussing a topic that I know very little of. I have some questions: 1) which devices do we consider "older devices"? (Perhaps I'll upgrade some of my devices.) 2) a "clean system is the best.." but, in my opinion, cleaning a system is very difficult. Has the ability to clean up a system changed in the past five years? New devices to help find the trouble? or just better devices? and are they just better because of them being dual band or are there other improvements? (yes, this is kind of the same as my first question) Don't worry about topics causing debates. For me, debates are an exchange of ideas. Despite disagreements, both have pertinent points and the contradicting ideas only helps by given you multiple avenues to pursue a resolution. I generally look at any device more than 5 years to be older. Whole the protocol itself remains unchanged overall, there has been some enhancements added. Over the years, these enhancements add up enough to where the variables for operation can be different for the overall system. I wouldn't upgrade if things are working great for you (if everything is dual band). Minor issues can pop up with new and old alike. However, if you're using 10 year old devices such as the 2476, it's definitely worth upgrading. Cleaning your system is difficult and that hasn't changed much. The difference with newer devices are they are able to exist much better in a sub optimal environment. By default, I put filters on surge protectors/conditioners and power strips with multiple transformers plugged in. After that, I'll look at things on an individual basis such as microwaves and refrigerators which could potentially impact the system
larryllix Posted September 9, 2020 Posted September 9, 2020 (edited) 11 hours ago, someguy said: I apologize for bringing up a topic that created some conflict. I know I benefit from the discussion. I feel like a kid listening to adults discussing a topic that I know very little of. I have some questions: 1) which devices do we consider "older devices"? (Perhaps I'll upgrade some of my devices.) 2) a "clean system is the best.." but, in my opinion, cleaning a system is very difficult. Has the ability to clean up a system changed in the past five years? New devices to help find the trouble? or just better devices? and are they just better because of them being dual band or are there other improvements? (yes, this is kind of the same as my first question) Don't be sorry about it! We are all mostly more mature in this crowd except a few users, like..... whats-his-name? j/k I consider devices that are not dual band as old or needing replacement if they are ever upgraded. My Insteon noise makers are as people warned me for years but never thought it should be a problem. Chamberlain garage door openers. I have two vintages. One older AC motor with just electronic wall control, and one newer unit with DC motor, battery backup etc... I always wondered where the interference came from until I added the newer unit and it crippled my Insteon system abut 75%. Made it much easier to find. Then I unplugged both GDOs and it was like a new system again. Now two FilterLincs have resolved those problems. They are easy as any plug-in wallwart and I now have an extra for testing for future suspicions and testing. Edited September 10, 2020 by larryllix
kclenden Posted September 9, 2020 Posted September 9, 2020 7 hours ago, someguy said: I apologize for bringing up a topic that created some conflict. No worries. It's only through robust discussion that we really learn anything. 6 hours ago, lilyoyo1 said: Has the ability to clean up a system changed in the past five years? New devices to help find the trouble? No. 7 hours ago, someguy said: or just better devices? Yes. 7 hours ago, someguy said: are they just better because of them being dual band No. 7 hours ago, someguy said: are there other improvements? Yes. As an example, here is the lead paragraph to developer notes released in Feb 2012: We are making improvements in device firmware to help ensure INSTEON commands are sent in a more reliable manner. This includes the adding of checksum (CS) to commands that set a remote device’s properties, bit flags byte and database records. Also, internal protections have been added such as the ability to prevent device from acting on a message from a device not currently in its database, enhanced buffer corruption prevention and preventing invalid hop count messages from being hopped on the network. While the notes are from 2012, in my experience it can take a year, or two, for inventories of old devices to clear so that you know you're getting a new device when you buy, so I would consider devices that are roughly six years, or older, to be "old". One thing that has definitely changed, for the worse, is that Smarthome has pretty much stopped updating developers on changes. So while you can see when a device's firmware has been changed, you don't know what those changes were.
lilyoyo1 Posted September 10, 2020 Posted September 10, 2020 11 minutes ago, simonsoap said: I consider devices that are not dual band as old or needing replacement if they are ever upgraded. @larryllix I guess another trying to get their post count up by copying you
MrBill Posted September 10, 2020 Posted September 10, 2020 1 hour ago, lilyoyo1 said: @larryllix I guess another trying to get their post count up by copying you Actually its the link spam in the signature. this forum has been hit with a bunch of attempted link spammers lately, sadly once they start they just keep coming.
larryllix Posted September 10, 2020 Posted September 10, 2020 1 hour ago, MrBill said: Actually its the link spam in the signature. this forum has been hit with a bunch of attempted link spammers lately, sadly once they start they just keep coming. I got turned off by certain posters having so much garbage in their "signatures", I have had it disabled for years now. When a signature takes up my whole monitor page or is full of "Deep thoughts" or spam it is time to go. Unfortunately individual signature blocking is not an option. It makes it hard to follow continuity of a thread. @Michel KohanimThe forum could really use a limitation of lines on signature length. It is thread disruptive and so many users blocking it destroys a nice feature where posters can expose their equipment, firmware and interests to others. A limitation of X inches of space below any post would be a nice limitation if it could be implemented.
larryllix Posted September 10, 2020 Posted September 10, 2020 3 minutes ago, larryllix said: I got turned off by certain posters having so much garbage in their "signatures", I have had it disabled for years now. When a signature takes up my whole monitor page or is full of "Deep thoughts" or spam it is time to go. Unfortunately individual signature blocking is not an option. It makes it hard to follow continuity of a thread. @Michel KohanimThe forum could really use a limitation of lines on signature length. It is thread disruptive and so many users blocking it destroys a nice feature where posters can expose their equipment, firmware and interests to others. A limitation of X inches of space below any post would be a nice limitation if it could be implemented. Good luck!
Recommended Posts