From: Marc M. <ma...@me...> - 2009-03-15 16:18:03
|
On Sun, Mar 15, 2009 at 07:29:19AM -0400, Gregg Liming wrote: > > after that, I'm not too sure what happens exactly, how long/how many times > > mh tries to resend that unacked command before giving up, and how this is > > involved: > > @ In addition, you can adjust the duration before mh will requeue a > > @ transmitted message when it has not recevied an ack. The default is 15 > > @ seconds and is likely sufficient for most cases. To adjust: > > Insteon_PLM_max_queue_time=5 > > mh waits up to Insteon_PLM_max_queue_time for receipt of an ACK. If an > ACK is not received w/i that time, it will retry. Gotcha, so while devices themselves do 2 retries within 1 sec or somesuch, a plm initiated command has no implied retries, the software is supposed to watch for acks and send retries. I just improved the new wiki page and the existing one to clarify that there are 2 retries at most for a total time of Insteon_PLM_max_queue_time x 2 + 1sec before mh gives up and the command gets dropped. New text is: @ You can adjust the duration before mh will requeue a transmitted @ message when it has not recevied an ack. The default is 15 seconds and @ is likely sufficient for most cases (5 means quicker retries and less @ delay for the next commands) @ mh will retry the command twice and then give up and move on. @ This means, mh will wait up to Insteon_PLM_max_queue_time x2 + 1sec @ before giving up and sending the next command in the queue (all commands @ wait in line before the current one has been acked). Insteon_PLM_max_queue_time=5 > > Is the text I have correct? I.e. does it mean mh tries resending an unacked command > > every 5 seconds forever? > > A total of two retries. I take it the number of retries is not tunable, right? > > If not, what actually happens? > > You see the message and any pending next command is attempted; nothing > occurs if none exists. but if there is no next command, I still get some " WARN: queue timer on $fmr_outside expired" to know my command got dropped, just a differeng log line, right? > > More importantly, is it an error that means that the command was lost and mh gave up > > sending it, potentially leaving my outside light on? > > It means that there is a problem w/ your insteon environment. Usually, > it exists because of excess messages and resulting collisions. Right. In this case it's indeed a motion sensor that triggers a bunch of light toggles, and with short timeouts I was probably overwhelming the bus a bit. > > For now, I unset those two, just in case: > > #Insteon_PLM_disable_throttling=1 > > #Insteon_PLM_xmit_delay=0.15 > > Because those two settings impact the timing of messages and how many > can be put onto the powerline, then they indirectly can influence the > above. In general, however, intelligent practices are enough. For Right. I disabled them earlier for some testing, but they may actually have been the indirect cause of my message being dropped. Now the crucial question: Assuming there is no setting for mh to retry more than twice (although that's of course only one number to change in the code) and that mh cannot put an unacked command at the end of the command queue for retrying later: Is there a programmatical way to see whether a command got lost outside of grepping print.log? I'm specifically thinking about an expensive high wattage device that would stay on for hours too many, or some kind of fish water pump that would burn up if never turned off, maybe causing the fish to die if you're gone on a 3 week trip (I'm reaching a bit, but you get the idea :) ). Thanks for the details, 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/ |