Is it possible to have too many Insteon devices, thus causin

[ellesshoo]

I'm no expert on the underlying methods of insteon networks but was curious about this. Let's say I start with two devices in two different rooms connected by a hallway. Let's say they can communicate directly. What happens if a bunch of devices are added in between? Would the commands hop between all those closer devices to reach the target at the end or just go directly to the target bypassing all those devices?

[apostolakisl]

My understanding is as follows:

 

The original signal is sent out over the power lines. All devices within range will hear the signal. In a clean environment, that very well may be every device in your house, thus no hops needed. After a predetermined number of 60hz cycles on your power line, all the devices repeat the signal. Each repeat has an additional piece of info added that indicates it is a repeat until it hits 3 at which point it gives up. Once the target device receives the signal, an acknowledgement is sent which shuts down the hop process.

[Vyrolan]

Once the target device receives the signal, an acknowledgement is sent which shuts down the hop process.

Actually it just waits. Imagine you had a bunch of people in a room and you were doing Insteon-like repeating. Somebody shouts, and everyone who hears that shouts a repeat...you're trying to get the message across the room. The protocol may be to repeat 3 times... The original shout is "Message 2"...1 second later, everyone who heard it shouts "Message 1"...finally 1 second later, everyone who hears those shouts "Message 0" and it's complete. If the target person heard the original shout (he heard the original "Message 3"), he will have to just stand there and wait 2 more seconds while all of the repeating of the shout is going on. Then once everyone is done and quiet, only then would he acknowledge that he heard it.

 

Insteon is dual-band so two kinds of communication...to extend the metaphor, imagine the shouting is powerline, and a bunch of people (but not all) have signs and so they can hold up a written message as well...the signs are the RF. People with signs that hear a shout (or see a sign) both repeat it by shouting and by displaying it on their sign. Either way though, the "target" must wait for all the repeating to end (silent room with no signs displaying) before it can send its acknowledgement.

 

Of course, this all happens super duper fast in the Insteon world. You're looking at a quarter of a second or so for all of that to happen. =p

[oberkc]

Actually it just waits.

 

While I claim no particular knowledge about insteon communication and hops and waits and cycles, my perception is that my devices respond faster when good communication exists compared to when good communication does NOT exist. This tends to suggest, in my mind, that the responding devices are capable of responding before all repeats/hops. Am I missing something?

[ELA]

Hello ellesshoo,

In theory you could "run out of hops" with a long string of devices, on a long enough cable run, with limited RF communications capability.

 

Message timing can vary greatly depending upon whether it is scene or group send or a standard\extended direct message to one device.

 

Below all assumes a standard direct message sent with 3 hops:

Initially with good signal strength the initial send ( or hop #0) will be received by other devices. If the message was sent with 3 hops , all 3 hops will still be sent, but the message may be received right away at hop # 0.

 

As you add more devices to a cable run they each add to the attenuation of the signal strength. If you have good RF comms that can compensate for this. If you have limited RF capability then it is possible that the signal begins to degrade enough that some devices need to rely on simulcasted hops from other devices. They may receive at the 1st hop. If the line is long enough, with enough devices others down the line may receive on hops #2 or hop #3.

 

Another item that plays into how fast a device appears to respond is retries. If all 3 hops are used and the sender does not receive a acknowledge response it will retry several times, at the PLM level. Then on top of that the upper level application such as the ISY may also retry several times.

 

With really good communications the message exchange may only take ~100 milliseconds for the intended receiver to "hear" the command. As the comms begins to deteriorate the time to receive begins to increase.

It can take near to 1.5 seconds if the PLM is retrying up to 3 times. Even more if the PLM is not "hearing" any responses at all and retries 5 times.

 

Then on top of that if the PLM fails to get a response, the ISY may do retries on its own. I forget exactly but I think the ISY waits about 8-9 seconds if messages are failing to get any response?

[apostolakisl]

So would it be safe to say that the 3 hop and done is the Insteon standard, and that the entire 3 hop and done thing can start all over again once you involve a plm/isy?

 

And your saying that all three hops always occur even if it only took one hop? If indeed this is the case, then what is the purpose of sending an ACK (at least in a non-ISY environment)? In a non-ISY situation, why would any switch need to know the signal got there if it is going to repeat 3 times either way?

 

I'm not saying that this isn't the case, but from a logic standpoint it baffles me. I thought the purpose of the ACK was to shut things down to open up the power lines for other comm.

[ELA]

I tend to talk in terms of a PLM as the sender since I have done so much testing with them. I believe the device retries pertains to any Insteon Powerline sender.

 

I have not reviewed the Insteon details doc in a while but it covers the concept of time slots.

If the message is sent with 3 hops they will all be sent, even if the intended receiver hears the msg at hop#0. The time slots must be reserved for their intended purpose.

When the recipient sends its acknowledge MSG it must wait for the appropriate time slot, after the senders 3 hops slots. (Again assuming 3 hops max send).

Scene messaging and group sends attempt to improve on speed with another technique.

 

I cannot speak to all the why's of this protocol. Too much to review and respew. I speak from a combination of reading the Insteon details in the past and lots of of Oscope reviews of message exchanges.

Please do review the details doc and see if they provide justifications.

 

I am typing on my wife's iPad and I find I try to avoid typing too much with this keypad

[Vyrolan]

So would it be safe to say that the 3 hop and done is the Insteon standard, and that the entire 3 hop and done thing can start all over again once you involve a plm/isy?

Yes.

 

And your saying that all three hops always occur even if it only took one hop? If indeed this is the case, then what is the purpose of sending an ACK (at least in a non-ISY environment)? In a non-ISY situation, why would any switch need to know the signal got there if it is going to repeat 3 times either way?

You want acknowledgements for linking. If you are using set buttons to setup scenes, you for sure want acknowledgements so they can let you know if a communication was missed lest you end up with some really messed up scenarios.

 

I'm not saying that this isn't the case, but from a logic standpoint it baffles me. I thought the purpose of the ACK was to shut things down to open up the power lines for other comm.

The powerline is not full duplex...it's only half. There cannot be two messages at the same time since they all share the carrier. Think of it like the radios where when you are pressing the button to send, the other guy can't talk back. You might hold the button and say, "The mission is a go...I repeat, the mission is a go." Now someone hearing the other end can't push their button in the middle and say "ok, we got you the first time". They have to wait until you are done transmitting (including your repeat) before they can speak back. That's exactly why radio communications end with "Over". That's essentially the way of saying "I am done transmitting; you may transmit now." For Insteon devices, the "Over" is implied to be after the last hop. So the receiving device gets the message with 2 hops left, he must (and will) wait out those 2 hops so he knows "the other guy has stopped transmitting".

[apostolakisl]

So would it be safe to say that the 3 hop and done is the Insteon standard, and that the entire 3 hop and done thing can start all over again once you involve a plm/isy?

Yes.

 

And your saying that all three hops always occur even if it only took one hop? If indeed this is the case, then what is the purpose of sending an ACK (at least in a non-ISY environment)? In a non-ISY situation, why would any switch need to know the signal got there if it is going to repeat 3 times either way?

You want acknowledgements for linking. If you are using set buttons to setup scenes, you for sure want acknowledgements so they can let you know if a communication was missed lest you end up with some really messed up scenarios.

 

I'm not saying that this isn't the case, but from a logic standpoint it baffles me. I thought the purpose of the ACK was to shut things down to open up the power lines for other comm.

The powerline is not full duplex...it's only half. There cannot be two messages at the same time since they all share the carrier. Think of it like the radios where when you are pressing the button to send, the other guy can't talk back. You might hold the button and say, "The mission is a go...I repeat, the mission is a go." Now someone hearing the other end can't push their button in the middle and say "ok, we got you the first time". They have to wait until you are done transmitting (including your repeat) before they can speak back. That's exactly why radio communications end with "Over". That's essentially the way of saying "I am done transmitting; you may transmit now." For Insteon devices, the "Over" is implied to be after the last hop. So the receiving device gets the message with 2 hops left, he must (and will) wait out those 2 hops so he knows "the other guy has stopped transmitting".

 

An ACK during linking makes sense. But an ACK during a regular command still doesn't make sense and in fact would just add needless noise. Aside from having an ISY which might repeat the entire process if an ACK isn't received, regular Insteon stuff doesn't seem to make any use of it.

 

I get your analogy about the radio. But you could also "let off the button" in between the 3 hops, wait for an ACK, and then push the button again if none is received. I kind of feel like I am watching Beetle Juice here.

 

So I understand that it is the way it is, but the necessity of the ACK seems to be missing. Even in an ISY environment, the ACK doesn't serve much use. If the message didn't get through on the first 3 hops, what do you think the odds are that doing the exact same 3 hop sequence a second time will turn out any different? My bet is pretty slim. Perhaps if a noise maker quit making noise in that split second between the first and second try. Benjamin Franklin once said, "only a fool does the same thing twice and expects a different result".

[ELA]

When an Insteon message is repeated or simulcasted multiple times that is not really doing the same thing over and over.

I am not going to go so far as to praise the Insteon hardware/protocol because I know it has issues.

 

For sure if your network is pristine messages will get though and no need to repeat or ack anything.

I can get 100% success with sending zero max hop messages in a good portion of my home network, but not all of it.

 

However what you may be missing is the fact that the network impedance is always changing.

When hops are repeated there may be different combinations of devices contributing(Simulcasting). If you look at a few of the Oscope pictures I have posted you can see that the hops almost never look identical to each other ( in a busy-non isolated network).

 

In the thread below there are many pictures and descriptions of marginal communication situations. I point to this one particular post that speaks directly to your suspicion that retries may not be effective.

 

http://forum.universal-devices.com/viewtopic.php?p=54985#p54985

 

The statistics there show several devices that are relying completely on retries to complete a message exchange. Some devices were 100% successful, but had to constantly rely on retries to do it. Others occasionally failed to receive even with retries and the success rate dropped off.

This is common of marginal communications, where retries often make all the difference in getting the message through. When you are relying on retries however, you are extra susceptible to occasional complete misses when anything at all changes in the network.

That particular post was speaking to the effect of moving the PLM and the drastic change in the reliability statistics as a result. ( some people do not believe the PLM placement matters

 

I always strive to observe no retries to be occurring in my network. However they can be very helpful if or when it is a marginal network.

[Vyrolan]

if an ACK isn't received, regular Insteon stuff doesn't seem to make any use of it.

They blink if responders don't ack so you know there is an issue.

 

I get your analogy about the radio. But you could also "let off the button" in between the 3 hops, wait for an ACK, and then push the button again if none is received. I kind of feel like I am watching Beetle Juice here.

How long are you supposed to wait? What if the messages gets to the destination on the first hop, but the ack fails and needs multiple hops?

 

Also, the later hops aren't sent by the originator of the message...they are sent by all who received the first hop. How are all of those supposed to know not to send if the first hop was received by the destination? They would all need to receive the acknowledgement to know to stop...and that's asking a lot for reliability. Also, they would need the ability to queue up these "to be sent as later hops" while waiting for acknowledgements.

 

Further, how does a device know when a transmission is complete then? If 1 hop is sent, then all who receive it queue it up (they won't send hop 2 until they know there's not an ack in your scenario), then is that just dead time? Can another device send a different message in the middle? Now you're interleaving the messages....everything that hears the second device's message is queuing up two messages that may or may not be sent based on whether or not acknowledgements are received. If they can't interleave, then you're just injecting waiting for nothing...actually slowing things down instead of speeding things up. For the worst case when two devices need all the hops to communicate each way, waiting just 1 unit of time for acknowledgements would add 300ms total.

 

Another example is a Triggerlinc communicating with a powerline-only switch. On the first hop which is RF only from the Triggerlinc, there is no way it was received because the destination is not dual band...so by waiting for the acknowledgement you're just slowing things down. Ditto for any two source/destination that rely on other dual band devices to bridge phases.

 

To be honest I think you are drastically underestimating the complexity. It would add a ton of complexity to the devices to be able to preempt the send with an acknowledge, and even in good scenarios it would save very minimal time. That's also assuming you only wait 1 unit of time for the acknowledgement which would be wrought with problems without adding a ton of complexity. A big part of the reliability of Insteon is the simulcasted repeats where the signals add to each other...leading to the "more devices you have the better it works" situation. With complexity of trying to preempt that process, it would probably be the exact opposite where more devices yields less reliability.

 

So I understand that it is the way it is, but the necessity of the ACK seems to be missing. Even in an ISY environment, the ACK doesn't serve much use.

The "fire and forget" of X10 was always considered a problem because you never knew for sure what was happening. In general, it's always better to know if your message was received than to just assume it, so I imagine some of that is future proofing for devices that may do more advanced communications. I'd certainly want the ISY to receive acknowledgements so it can retry or it can at least let me know it failed to communicate. (I actually wish the ISY did more around them.) The acks can also contain data...the acks may not be that useful for "On" and "Off, but they sure are for "Query".

 

If the message didn't get through on the first 3 hops, what do you think the odds are that doing the exact same 3 hop sequence a second time will turn out any different? My bet is pretty slim. Perhaps if a noise maker quit making noise in that split second between the first and second try.

Well hops and retries are separate. Retries I can kind of agree with as being a bit excessive for anything beyond linking, but we deal with intermittent communications issues on these forums all the time, so I wouldn't say the chance is that slim.

 

Benjamin Franklin once said, "only a fool does the same thing twice and expects a different result".

Who knows who actually said that... Variations are attributed to many people including Albert Einstein.

[apostolakisl]

There are quite a few flaws to the Insteon logic in my opinion which is probably why it works like 99% of the time instead of 100%. Not that they haven't made the best of less than perfect environment, or maybe not, I really can't say.

 

For example, for a 3 hop timeslot to be reserved, all the devices have to receive the first broadcast. If a device is 2 hops away from getting the message, it could start its own separate broadcast while the first signal is still in the midst of those 2 hops. Then you get 2 overlapping messages and I just don't know what the devices make of that.

 

Having lots of devices helps with the exponential growth of the signal as it hops, but it also increases the possibility of getting simultaneous broadcasts.

 

My wife says, "yes it is possible to have too many Insteon devices, thus causing marital difficulties"