From: cjm5035 <cmc...@co...> - 2010-10-18 22:45:24
|
Chris Engel wrote: > > I have had the same issue and this was my attempt to reset MH after the > serial port changed, is this similar to what you have attempted ? > > Index: mh.1003/lib/Insteon_PLM.pm > =================================================================== > --- mh.1003.orig/lib/Insteon_PLM.pm > +++ mh.1003/lib/Insteon_PLM.pm > @@ -283,6 +283,8 @@ sub check_for_data { > . " This may reflect a problem with your > environment."); > $$plm{xmit_in_progress} = 0; > pop(@{$$plm{command_stack2}}); # pop the active command > off > the queue > + &::print_log("[Insteon_PLM] WARN: Resetting serial port to > attempt recovery"); > + $plm->reset_serial_object(); > $plm->send_plm_cmd(); > } else { > &::print_log("[Insteon_PLM] PLM xmit timer expired but no > transmission in place. Moving on...") if $main::Debug{insteon}; > > I appears to be triggering, not sure if it was really an issue but > "shouldn't" cause any problems I don't think. > > [cengel@kitchen logs]$ grep "Resetting serial" print.log* > print.log:17/10/2010 13:38:47 [Insteon_PLM] WARN: Resetting serial port > to > attempt recovery > -- > Chris > > - > You are ahead of me a bit, Chris. Before implementing a reset at that location in Insteon_PLM.pm, I added code to Insteon_Device.pm to watch and record retry activity: 527 } else { 528 &::print_log("[Insteon_Device] WARN: queue timer on " . $self->get_object_name 529. 530 " expired. Trying next command if queued."); 531 $$self{m_status_request_pending} = 0; # hack--need a better way 532 if ($self->queue_timer_callback) { 533 if ($$self{_prior_msg} and ($$self{_prior_msg}{is_synchronous})) { 534 # get rid of any pending next command as we need to abort 535 pop(@{$$self{command_stack}}); 536 } 537 $callback = $self->queue_timer_callback; 538 $self->queue_timer_callback(''); # reset to prevent repeat callbacks 539 } 540#cjm Failure point for diagnostic 541 #increment a counter to capture number of failed retry events 542 $cjm_retry_fail_count ++; 543 &::print_log("[Insteon_Device] cjmDiagnostic: retry counter incremented to value 544= " . $cjm_retry_fail_count . 545 " in module Insteon_Device.pm ."); 546 } Since implementing, I have only recorded activity (that I have seen) when an Insteon switch was powered down by an open circuit breaker. I have yet to experience a 'glitch' and move of /dev/ttyUSB0 to /dev/ttyUSB1. I added your Insteon_PLM.pm code and will watch it. Also: What change management package are you using (in your code snippet above)? -- View this message in context: http://old.nabble.com/My-PLM-Died-Again-tp29986657p29995527.html Sent from the Misterhouse - User mailing list archive at Nabble.com. |