Announcement

Collapse
No announcement yet.

Is it possible that HS is truncating data rcvd from serial port

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bsobel
    Guest replied
    WBMurray, did you ever complete this script to allow full control? If so, can you post an updated version. I'm the author of the original MisterHouse script you referenced, I'm considering converting over to HS and was looking for scripts for my various devices.

    Thanks
    Bill

    Leave a comment:


  • sdanks
    replied
    I know this is an old post, but I think it will help me. However, I thought the data was passed to the subroutine by the callback. You seem to be getting it with getcomportdata. Or does it stay there for you to get even thought it is being passed to the routine, so you can get again with the getcomportdata?

    Leave a comment:


  • wbmurray
    Guest replied
    It worked!

    Now I'm able to consistently build packets that have all the data I need. This is awesome!

    I hope to be able to offer you help sometime!

    Leave a comment:


  • wbmurray
    Guest replied
    David - Thank you for the code stubs to help me get started! Much appreciated!

    Rick - Thanks for the explanation. The compool receive procedure does a rcvd=hs.getcomportdata(2)and then processes that. I "get" your idea and with David's code above will work on this tonight!

    [This message was edited by WBMurray on Mon, 28 April 2003 at 03:01 PM.]

    Leave a comment:


  • dkindred
    replied
    WBMurray,

    Maybe these bits of code will help you. Here's part of the port initialization routine. You'll note that an HS variable is created to hold the incoming data:

    hs.OpenComPort CPort,"4800,N,8,1",0,"test.vbs","GotData"
    x = hs.CreateVar("IncomingData")
    x = hs.SaveVar("IncomingData", "")

    Now, here's part of the routine that handles the incoming data. Note the IF statement is checking to see that there is both a command prefix and suffix before it tries to process it. If both are not present, then what is available is accumulated in a system variable to be processed when the next few bytes of data are available.

    sCID = hs.GetComPortData(CPort)
    sFullCID = hs.GetVar("IncomingData") & sCID

    if (instr(sFullCID,"###") = 0 or instr(sFullCID,"+++") = 0) then
    ' Save available data in system variable.
    x = hs.SaveVar("IncomingData", sFullCID)
    exit sub
    else
    ' Process the data

    ' Clear out the variable after it's been processed
    x = hs.SaveVar("IncomingData", "")
    end if

    --David (Who cannot stand Coca Cola, contrary to what his buddy Tink has placed under his avatar.)

    Leave a comment:


  • Rick Tinker
    replied
    WBMurray,

    I do not see the CompoolReceive procedure in your script which is the one set up to be run when there is data in the COM port, but I may still know what is happening.

    When data comes in the COM port, HomeSeer runs the script and procedure indicated in the OpenComPort command. Now, it varies from system to system on how fast the script is run, but that script is often run while the Compool device is still sending data. What is probably happening is that your script to handle the data is assuming that it has all of the data when in fact it was run when only part of it was available.

    What you need to do in your procedure that receives data from the COM port is to get the data, look and see if the END OF DATA character is there, and if not, then save the information somewhere (perhaps a system variable) and then exit. If the END OF DATA character is present, then take whatever data is in your system variable, append the new data to it, and you should then have a complete packet that you can process and you can then wipe out the system variable and get ready to do it all over again.

    When OpenComPort is used in mode 0 as your script uses it, no characters are stripped off of the data but as I wrote above, it might just be that your script is processing it while it is still coming in from the Compool device. When OpenComPort is used in mode 1, then CR-LF are the characters that dictate END-OF-DATA and so you don't have to store data until you get a CR-LF - HomeSeer does that for you.

    If the Compool interface does end its transmission with CR-LF, then you will find it and easy fix to change your OpenComPort command to use Mode 1 instead of Mode 0. If it does not, then with mode 0 you will find it necessary to implement a buffering routine like I described above.


    Regards,

    Rick Tinker
    HomeSeer Technologies

    Leave a comment:


  • wbmurray
    Guest replied
    Thanks Rupp. Here is where I open the com port. I tried "mode 1" but the packet sent has no CRLF.

    sub Main()
    compoolreset
    portnumber = 2
    hs.createvar("CompoolPort")
    hs.createvar("CompoolHC")
    hs.SaveVar "CompoolPort", portnumber
    hs.savevar "CompoolHC","W"

    st=hs.OpenComPort(hs.getvar("CompoolPort"), "9600,N,8,1",0, "ccs.txt", "CompoolReceive")
    hs.SetComPortRTSDTR hs.getvar("CompoolPort"),0,1
    if st<>"" then
    hs.writelog "Compool","Error Opening Comm Port: "+cstr(hs.getvar("CompoolPort"))
    close
    else
    hs.writelog "Compool", "Comm Port: "+cstr(hs.getvar("CompoolPort"))+" Opened"
    f=hs.SetDeviceString(hs.getvar("CompoolHC")+"40","<MARQUE E>Running</MARQUEE>")
    hs.SetDeviceLastChange hs.getvar("CompoolHC")+"40",now
    ' hs.writelog "test receive","Test Data="+cstr(st)
    end if
    end sub

    Leave a comment:


  • Rupp
    replied
    Post your open com port code. This is most likely where the problem is occurring.

    -Rupp

    Leave a comment:


  • wbmurray
    Guest started a topic Is it possible that HS is truncating data rcvd from serial port

    Is it possible that HS is truncating data rcvd from serial port

    I recently posted a script I'm working on that receives a packet from a swimming pool controller every 2.5 seconds (sort of a heartbeat packet). Problem is HS isn't reliably receiving the whole packet (5A thru DA). I know the data is coming in the serial port because I ran a serial port monitor program and got the full packets (see below)

    5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B
    02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA 5A FF AA 0F 1B 02 10 13 14 00 20 70 45 1B 00 00 72 A1 00 00 00 70 40 04 BF 5A DA

    But the data HS received is inconsistent. The fist 2 packets are "short" but the last packet is complete (see below):
    4/25/2003 8:41:46 PM~!~dec2hex~!~5AFFAA0F1B02102B14002070441A000072A1000000704 004
    4/25/2003 8:41:49 PM~!~dec2hex~!~5AFFAA0F1B02102B14002070441A000072A1000000704 004
    4/25/2003 8:41:51 PM~!~dec2hex~!~5AFFAA0F1B02102B14002070441A000072A1000000704 004D55ADA

    I'm using "rcvd=hs.getcomportdata(2)" to receive the data.

    Is it possible that HS is truncating the com2 data or am I doing something wrong?

    [This message was edited by WBMurray on Sat, 26 April 2003 at 10:51 AM.]
Working...
X