Re: [mh] Insteon PLM "wedged"

[xhawkx <xh...@ya...>]

I am probably out of my league here... but have you tried using an inline serial port LED device to see if the there is a change in one of the other signal lines when you have the wedging symptoms? I am not familiar with the Insteon PLM device, but maybe the CTS (Clear to send) isn't active anymore... or Data set ready... etc...
You can find more information on RS-232 communication on this site that may help you decipher your problems.

http://www.lammertbies.nl/comm/cable/RS-232.html

Links to testers I am refering to.
9-pin:  http://www.usbgear.com/DB9-TERS.html
25-pin: http://www.stayonline.com/detail.aspx?ID=198







----- Original Message ----
From: "rb...@ca..." <rb...@ca...>
To: MH-Users <mis...@li...>
Sent: Wednesday, September 3, 2008 11:20:43 AM
Subject: [mh] Insteon PLM "wedged"

I can't believe it's taken me this long to come to this diagnosis. I'd appreciate a sanity check on my testing methodology from those familiar with the PLM.

Issue:
The PLM becomes "unresponsive" to the serial port after some seemingly arbitrary time|event.

Conditions:
PLM is mostly used to send X10 commands to X10 switches. Also, I currently run a TED, which communicates over the powerline at a frequency 125kHz (X10's is 120kHz). The TED is quite chatty, xmitting data every second, so collisions are inevitable. That said, during the time PLM works, is seems to have been "as effective" or better than the CM11.

Testing Methodology:
I instrumented Insteon_PLM.pm with some print statements largely around the  {xmit_in_progress} flag to see where and when this flag is set and if it persists across check_for_data() -> check_for_generic_serial_data call.

Under proper operation, xmit_in_progress is set and released within 2 passes. When the PLM becomes wedged, xmit_in_progress persists through many passes and is finally cleared after a timeout after a lack of an ack by PLM.

The question became: Is the serial port really sending data to the PLM, or is the send being "lost" in the OS somewhere?

Test & answer: 
1) connected a null modem cable to an extra serial port on the machine 
2) launched minicom -s and config'd it to the extra port w\19200, 8N1
3) enabled local echo (CRTL-Z E) and line feed (CRTL-Z A) w\i minicom
4) launch mh and wait for symptoms of wedging (i.e. "[Insteon_PLM] WARN: No acknowledgement from PLM..." after every send) (Note: I have a phantom X10 event toggling a switch every 30 seconds).
5) between sends, disconnect the PLM serial cable and connect the other end of the minicom serial port null modem cable to the serial port the PLM was connected to..

If data in minicom, then PLM probably wedged?

I see data. It's binary, so I don't know what the data really is, but it repeats, so it appears to be the same X10 ON\OFF commands over and over.

Additional (puzzling) observations:
1) If I hit the reset button on the PLM, no change.
2) If I unplug the PLM, count 5, then replug... no change.
3) If I stop and restart MH, then comm works for awhile again.

Questions:
1) Is there a way to determine the firmware revision of this PLM?
2) What's the purpose of plm_reset => 0x67 and user_user_reset => 0x55 respectively, and what would be the proper coding syntax for sending either to try and "unwedge" the PLM?
3) What could it be about serial_port_create() that "revives" the PLM? (this is what is called at mh startup).

As always, thanks,

Rick




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365