From: Troy C. <tr...@ca...> - 2008-02-15 16:49:11
|
Getting my DSC5401 to work is like pulling teeth. It's a good thing Linux is rock sold so that restarts are limited because once it works, I can leave it alone. My longest stretch has been 1.5 years of uptime with DSC5401 working fine. Unfortunately, as documented in past emails, I had to switch the email/spam/groupware solution I was running on the server (MH is running on the same server). I took the opportunity to upgrade everything...new motherboard/memory/etc, new OS (FC4 x86 -> Ubuntu Gutsy 64bit) along with the new email solution. Getting the DSC5401 to work again has been the bane of my existence. I have got to think it is not a PC hardware issue. The exact problem was happening on the old PC and now I have a new Mobo and new OS. The problems follow the 5401 to whichever serial port I put it on. I have even used a usb->serial adapter and had the same problems. Given that others seem to have their 5401s working, I have to lean towards a 5401 hardware problem. IF I can get it to work, it seems to work solid until the PC is restarted. For the most part, even restarting MH in that state does not seem to affect it. However, when it doesn't want to work, starting MH yields the following errors: 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=501 96 02/15/08 11:30:37 AM Command Error : Unknown 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=500 001 26 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=502 001 28 02/15/08 11:30:37 AM System Error : RS-232 Receive Buffer Overrun I may get an initial zone report from the system right after that (which may be complete or is sometimes truncated), but it will be the last thing that comes from the 5401. I have found that if I play around with the delay times in the DSC5401 library, I get different results. Too much time and the library doesn't seem to be able to decode any messages from the panel, and too little time causes it to clam up. One thing is sure, whenever I start MH, it seems to jolt the unit for a bit because it always talks right at MH startup. I have tried commenting all the startup code that configures the unit, and it may work for one command after that (I usually try the set-time command), but that will be it. I have also seen times where it appears it works (sends the zone report and the partition status, may even report a few real-time zone changes, but then stops communicating. The documentation doesn't show any reset type command for the unit, and I tried many power cycles on the alarm system last night to see if that would get the 5401 in a good state. No joy. I am about ready to take a sledge hammer to this little puppy and get another one to see if the problems persist. But, before I do that, does anyone know of an extrenal program that will just interact with the board? It can be Windows or Linux, I don't care. I want to see if I can get another PC and software solution to communicate reliably with the unit. It would essentially do what MH does...send configuration commands and print the status reports sent by the unit. Thanks for reading this far, Troy |
From: Pete F. <pj...@ca...> - 2008-02-15 21:15:51
|
Just a quick thought. I had simailar issuse a while back, and I traced it to flakey timing on th e built in RS232 port ... added a usb serial dongle and all got much better ... just my $0.02 -Pete Flaherty http://www.mraudrey.net http://www.hauntedacrewoods.com On Fri, February 15, 2008 11:47 am, Troy Carpenter wrote: > Getting my DSC5401 to work is like pulling teeth. It's a good thing Linux > is > rock sold so that restarts are limited because once it works, I can leave > it > alone. My longest stretch has been 1.5 years of uptime with DSC5401 > working > fine. > > Unfortunately, as documented in past emails, I had to switch the > email/spam/groupware solution I was running on the server (MH is running > on > the same server). I took the opportunity to upgrade everything...new > motherboard/memory/etc, new OS (FC4 x86 -> Ubuntu Gutsy 64bit) along with > the > new email solution. Getting the DSC5401 to work again has been the bane > of > my existence. > > I have got to think it is not a PC hardware issue. The exact problem was > happening on the old PC and now I have a new Mobo and new OS. The > problems > follow the 5401 to whichever serial port I put it on. I have even used a > usb->serial adapter and had the same problems. Given that others seem to > have their 5401s working, I have to lean towards a 5401 hardware problem. > > IF I can get it to work, it seems to work solid until the PC is restarted. > For the most part, even restarting MH in that state does not seem to > affect > it. > > However, when it doesn't want to work, starting MH yields the following > errors: > 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=501 96 > 02/15/08 11:30:37 AM Command Error : Unknown > 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=500 001 26 > 02/15/08 11:30:37 AM DSC5401:check_for_data DscString=502 001 28 > 02/15/08 11:30:37 AM System Error : RS-232 Receive Buffer Overrun > > I may get an initial zone report from the system right after that (which > may > be complete or is sometimes truncated), but it will be the last thing that > comes from the 5401. > > I have found that if I play around with the delay times in the DSC5401 > library, I get different results. Too much time and the library doesn't > seem > to be able to decode any messages from the panel, and too little time > causes > it to clam up. > > One thing is sure, whenever I start MH, it seems to jolt the unit for a > bit > because it always talks right at MH startup. I have tried commenting all > the > startup code that configures the unit, and it may work for one command > after > that (I usually try the set-time command), but that will be it. > > I have also seen times where it appears it works (sends the zone report > and > the partition status, may even report a few real-time zone changes, but > then > stops communicating. The documentation doesn't show any reset type > command > for the unit, and I tried many power cycles on the alarm system last night > to > see if that would get the 5401 in a good state. No joy. > > I am about ready to take a sledge hammer to this little puppy and get > another > one to see if the problems persist. But, before I do that, does anyone > know > of an extrenal program that will just interact with the board? It can be > Windows or Linux, I don't care. I want to see if I can get another PC and > software solution to communicate reliably with the unit. It would > essentially do what MH does...send configuration commands and print the > status reports sent by the unit. > > Thanks for reading this far, > Troy > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Troy C. <tr...@ca...> - 2008-02-16 03:48:38
|
On Friday 15 February 2008 04:05:47 pm Pete Flaherty wrote: > Just a quick thought. I had simailar issuse a while back, and I traced it > to flakey timing on th e built in RS232 port ... added a usb serial dongle > and all got much better ... Thanks Pete for pulling me out of my dispair because in retesting your suggestion, I had a thought of a troubleshooting method (more on that starting in the next paragraph). I have tried the USB dongle thing and got the same results...even now I just tried it and got the same results. However, I do actually now think this is a problem with MH somehow, either in my personal code or the library itself. Let me explain what I have done. While still having the 5401 connected to the USB dongle, which is device /dev/ttyUSB0, I ran the "ser2net" program That basically connects the serial port to a TCP port on the PC, in this case 52000. So, from another machine I telnet to port 52000 on the MH server. I get left over buffered output, but then it stops. When I try to type ASCII characters, like MH would send, I get error code responses (which is what I would expect since I don't know the command sequences off the top of my head). But, as I trip zones and watch the screen, I see all the correct encoded output from the 5401, even the time broadcast every 4 minutes. Arming and disarming via a panel generates the correct codes. For instance, arm the system in away mode from the panel. First I see: 6561D2 System is in exit delay 7011C9 1 minute later, special arming action 65211FF This says the system is now armed in away mode. 550224002150892 Standard time/date broadcast (very recent, too). So, if my serial terminal sees this stuff, why doesn't MH? It's almost as if, once the 5401 reports the buffer overflow, MH stops listening. The USB dongle has a light that blinks when there is activity, and when MH is not listening, it is constantly blinking. Now, I will need to do some research and figure out what the command sequences are that I need to send to see something happen. Then I guess I will pull out my debugging hat and figure out exactly what is going on with MH. It could be anywhere from the 5401 library to the serial port driver code. Too bad I can't make the 5401 library code telnet to this port instead of use it directly. Imagine if that ability was added to MH for any serial device, they could sit anywhere in the world where there is a PC running software like ser2net. Troy |
From: Neil C. <nc...@li...> - 2008-02-16 04:23:29
|
Troy Carpenter wrote: > On Friday 15 February 2008 04:05:47 pm Pete Flaherty wrote: >> Just a quick thought. I had simailar issuse a while back, and I traced it >> to flakey timing on th e built in RS232 port ... added a usb serial dongle >> and all got much better ... > > Thanks Pete for pulling me out of my dispair because in retesting your > suggestion, I had a thought of a troubleshooting method (more on that > starting in the next paragraph). I have tried the USB dongle thing and got > the same results...even now I just tried it and got the same results. > > However, I do actually now think this is a problem with MH somehow, either in > my personal code or the library itself. Let me explain what I have done. > > While still having the 5401 connected to the USB dongle, which is > device /dev/ttyUSB0, I ran the "ser2net" program That basically connects the > serial port to a TCP port on the PC, in this case 52000. So, from another > machine I telnet to port 52000 on the MH server. I get left over buffered > output, but then it stops. When I try to type ASCII characters, like MH > would send, I get error code responses (which is what I would expect since I > don't know the command sequences off the top of my head). But, as I trip > zones and watch the screen, I see all the correct encoded output from the > 5401, even the time broadcast every 4 minutes. Arming and disarming via a > panel generates the correct codes. > > For instance, arm the system in away mode from the panel. First I see: > 6561D2 System is in exit delay > 7011C9 1 minute later, special arming action > 65211FF This says the system is now armed in away mode. > 550224002150892 Standard time/date broadcast (very recent, too). > > So, if my serial terminal sees this stuff, why doesn't MH? It's almost as if, > once the 5401 reports the buffer overflow, MH stops listening. The USB > dongle has a light that blinks when there is activity, and when MH is not > listening, it is constantly blinking. > > Now, I will need to do some research and figure out what the command sequences > are that I need to send to see something happen. Then I guess I will pull > out my debugging hat and figure out exactly what is going on with MH. It > could be anywhere from the 5401 library to the serial port driver code. > > Too bad I can't make the 5401 library code telnet to this port instead of use > it directly. Imagine if that ability was added to MH for any serial device, > they could sit anywhere in the world where there is a PC running software > like ser2net. Is the serial port mode raw? Take a look at you ini file for your DCS settings. This is just a guess but I think I've seen something odd like that previously. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Troy C. <tr...@ca...> - 2008-02-16 04:41:06
|
On Friday 15 February 2008 11:23:13 pm Neil Cherry wrote: > > Is the serial port mode raw? Take a look at you ini file for your > DCS settings. This is just a guess but I think I've seen something > odd like that previously. These are the only INI variable related to DSC serial ports. DSC_5401_serial_port=/dev/ttyS2 DSC_5401_baudrate=9600 DSC_5401_module=DSC5401 In the DSC library, there is this code to init the port: if ( &main::serial_port_create( 'DSC5401', $port, $BaudRate, 'none', 'raw' ) ) { init( $::Serial_Ports{DSC5401}{object}, $port ); I have used the setserial command to show me that port. I don't know if raw mode can be set via setserial. I don't know much about serial ports, other than they drive me crazy. Troy |
From: Neil C. <nc...@li...> - 2008-02-16 04:55:16
|
Troy Carpenter wrote: > On Friday 15 February 2008 11:23:13 pm Neil Cherry wrote: >> Is the serial port mode raw? Take a look at you ini file for your >> DCS settings. This is just a guess but I think I've seen something >> odd like that previously. > > These are the only INI variable related to DSC serial ports. > DSC_5401_serial_port=/dev/ttyS2 > DSC_5401_baudrate=9600 > DSC_5401_module=DSC5401 > > In the DSC library, there is this code to init the port: > if ( &main::serial_port_create( 'DSC5401', $port, > $BaudRate, 'none', 'raw' ) ) { > init( $::Serial_Ports{DSC5401}{object}, $port ); You may want to get rid of the raw but since I don't know how the code is written that may not be a good idea. Raw is used when there is no line ending (a CR and/or LF). -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Pete F. <pj...@ca...> - 2008-02-16 04:34:10
|
Troy, enable serial debugging ( I think there is debug code in the lib) If not sprinkle a couple print statements in the lib/code so you can watch the data/processing. Then you may get a better handle on what is messing up. Seems I had a similar issue on one of my serial enabled code files, and needed to force a buffer flush at init, so there was nothing in the buffer to start with. as I recall it was just a matter of reading the buffer once on startup and then emptying the read data ... more change $0.02 -Pete Flaherty http://www.mraudrey.net http://www.hauntedacrewoods.com On Fri, February 15, 2008 10:48 pm, Troy Carpenter wrote: > On Friday 15 February 2008 04:05:47 pm Pete Flaherty wrote: >> Just a quick thought. I had simailar issuse a while back, and I traced >> it >> to flakey timing on th e built in RS232 port ... added a usb serial >> dongle >> and all got much better ... > > Thanks Pete for pulling me out of my dispair because in retesting your > suggestion, I had a thought of a troubleshooting method (more on that > starting in the next paragraph). I have tried the USB dongle thing and > got > the same results...even now I just tried it and got the same results. > > However, I do actually now think this is a problem with MH somehow, either > in > my personal code or the library itself. Let me explain what I have done. > > While still having the 5401 connected to the USB dongle, which is > device /dev/ttyUSB0, I ran the "ser2net" program That basically connects > the > serial port to a TCP port on the PC, in this case 52000. So, from another > machine I telnet to port 52000 on the MH server. I get left over buffered > output, but then it stops. When I try to type ASCII characters, like MH > would send, I get error code responses (which is what I would expect since > I > don't know the command sequences off the top of my head). But, as I trip > zones and watch the screen, I see all the correct encoded output from the > 5401, even the time broadcast every 4 minutes. Arming and disarming via a > panel generates the correct codes. > > For instance, arm the system in away mode from the panel. First I see: > 6561D2 System is in exit delay > 7011C9 1 minute later, special arming action > 65211FF This says the system is now armed in away mode. > 550224002150892 Standard time/date broadcast (very recent, too). > > So, if my serial terminal sees this stuff, why doesn't MH? It's almost as > if, > once the 5401 reports the buffer overflow, MH stops listening. The USB > dongle has a light that blinks when there is activity, and when MH is not > listening, it is constantly blinking. > > Now, I will need to do some research and figure out what the command > sequences > are that I need to send to see something happen. Then I guess I will pull > out my debugging hat and figure out exactly what is going on with MH. It > could be anywhere from the 5401 library to the serial port driver code. > > Too bad I can't make the 5401 library code telnet to this port instead of > use > it directly. Imagine if that ability was added to MH for any serial > device, > they could sit anywhere in the world where there is a PC running software > like ser2net. > > Troy > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Troy C. <tr...@ca...> - 2008-02-16 04:49:52
|
On Friday 15 February 2008 11:24:03 pm Pete Flaherty wrote: > Troy, > > enable serial debugging ( I think there is debug code in the lib) > If not sprinkle a couple print statements in the lib/code so you can > watch the data/processing. > > Then you may get a better handle on what is messing up. > Seems I had a similar issue on one of my serial enabled code files, and > needed to force a buffer flush at init, so there was nothing in the buffer > to start with. > > as I recall it was just a matter of reading the buffer once on startup and > then emptying the read data ... I will definitely look for that...I am thinking along the same lines. I'm finding that the 5401 is always parsing the input, and will send a response as soon as it recognizes something. There doesn't seem to be any "start of command" sequence, unless you count <CR><LF> from the previous command and don't send anything to the serial port in between. That's why the first command is often rejected when MH starts up. I would think the library code would sync up with the 5401 after that. Having said all that, though, I have yet to get the 5401 to accept any command I send to it using the ser2net program. Every command I try, even simple ones, generate buffer overflow error response (50202029) from the 5401. I have my telnet program set to send <CR><LF> when I hit enter, but it always seems like the 5401 is waiting for something else. I'm not getting any local echo, so I can't see if I enter something wrong. For instance, I type: 00191<enter> I get nothing...one more tap on <enter> and I get: 50202029 So obviously I don't understand something yet either about sending the 5401 data, or how telnet is supposed to be sending things. |
From: Troy C. <tr...@ca...> - 2008-02-16 04:57:56
|
On Friday 15 February 2008 11:49:46 pm Troy Carpenter wrote: > Having said all that, though, I have yet to get the 5401 to accept any > command I send to it using the ser2net program. Every command I try, even > simple ones, generate buffer overflow error response (50202029) from the > 5401. I have my telnet program set to send <CR><LF> when I hit enter, but > it always seems like the 5401 is waiting for something else. I'm not > getting any local echo, so I can't see if I enter something wrong. > > For instance, I type: > 00191<enter> I get nothing...one more tap on <enter> and I get: > 50202029 Quick correction, this error is API syntax error, not buffer overflow...I was reading it wrong. That would make more sense if I am typing commands in wrong. Troy |
From: Neil C. <nc...@li...> - 2008-02-16 05:09:22
|
Troy Carpenter wrote: > On Friday 15 February 2008 11:24:03 pm Pete Flaherty wrote: >> Troy, >> >> enable serial debugging ( I think there is debug code in the lib) >> If not sprinkle a couple print statements in the lib/code so you can >> watch the data/processing. >> >> Then you may get a better handle on what is messing up. >> Seems I had a similar issue on one of my serial enabled code files, and >> needed to force a buffer flush at init, so there was nothing in the buffer >> to start with. >> >> as I recall it was just a matter of reading the buffer once on startup and >> then emptying the read data ... > > I will definitely look for that...I am thinking along the same lines. I'm > finding that the 5401 is always parsing the input, and will send a response > as soon as it recognizes something. There doesn't seem to be any "start of > command" sequence, unless you count <CR><LF> from the previous command and > don't send anything to the serial port in between. That's why the first > command is often rejected when MH starts up. I would think the library code > would sync up with the 5401 after that. > > Having said all that, though, I have yet to get the 5401 to accept any command > I send to it using the ser2net program. Every command I try, even simple > ones, generate buffer overflow error response (50202029) from the 5401. I > have my telnet program set to send <CR><LF> when I hit enter, but it always > seems like the 5401 is waiting for something else. I'm not getting any local > echo, so I can't see if I enter something wrong. > > For instance, I type: > 00191<enter> I get nothing...one more tap on <enter> and I get: > 50202029 Line ending problems. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Troy C. <tr...@ca...> - 2008-02-16 05:36:32
|
Ok, connecting to the serial port first with ser2net seems to make some kind of difference. I started MH back with the 5401 on /dev/ttyUSB0 and it worked fine (well, not really just fine, it doesn't get all of the status report at startup and I have to do a subsequent status request in my user code). Then I put the 5401 back on /dev/ttyS2, change config file and restarted MH...back to the same problems as before. Configured ser2net to use /dev/ttyS2, connected to the port via telnet and hit return a few times to see the API error message come from 5401. I then quit ser2net (to free the port, of course), then restarted MH. This time it worked like a charm. So, it would seem to me that there is something missing in the serial port initialization for the 5401 in MH (which the ser2net does correctly). Right now my copy of the 5401 library module is unmodifed. I'll see what I dig up along those lines. |
From: Troy C. <tr...@ca...> - 2008-02-16 06:16:23
|
On Saturday 16 February 2008 12:36:22 am Troy Carpenter wrote: > Ok, connecting to the serial port first with ser2net seems to make some > kind of difference. > > I started MH back with the 5401 on /dev/ttyUSB0 and it worked fine (well, > not really just fine, it doesn't get all of the status report at startup > and I have to do a subsequent status request in my user code). > > Then I put the 5401 back on /dev/ttyS2, change config file and restarted > MH...back to the same problems as before. Configured ser2net to > use /dev/ttyS2, connected to the port via telnet and hit return a few times > to see the API error message come from 5401. I then quit ser2net (to free > the port, of course), then restarted MH. This time it worked like a charm. > > So, it would seem to me that there is something missing in the serial port > initialization for the 5401 in MH (which the ser2net does correctly). > Right now my copy of the 5401 library module is unmodifed. I'll see what I > dig up along those lines. Ok, it's not ser2net itself, but the act of connecting to the port and letting the receive buffer clear out. I just did a total powerdown on the MH server. When it came back up the 5401 did the same ole stuff that started this rant. I tried setting more of the serial port parameters in the 5401 library code to no avial. I then quit MH, ran ser2net, but didn't telnet to the port. Quit ser2net, restart MH, same result. Quit MH, restart ser2net and this time connect to the port. Lots of buffered output from the 5401 scroll by. Disconnect, quit ser2net, restart MH, and now the 5401 works fine. So, how do I get MH to flush the buffer when connecting to the port? Once I get that, I will do the power down test again. My goal is to have MH & the 5401 work without intervention from a power-up. |
From: Steve G. <st...@fa...> - 2008-02-16 23:05:22
|
Troy Carpenter wrote: > > So, how do I get MH to flush the buffer when connecting to the port? Once I > get that, I will do the power down test again. My goal is to have MH & the > 5401 work without intervention from a power-up. Looks like you could add this code from check_for_data in the DSC5401 library code &main::check_for_generic_serial_data('DSC5401'); my $NewCmd = $main::Serial_Ports{'DSC5401'}{data}; $main::Serial_Ports{'DSC5401'}{data} = ''; right after this select code in the init sub for the DSC5401 select( undef, undef, undef, .100 ); # Sleep a bit and whatever happens to be in the buffer at init time after that iniial sleep will be flushed. -- Steve |
From: Troy C. <tr...@ca...> - 2008-02-17 04:17:46
|
On Saturday 16 February 2008 06:03:37 pm Steve Goldman wrote: > Troy Carpenter wrote: > > So, how do I get MH to flush the buffer when connecting to the port? > > Once I get that, I will do the power down test again. My goal is to have > > MH & the 5401 work without intervention from a power-up. > > Looks like you could add this code from check_for_data in the DSC5401 > library code > > &main::check_for_generic_serial_data('DSC5401'); > my $NewCmd = $main::Serial_Ports{'DSC5401'}{data}; > $main::Serial_Ports{'DSC5401'}{data} = ''; > > right after this select code in the init sub for the DSC5401 > > select( undef, undef, undef, .100 ); # Sleep a bit > > and whatever happens to be in the buffer at init time after that > iniial sleep will be flushed. I tried this code, and it didn't fix the problem. I am now going to write a kludge expect script so I can at least be sure the port is set up correctly before starting MH. Troy |
From: Troy C. <tr...@ca...> - 2008-02-17 05:34:46
|
On Saturday 16 February 2008 11:17:42 pm Troy Carpenter wrote: > I am now going to write > a kludge expect script so I can at least be sure the port is set up > correctly before starting MH. > > Troy A fairly complex workaround, but with easy execution and predictable results. As stated earlier in this email thread, I installed the program "ser2net" which exposes serial ports to the network as TCP ports on your machine. Here's the ser2net config I used: BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n 52001:telnet:600:/dev/ttyS2:9600 8DATABITS NONE 1STOPBIT banner This exposes /dev/ttyS2 as port 52001 on the MH machine. I then wrote an expect script. Here's the script: --fixdsc.exp--- #!/usr/bin/expect system "/etc/init.d/ser2net stop" sleep 1 system "/etc/init.d/ser2net start" sleep 1 set timeout 1 spawn telnet localhost 52001 send "\n" expect { timeout { send "\n"; exp_continue } "50202029" } send "\035" expect "telnet" send "quit\n" system "/etc/init.d/ser2net stop" ------ This starts the ser2net service (stops it first just in case), telnet to port 52001, simulate hitting "enter" until the DSC spits out "50202029" then quits the telnet session and stops ser2net. After that I start misterhouse and everything works great...almost. See my next email for that story. I put both the expect script and MH startup in rc.local, which processes last in the boot sequence. I'm sure there's a way to do this in Misterhouse, but I'm not ready to figure that out. Now, on to my next problem! Troy |
From: Steve G. <st...@fa...> - 2008-02-17 18:03:27
|
Troy Carpenter wrote: > > This starts the ser2net service (stops it first just in case), telnet to port > 52001, simulate hitting "enter" until the DSC spits out "50202029" then quits > the telnet session and stops ser2net. After that I start misterhouse and > everything works great...almost. See my next email for that story. > Ahh so the problem wasn't really left over junk in the buffer confusing mh. This looks for all the world like the DSC5401 is doing an autobaud search and until it sees enough <cr>'s it doesn't get the framing correct. Seems like on your shutdown it switches to some unexpected baud rate because of junk it sees on the rs232 port and until you run this sequence of <cr>'s to it later it doesn't get back to the expected baud rate. It does sound like as Noah suggested that a jumper config on the board is not quite matched up and it is using autobaud and not a fixed baud rate. -- Steve |
From: Richard K. <n1...@ho...> - 2008-02-17 18:53:58
|
Hello list, I trying to setup some code to send out an xPL message to a remote computer. I notice, using tcpdump, that the message is getting sent on eth1. I'd like it to be sent on eth0. Is there a parameter to do this? I tried playing with xpl_address but it had no effect. The code I'm using is as follows: $xpl_monitor1 = new xPL_Item; $xpl_monitor1 -> tie_event('print_log "xpl data: $state"'); $pcroom_light_xpl = new xPL_Item('TEST-LAMP.pcroom', 'lamp.basic' => {action => '$state'}); $pcroom_light_xpl -> tie_event('print_log "xpl says TEST-LAMP.pcroom light was set to $state"'); $xpl_test = new Voice_Cmd 'Test xpl send [0,1,2]'; if (defined ($state = said $xpl_test)) { print_log "Running xpl send tset $state"; &xAP::send_xpl_heartbeat() if $state == 0; set $pcroom_light_xpl TOGGLE if $state == 1; &xAP::send('xPL', 'TEST-LAMP.pcroom', 'lamp.basic' => {action => 'on'}) if $state == 2; } |
From: Gregg L. <gr...@li...> - 2008-02-17 20:38:46
|
Richard Koch wrote: > Is there a parameter to do this? I tried playing with xpl_address but it had no > effect. use ipaddress_xpl_broadcast to control binding to a specific interface and ipaddress_xpl (xpl_address is deprecated but still works) to control binging the receive socket and proper init of the heartbeat param. e.g., ipaddress_xpl = 10.20.1.5 ipaddress_xpl_broadcast = 10.20.1.255 |
From: Richard K. <n1...@ho...> - 2008-02-17 20:57:57
|
Thanks Gregg, thats exactly what I needed to know, it's working now... -Rick ---------------------------------------- > Date: Sun, 17 Feb 2008 15:38:36 -0500 > From: gr...@li... > To: mis...@li... > Subject: Re: [mh] xPL problem sending on wrong interface > > Richard Koch wrote: > >> Is there a parameter to do this? I tried playing with xpl_address but it had no >> effect. > > use ipaddress_xpl_broadcast to control binding to a specific interface > and ipaddress_xpl (xpl_address is deprecated but still works) to control > binging the receive socket and proper init of the heartbeat param. > > e.g., > > ipaddress_xpl = 10.20.1.5 > ipaddress_xpl_broadcast = 10.20.1.255 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Gregg L. <gr...@li...> - 2008-02-17 21:12:23
|
Richard Koch wrote: > Thanks Gregg, thats exactly what I needed to know, it's working now... Great! BTW: I just noticed some of your actual code and was about to comment on why those practices were particularly bad when I realized that it was almost an exact copy and paste out of code/common/test_xap.pl. Actually, I had no idea that file even existed and worse: (1) it contains code that is filled with exceptionally bad examples and (2) in some cases will no longer work at all. Ordinarily, I've very hesitant to consider deleting existing code; but, this is only useful as examples and the examples if ever used are going to cause nothing but headaches, poor user experience and understanding of how to do things the wrong way. So, this email serves as notice that I'm intending to delete it unless anyone can offer a compelling reason to keep it. |
From: Richard K. <n1...@ho...> - 2008-02-17 22:12:54
|
Gregg, I haven't much experience with MH's xAP/xPL code and admittedly I was a bit disappointed with what was in the example code provided (at least for xPL). Please if you delete the current, replace with some contemporary code. -Rick ---------------------------------------- > Date: Sun, 17 Feb 2008 16:12:15 -0500 > From: gr...@li... > To: mis...@li... > Subject: Re: [mh] xPL problem sending on wrong interface > > Richard Koch wrote: >> Thanks Gregg, thats exactly what I needed to know, it's working now... > > Great! BTW: I just noticed some of your actual code and was about to > comment on why those practices were particularly bad when I realized > that it was almost an exact copy and paste out of > code/common/test_xap.pl. Actually, I had no idea that file even existed > and worse: (1) it contains code that is filled with exceptionally bad > examples and (2) in some cases will no longer work at all. Ordinarily, > I've very hesitant to consider deleting existing code; but, this is only > useful as examples and the examples if ever used are going to cause > nothing but headaches, poor user experience and understanding of how to > do things the wrong way. So, this email serves as notice that I'm > intending to delete it unless anyone can offer a compelling reason to > keep it. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Gregg L. <gr...@li...> - 2008-02-17 22:29:55
|
Hi Rick, Richard Koch wrote: > I haven't much experience with MH's xAP/xPL code and admittedly > I was a bit disappointed with what was in the example code provided > (at least for xPL). Yes--I was disappointed as well as it suggests that users should be encouraged to actually use the "low-level" xAP_Item or xPL_Item. This would be about as sensible as suggesting that users start by instantiating Generic_Item for everything in mh. In general, I've tried to be responsive to any requests for support of schemas for which built-in support does not already exist. The post 2.104 code (in svn) has a number of new xPL "items" that can be instantiated directly in *.mht using the target address and, optionally, device id (or equivalent). In other cases, support is somewhat "built-in". For example, any xPL or xAP "display device" (e.g., squeezebox) can be targeted using the same sort of logic that you use for targeting speech. Details are here: http://misterhouse.wikispaces.com/Using+xAP+and+xPL+Displays Definitely, I need to add lots of documentation of using xPL and xAP devices to the wiki. But, in the mean time, just speak up about use of a particular schema. And, if it doesn't exist, I'll add it as quickly as I can. Exceptions to "quick" would be more advanced schemas like security, lighting and media. > Please if you delete the current, replace with some contemporary code. It doesn't make sense to "replace" since instead you would just add new entries into *.mht and then work w/ them using "normal" mh methods (e.g., set, state_now, etc.). A better approach would be for me (or, now others that are successfully using them) to add examples to the wiki. Gregg |
From: Richard K. <n1...@ho...> - 2008-02-17 22:37:03
|
> It doesn't make sense to "replace" since instead you would just add new > entries into *.mht and then work w/ them using "normal" mh methods OK, that makes sense, that makes these devices work just like the others. This is my next step since I want to turn a particular light on/off and have it defined in my MH setup, i.e. items.mht. > (e.g., set, state_now, etc.). A better approach would be for me (or, > now others that are successfully using them) to add examples to the wiki. > That would be great. Thanks agn... |
From: Gregg L. <gr...@li...> - 2008-02-17 23:03:43
|
Richard Koch wrote: > >> It doesn't make sense to "replace" since instead you would just add new >> entries into *.mht and then work w/ them using "normal" mh methods > > OK, that makes sense, that makes these devices work just like the others. > This is my next step since I want to turn a particular light on/off and have it > defined in my MH setup, i.e. items.mht. So that I best understand... are you saying that you want to expose some light already controlled by mh (e.g., x10, insteon, etc.) to xPL so that it could be remotely managed using some schema like control.basic (or, optionally, the more advanced lighting schema)? Or, are you saying that you have some xPL-enabled light that you want to control via mh? I've not yet implemented any proper "facade" capability for the former (although should be easy to add); the latter should be quite straight-forward depending upon the schema. If you can define the specific scenario of what you want and schemas (if known), then I can better help you. Gregg |
From: Richard K. <n1...@ho...> - 2008-02-18 15:59:53
|
OK, well thanks to CompUSA going out of business I was able to pick up some z-wave devices. Unfortunately the controller, an HA-22, doesn't have a linux device driver (yet). So my intention is to install it on windows and use tools from http://www.xplmonkey.com (xPLZWave ) to control the devices from my MH linux box. I'm hoping to at least be able to turn the lights on/off, dimming would be great. I haven't got very far yet and I'm not that familiar with xPL and the various schemas. Would love to play with it some more today but gotta head in to work... -Rick > > So that I best understand... are you saying that you want to expose some > light already controlled by mh (e.g., x10, insteon, etc.) to xPL so that > it could be remotely managed using some schema like control.basic (or, > optionally, the more advanced lighting schema)? Or, are you saying that > you have some xPL-enabled light that you want to control via mh? I've > not yet implemented any proper "facade" capability for the former > (although should be easy to add); the latter should be quite > straight-forward depending upon the schema. If you can define the > specific scenario of what you want and schemas (if known), then I can > better help you. > > Gregg |