Using a callback script with OpenComPort

[sdanks]

I'm confused. If I understand it correctly, I should specify the callback script in the OpenComPort call and Homeseer will call the callback script when data comes in. So,

e=OpenComPort("1","9600,N,8,1",1,callback.txt,"")
then I create a script called callback.txt, and replace the

sub main()
end sub

with

sub callback(data)
hs.msgbox data
end sub

and when data arrives on the com port with a crlf, it should display what arrived in a msgbox? or am I misunderstanding the way the callback subroutine works? Should I not change from sub main() to sub callback(data)? the manual is not clear on this.

[jhisr]

Hi sdanks,

If you use:
e=OpenComPort("1","9600,N,8,1",1,callback.txt,"")

then you need this format:

sub main(data)
end sub


If you use:
e=OpenComPort("1","9600,N,8,1",1,callback.txt,"mycallback")

then you need this format:
sub mycallback(data)
end sub

The last paramter is the name of the sub you want to have called. If it's left as empty quotes as the first example then sub main will be called.

In either case you must have a paramter in your sub so that the data can be passed to your script. In these examples "data" is used but any variable name will do.

Hope this clears it up some.

Cheers,

[sdanks]

Thanks, I see my problem. I will go try it. I thought you had to rename to sub callback to make it work. This makes sense now. I guess you can have a script callback.txt and have

sub mycall(data)
end sub
sub mycallback(data)
end sub

and put them back to back in the same script. Thanks for the info, I'm not sure I would have figured it out for a while.

[jhisr]

You're welcome. If you have any other questions just let us know.

[jlikonen]

Hi,
I wonder whether anyone has investigated which mode is faster. In raw mode each character that is received on the com port causes the specified script and specified function to be called. In strings mode characters are buffered up until a CFLF pair is received. I am just curious which mode is faster.

Jari

[sdanks]

Smee helped me out to let me know that you can use OpenComPortEx to look for any terminating character. I went home and reduced my script significantly by using this method. Now the script only gets called when I receive a whole string of data. It's very fast. The Weeder board only sends a CR when it's done (No LF). So I used this function: opencomportex(1,"9600,n,8,1",1,"weedercb.txt","",chr(13)). It then calls the weedercb.txt main() function and processes the return with a Select Case statement. Works pretty good. Now I need to hookup the wires I have to the things I want to monitor.

[jlikonen]

sdanks,

I wonder whether you could post your script. It would help a lot. Thanks.

Basically you need 2 scripts but I have been wondering how you could combine them. I looked at posts related serial ports and somebody suggested to put the hs.opencomport into the startup.txt srcipt. I can't do this because basically I have several RS-485 devices connected to a single com port. So, I need to open/close the comm port each time when I want to read data from the devices. I know how to use hs.getcommport, but this needs a loop to retrieve all the characters. I think this is slower than using the 2 script technique.

So, I am wondering how to use only one script which opens the comm port, sends data to it, reads the characters (without hs.getcommport) and finally closes the serial port.

Jari

[sdanks]

Sure, I'm happy to. I'm just setting it up right now. The weeder board I have is going to be setup for the first 7 inputs to be "switch" inputs. So, I send "ASA", "ASB", ..., "ASG" etc to setup the ports A-G. This makes the board report when it goes high or low, and this mode has a debounce built in. So then when my script weedcb.txt is called it looks for the right response and updates the device q1 with the text. This is displayed on the devices page and I can see if the devices are open, closed, shut, armed etc. I dont have anything hooked up the board yet, but I ran a wire from ground to the input to simulate the door open/closed etc. Look at setting up a virtual device to see how to do this part. Here are the simple scripts:

[sdanks]

I guess you can only attach one file per post. Here is the setup file that has to run once.

[Rick Tinker]

The two choices are not really for speed purposes. It depends on what you are interfacing with. If the device you are interfacing with OpenCOMPort does end its transmission with CRLF or something like that, then there is less overhead simply because you are getting the complete strings each time the handling script is run. If you use it in RAW mode and let's say the termination is CHR(2) or something strange like that, then you will be running the script very often, and most of the time it will be appending characters to some sort of system variable or device until it finally gets a CHR(2) so it can process it. In fact, it is possible to get a CHR(2) in the middle of a string of characters such that you have to go and process that first string and then start building another string. It is just more complex and causes the handling script to run much more frequently.

If speed was desired, then you would not be interfacing with something that spoke ASCII in the first place - it would be binary characters like OP codes that you find in machine language to keep it short. Even at relatively slow speeds like 1200bps, the difference between 10 characters and 100 characters is not that much.

[jlikonen]

Rick,

Many thanks for your reply. I have been wondering which way is fastest. I have e.g. three four channel thermostats and I have found it much more convenient to use raw mode with getcomportdata. If I used string mode I would need quite many scripts for reading temperatures and set points. Now when I use raw mode I have to use a loop with getcomportdata in order to build the string. So, I would like to have a command which reads all the characters with a certain termination without the need to have 2 scripts or loops.
Jari