Re: [mh] INSTEON mesh network

[Eloy P. <pe...@ch...>]

Hi Chris,

On 04/28/2013 12:28 PM, Chris Dragon wrote:

> Marc MERLIN-7 wrote
>>
>> I thought that insteon was slow enough that even restransmitted messages
>> were effectively synchronous with the orignal message (unless we're
>> talking
>> about the restransmit one second later because the first message didn't
>> make it).
>>
>> Is that not true?
>
> I just went and read page 23 of insteondetails.pdf and what you're probably
> thinking of is that retransmissions are synchronous.  Things are
> synchronized using the powerline cycles using six cycles for a standard
> message and 13 for an extended.  Those periods are called time slots.  If a
> message has 3 max hops set and > 0 hops left set, then every device that
> received the message in the first time slot will retransmit it with hops
> left - 1 in the next time slot.  It doesn't hurt that multiple devices are
> sending at the same time because they're synchronized to transmit at exactly
> the same time when the next timeslot starts.  The device that needs to send
> an ACK will know it needs to wait to send that ACK until all the
> retransmission timeslots have completed, which is why sending a message with
> max hops 3 takes so long - it uses 4 timeslots to repeat the message, then 4
> timeslots to repeat the acknowledgement.
>
> Page 28: "If the originator of an INSTEON Direct message does not receive an
> acknowledgement from the intended recipient, the message originator will
> automatically try resending the message up to five times. Additional retries
> are carried out if the application simply resends the message.
> In case a message did not get through because Max Hops was set too low, each
> time the message originator retries a message, it also increases Max Hops up
> to the limit of three. A larger number of Max Hops can achieve greater range
> for the message by allowing more devices to retransmit it.
> Firmware in the INSTEON Engine handles message retrying. After using the
> INSTEON Engine to send a Direct message, applications will either receive
> the expected acknowledgement message or an indication that the intended
> recipient did not receive the Direct message after five retries."
>
> Page 35: Standard message timeslot is 50 milliseconds, extended is 108.33.
> So it would take 50*8=400ms (almost half a second) to transmit a 3 hop
> standard message and wait for the ACK.  When it says it retries up to 5
> times I'm assuming it starts at 1 max hops, allowing 1 timeslot for
> transmission, 1 to repeat transmission, 1 for ACK, and 1 to repeat ACK.
> When the message repeats with 2 max hops it will take 6 timeslots, then the
> 3rd repeat with 3 max hops takes 8 timeslots, 4th repeat 3 max hops 8
> timeslots, and the 5th repeat would use 3 max hops again for 8 timeslots.
> That's 4+6+8+8+8=34*50ms=1700ms (1.7 seconds).
>
> That 1.7 seconds is why they warn you to unlink responders before you retire
> a device because it wastes a lot of time sending a message to a device that
> never responds.
>
> In my system I seem to always see standard messages with max hops 1 and
> remaining hops 1 or 0.  In fact, that's true even of a wireless device near
> the PLM so I think devices must start with max hops 1 instead of 0 in most
> (all?) cases.  And in most systems, that will be enough to get the message
> to the PLM without retrying the message with max hops + 1.
>
> So if kpl_garage sends its message with 1 max hops and doesn't get an ACK by
> the 4th timeslot, it will retry 200ms after its first transmission with max
> hops 2, then again in 400ms with max hops 3, and so on.  If MH sees those
> retries, it will see the same message repeated with max hops + 1 and it
> should ignore them if a retry occurs within 200ms of a previous max hop 1
> message or 400ms of a max hop 2.
>
> I see in Eloy's log "Message received with 2 hops left", then "Message
> received with 1 hops left", then just  message received (0 hops left,
> presumably).

Correct, no log message that indicates the number of hops left means 
that $msg{hopsleft} = 0.

> So the 3 messages he's seeing are probably from a message with
> max hops 2 and hops remaining 2, retransmitted by neighbor devices with hops
> remaining 1, then again with hops remaining 0.  The PLM should definitely
> expect a 2 max hop message to retransmit twice and it could only pass one of
> those on to MH, but it looks like it instead passes all 3 to MH.  In that
> case, MH should ignore the same message with same max hops but hops left - 1
> received within around 50ms of the previous message.

I just created Github issue #169 for this. I don't know if I articulated 
things properly but I did mention the great analysis you have done in 
this thread.

Cheers,

Eloy Paris.-