Re: [mh] What level of insteon errors/drops is ok?

[Gregg L. <gr...@li...>]

Marc MERLIN wrote:
> I'm trying to debug my house and I'm honestly not sure what the subjective
> threshold between ok and not ok is

> Note, my setup makes a full bus rescan (as in loop that requests state of
> each device) every 15mn so I have more chance to generate those than you :)
> 
> Also, to debug, I change stuff and just tell mh to ask all the devices for
> their state above. Then I could how many erros I got.
> 
> I just have no idea how many background noise/errors are reasonably
> acceptable, if any.

So, here's the deal... If you barrage the powerline w/ a lot of traffic, 
you will get collisions and those will result in resends. The trick is 
to try to avoid it to the extent possible.  The initial start-up status 
scan is deliberately done asynchronously--which means that the 
opportunity for collisions is greatest.  I don't worry about that as I 
may get a couple of collisions, but the resend(s) always gets through. 
Now, what I would be *very* concerned about is any significant number of 
resends while doing memory operations--which are synchronous.

I'm mentioning the above because your request for data would me 
meaningless unless it was properly qualified w/ the conditions in which 
the resends occur (and, those can't be easily extracted from logs).  I 
can tell you anecdotally that I never get resends when doing any memory 
operations and routinely get 2-3 resends when the "barrage" status scans 
are performed.  If you see the same results, then you are fine.  Also, 
realize that I run w/ the fastest settings possible (i.e., no throttling 
and minimal, inter-send delays).

One area that I frequently see a resend is associated w/ the triggering 
of a light based upon an insteon motion sensor.  This is because (for 
some who knows why reason), the motion sensor sends two reports w/ a 
slight delay (less than a second) between them.  The state is set on the 
first report.  So, if I then immediately turn on a light, then there is 
an opportunity for the light's insteon ACK to collide w/ the second 
motion sensor report.  That's quite annoying.  Possibly, I'll work on 
something to address it as a part of the second phase of refactoring.

Gregg