So, I have seen a lot of random issues with the PLM reconnect code.  I have made a new branch that adds an INI setting for enabling this, it is disabled by default.  If you have PLM issues, or the prior code had bad effects on your setup, please read and testout the following code:

https://github.com/hollie/misterhouse/pull/444

Please let me know how it works for you.

Kevin


On Sun, May 18, 2014 at 10:24 AM, Jim Cox <james.s.cox@gmail.com> wrote:
Hi Kevin.  I turned up the insteon debug level to 4 and ran misterhouse directly from the command line.  I also added two logging statements to bin/mh:

  # Recommended Steps to Close a Serial Port from CPAN
   ::print_log("Attempting to close:  $name  port:  $port" );
   $Serial_Ports{$name}{object}->close() || ::print_log("[Insteon_PLM] Close of serial port failed.");
   ::print_log("Closed." );


Here is the output right before a hang:


18/05/2014 12:04:39 PM Running: dr lamp 20%
18/05/2014 12:04:39 PM [Insteon_PLM] DEBUG2: Sending obj=$dr_lamp; command=on; extra=33 incurred delay of 0.00 seconds; starting hop-count: 1
18/05/2014 12:04:39 PM [Insteon_PLM] DEBUG3: Sending  PLM raw data: 02620ea1a6051133
18/05/2014 12:04:39 PM [Insteon_PLM] DEBUG4:
         PLM Command: (0262) insteon_send
              To Address: 0e:a1:a6
           Message Flags: 05
                Message Type: (000) Direct Message
              Message Length: (0) Standard Length
                   Hops Left: 1
                    Max Hops: 1
         Insteon Message: 1133
                       Cmd 1: (11) Light ON
                       Cmd 2: (33) Level

18/05/2014 12:04:39 PM [Insteon::BaseObject] $dr_lamp::set(20%, )
18/05/2014 12:04:41 PM [Insteon::BaseMessage] WARN: now resending obj=$dr_lamp; command=on; extra=33 after 1 attempts.
18/05/2014 12:04:41 PM [Insteon::BaseObject] DEBUG3: Adding hop count of 2 to hop_array of $dr_lamp
18/05/2014 12:04:41 PM [Insteon::BaseObject] DEBUG4: $dr_lamp->default_hop_count()=1 :: hop_array[]=211
18/05/2014 12:04:41 PM [Insteon_PLM] WARN: The PLM did not respond to the last command. The port may have closed, attempting to reopen the port.
18/05/2014 12:04:41 PM Attempting to close:  Insteon_PLM  port:  /dev/insteon


Obviously it's hanging on the close.  Kill -9 on the process does not stop misterhouse.


Other info which might be useful:

# perl -e 'use Device::SerialPort 9999'
Device::SerialPort version 9999 required--this is only version 1.04 at -e line 1.


And when I run the following script:


#! /usr/bin/perl -w

use strict;

use Device::SerialPort qw( :PARAM :STAT 0.07 );

my $PortName = '/dev/insteon';
my $ob = new Device::SerialPort ($PortName, 0) || die "Can't open $PortName: $!\n";
my $baud = $ob->baudrate;
my $parity = $ob->parity;
my $data = $ob->databits;
my $stop = $ob->stopbits;
my $hshake = $ob->handshake;

print "B = $baud, D = $data, S = $stop, P = $parity, 
            H = $hshake\n";


$ob->close();
print "first close OK\n";
$ob->close();
print "second close OK\n";
undef $ob; 

$ob->close();
print "third close OK\n";


I get:


B = 9600, D = 8, S = 1, P = none, 
            H = none
Request to send
Data terminal ready
first close OK
second close OK
Can't call method "close" on an undefined value at ./serial.pl line 35.


which is pretty much what I would expect.


Thanks,
Jim

















On Thu, May 15, 2014 at 2:54 PM, Kevin Robert Keegan <kevin@krkeegan.com> wrote:
Jim, this looks like this is a bug that was introduced when I added the feature to reconnect the PLM.  It seems like this is something specific to Gentoo, which I know nothing about.

I am hoping that perl is providing some error messages that might help diagnose the problem.  Can you enable level 4 debugging for insteon? And run misterhouse from the command line and not as a service?  The next time this error occurs, can you send me the command line output around this error?


On Tue, May 13, 2014 at 6:15 PM, Jim Cox <james.s.cox@gmail.com> wrote:
The current insteon code on the master branch is causing me issues.  I am running misterhouse on a 3.12.13 gentoo box.  At some point, either during start up, or while trying to control lights through the web interface, I get the following:


13/05/2014 05:58:07 PM [Insteon::BaseObject] received engine version for $kitchen4_back_master of I2. hops left: 0
13/05/2014 05:58:09 PM [Insteon::BaseMessage] WARN: now resending obj=$kitchen4_backyard_flood; command=get_engine_version after 1 attempts.
13/05/2014 05:58:09 PM [Insteon_PLM] WARN: The PLM did not respond to the last command. The port may have closed, attempting to reopen the port.

At this point, Misterhouse freezes and becomes unresponsive.  When I try to restart the service:

# service misterhouse stop
 * Stopping misterhouse ...
 * start-stop-daemon: 1 process refused to stop
 * Failed to stop misterhouse                                                                                     [ !! ]
 * ERROR: misterhouse failed to stop

Trying to kill -9 the misterhouse process has no effect.  I need to reboot.  I've tried resetting the usb port, but that too hangs when it gets to the PLM. 

After downgrading to stable, I am no longer experiencing freezes.  I am still unable to cleanly stop the misterhouse service; but this is something I probably would not have noticed as I do not ordinarily do this.

Thanks,
Jim


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users