From: Rick B. <rb...@ca...> - 2008-08-21 17:04:58
|
I'm finally trying to dig into this more deeply. Problem: W800 stops communicating with MH. Interestingly, if I "poke" the W800 (read 4 bytes) with sjinn, that "clears" the block and W800 & MH communicate again for awhile. At times, there can be a steady stream of "garbage" characters coming thru. This is visable with "serial" logging enabled. Unfortunately, some combination of this garbage can hose the console window character set or terminal type and then normal print text changes to all kinds of high bit ANSI characters. But eventually, a reset command streams in and proper console text can (partially) reappear (I may change the check_for_generic_serial_data() print statement to output hex). I've emailed WGL Designs, and they confirm that the W800 requires no flow control. They also don't suspect thermal or unfiltered power supply hash to be responsible based on the conditions it operates under. I've monitored the 310Mhz frequency and can detect when legitimate codes are broadcast, but I don't receive any discernable rf signal when the stream of trash is rolling in. So I'm looking for advice on instrumenting code to log more of what is happening. I need to understand the basic flow. In the end, does MH read the serial port as if it were a socket? Do we pole the socket every pass thru the code? Or are we waiting for some signal or notification? Thanks, Rick Ubuntu 8.04 (hardy), Moxa Smartio, PC2500E mobo, W800RF32 |
From: H P. <hp...@gm...> - 2008-08-22 03:47:19
|
I might have had a similar problem -- Gregg has helped me narrow down the problem to the Serial_Item. If I connect directly to the serial port in my main instance (what processes all light, motion events, speech, etc...). My W800 stops working after about a day. A MH restart brings the device back to life. I've since set up a separate instance that uses the proxy code to talk to the W800. This has been solid, and working for close to 3 weeks. Gregg has asked me to do some other testing, however I just haven't got around to it. It might be worthwhile for you to try this out, and make sure that you set sleep_time=100 and sleep_count=1 in your proxy's private mh.ini On 21-Aug-08, at 11:04 AM, Rick Bolen wrote: > I'm finally trying to dig into this more deeply. > > Problem: > W800 stops communicating with MH. > > Interestingly, if I "poke" the W800 (read 4 bytes) with sjinn, that > "clears" > the block and W800 & MH communicate again for awhile. > > At times, there can be a steady stream of "garbage" characters > coming thru. > This is visable with "serial" logging enabled. Unfortunately, some > combination of this garbage can hose the console window character > set or > terminal type and then normal print text changes to all kinds of > high bit > ANSI characters. But eventually, a reset command streams in and proper > console text can (partially) reappear (I may change the > check_for_generic_serial_data() print statement to output hex). > > I've emailed WGL Designs, and they confirm that the W800 requires no > flow > control. They also don't suspect thermal or unfiltered power supply > hash to > be responsible based on the conditions it operates under. I've > monitored the > 310Mhz frequency and can detect when legitimate codes are broadcast, > but I > don't receive any discernable rf signal when the stream of trash is > rolling > in. > > So I'm looking for advice on instrumenting code to log more of what is > happening. I need to understand the basic flow. > > In the end, does MH read the serial port as if it were a socket? > > Do we pole the socket every pass thru the code? Or are we waiting > for some > signal or notification? > > Thanks, > > Rick > Ubuntu 8.04 (hardy), Moxa Smartio, PC2500E mobo, W800RF32 > > > > > ------------------------------------------------------------------------- > 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 > |
From: Rick B. <rb...@ca...> - 2008-08-25 20:05:16
|
I had worked on this for most of last week, and thought I had it licked, but it happened again this morning. The main changes i had made that seemed to have improved things was: 1) I added logging; 2) I changed to the current SerialPort.pm from CPAN; 3) I ran MH from a console window. The logging I added was interesting in that it logged *anytime* we had data from the W800. At times this spit out data almost every iteration. On occasion the "stream" would stop... sometimes related to when a motion sensor would fire, and then resume... sometimes when the motion sensor would report "still" status... sometimes not... sometimes seemingly randomly. Normal logging doesn't show this because MH only logs W800 acitvity if it sees that the data is *the second repeat* of the data (X10 motion sensors appear the resend their data several times - MH only triggers on the second time). So among other things, I'm trying to figure out where this data stream is coming from??? Is it really coming from the W800, or is some other process writing\barfing on the W800 port\buffer? Anyone know how I can find out which processes have a port open system-wide? Yesterday I turned off the logging and rebooted the machine which started MH in the background. This morning I had the failure. So it seems that there could be a timing issue (since printing data to a console window tends to slow things down - and I had turned that logging off, and resumed running MH as a daemon). I haven't tried the mh parms you mentioned yet. I'll try that today, but I'm not gonna run a separate instance of MH. Rick > -----Original Message----- > From: mis...@li... > [mailto:mis...@li...]On Behalf Of H > Plato > Sent: Thursday, August 21, 2008 11:47 PM > To: The main list for the MisterHouse home automation program > Subject: Re: [mh] W800 communication problem > > > I might have had a similar problem -- Gregg has helped me narrow down > the problem to the Serial_Item. If I connect directly to the serial > port in my main instance (what processes all light, motion events, > speech, etc...). My W800 stops working after about a day. A MH restart > brings the device back to life. > > I've since set up a separate instance that uses the proxy code to talk > to the W800. This has been solid, and working for close to 3 weeks. > Gregg has asked me to do some other testing, however I just haven't > got around to it. > > It might be worthwhile for you to try this out, and make sure that you > set sleep_time=100 and sleep_count=1 in your proxy's private mh.ini > > > On 21-Aug-08, at 11:04 AM, Rick Bolen wrote: > > > I'm finally trying to dig into this more deeply. > > > > Problem: > > W800 stops communicating with MH. > > > > Interestingly, if I "poke" the W800 (read 4 bytes) with sjinn, that > > "clears" > > the block and W800 & MH communicate again for awhile. > > > > At times, there can be a steady stream of "garbage" characters > > coming thru. > > This is visable with "serial" logging enabled. Unfortunately, some > > combination of this garbage can hose the console window character > > set or > > terminal type and then normal print text changes to all kinds of > > high bit > > ANSI characters. But eventually, a reset command streams in and proper > > console text can (partially) reappear (I may change the > > check_for_generic_serial_data() print statement to output hex). > > > > I've emailed WGL Designs, and they confirm that the W800 requires no > > flow > > control. They also don't suspect thermal or unfiltered power supply > > hash to > > be responsible based on the conditions it operates under. I've > > monitored the > > 310Mhz frequency and can detect when legitimate codes are broadcast, > > but I > > don't receive any discernable rf signal when the stream of trash is > > rolling > > in. > > > > So I'm looking for advice on instrumenting code to log more of what is > > happening. I need to understand the basic flow. > > > > In the end, does MH read the serial port as if it were a socket? > > > > Do we pole the socket every pass thru the code? Or are we waiting > > for some > > signal or notification? > > > > Thanks, > > > > Rick > > Ubuntu 8.04 (hardy), Moxa Smartio, PC2500E mobo, W800RF32 > > > > > > > > > > > ------------------------------------------------------------------------- > > 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 > ------------------------------------------------------------------------- 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 |
From: Gregg L. <gr...@li...> - 2008-08-26 03:11:47
|
Rick Bolen wrote: > The main changes i had made that seemed to have improved things was: 1) I > added logging; 2) I changed to the current SerialPort.pm from CPAN; I did this years ago and it seemed, anecdotally, to improve things. I'm not sure why it was never incorporated. In my setup, I had to copy the lib created via CPAN into the lib/site/device area w/i mh since @INC give precedence to that location vice system libs. > The logging I added was interesting in that it logged *anytime* we had data > from the W800. At times this spit out data almost every iteration. On > occasion the "stream" would stop... sometimes related to when a motion > sensor would fire, and then resume... sometimes when the motion sensor would > report "still" status... sometimes not... sometimes seemingly randomly. > > Normal logging doesn't show this because MH only logs W800 acitvity if it > sees that the data is *the second repeat* of the data (X10 motion sensors > appear the resend their data several times - MH only triggers on the second > time). I had wondered about this when I recently rewrote the W800 lib (which has not been committed as yet). I also saw/experienced the same. Given the age of the w800 lib; either this has been fundamentally broken in mh for years (which is not beyond the scope of possibility) or that is the way that the w800 operates. I can't find wgl info to suggest one way or the other. > So among other things, I'm trying to figure out where this data stream is > coming from??? Is it really coming from the W800 AFAICT, yes. > So it seems that there could be a timing issue (since printing data to a > console window tends to slow things down - and I had turned that logging > off, and resumed running MH as a daemon). > > I haven't tried the mh parms you mentioned yet. I'll try that today, but I'm > not gonna run a separate instance of MH. Timing and/or some other environment aspects seem reasonable as I have never been able to reproduce the problems that you or others have cited. My suspicion is that someone capable of tracking down the problem will have to incur the problem to begin with in order to help. As an aside, there have been problems in the past regarding both the http_server and generic socket handling wrt system interrupts. My casual perusal of the Serial_Device.pm lib suggests that it doesn't much differentiate between absence of data and system interrupts (e.g., EAGAIN). Similar aliasing occurring in the original mh libs caused considerable reliability problems for certain users under transient conditions (again, it never happened to me; but, others--who also happen to be experiencing these same serial issues--did encounter them). I'm not suggesting that is definitely the issue/problem; but it would be the area that I would investigate if I could reproduce the problem. Another, possible issue is that the "reset_error" method does nothing despite a possible expectation otherwise in the main mh program's check_for_generic_serial_data. One thing that seems interesting is that the problems cited above had *always* existed in mh until corrected in the past 6 months or so and only began to materialize recently for certain users. Possibly, it is due to increased load, kernel differences, physical equipment combinations, etc. Gregg Gregg |