From: Marc M. <ma...@me...> - 2009-04-18 20:38:47
|
On Sat, Apr 18, 2009 at 03:08:43PM -0400, Gregg Liming wrote: > 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 Ok, it was hard to know for sure since I didn't know what baseline was supposed to be. > 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. Understood. So, I have 3/4th of my house unplugged right now or shut off at the circuit breaker, and still got this on a scan link table on $fmr_kpl: 18/04/2009 13:32:22 [Insteon_Device] WARN: queue timer on $fmr_kpl expired. Attempting resend: peek 18/04/2009 13:32:45 [Insteon_Device] WARN: queue timer on $fmr_kpl expired. Attempting resend: peek 18/04/2009 13:32:55 [Insteon_Device] WARN: queue timer on $fmr_kpl expired. Attempting resend: peek 18/04/2009 13:34:01 [Insteon_Device] WARN: queue timer on $fmr_kpl expired. Attempting resend: peek 18/04/2009 13:35:07 [Insteon_Device] WARN: queue timer on $fmr_kpl expired. Attempting resend: peek so, no good :( Grumble, from here, I have very little left I can remove. I'm now wondering if it's remotely possible that a switch/KPL I recently added can be deffective in a way that it's damaging signals. > 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. Oh boy, that's a fun one too... (that and the problem with putting scenes from motion sensors to switches doesn't really work with sync all links, while not having the scene removes half the pairing) I now see your beef with each device being suttly different. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |