How do I constantly sample a serial port?

[dishman]

I can't see way to sample a serial port more often than once a minute.

I would like to sample constantly, as HS does with devices like the slinke and cm11a. I'm working on some serial interfaces. Any suggestions? Thanks... Mark

[MikeMatthews]

I'm not sure how you're attempting to do it now, but there are two methods: 1) using HS built in function, and 2) writing your own plugin.

It seems like you would be better off writing your own plugin. Then, you can have it respond to "mscommevent", which means that any data that shows up will be sent to the plugin. It's essentially using the fact that Windows already monitors the serial ports for you. I do this with my analog/digital input here.
This is the way both the CM11a and Slinke are interfaced (I think), so the programmer doesn't really have to constantly monitor the serial port, but knows instantly when data arrives.

[George]

A script will work just fine.

For us lowey script writers, the OpenComPort function has a cb_script parm (Call Back Script) that will call your script whenever any data (character or full lines) are received at the com port. That way you don't have to keep polling the port, HS will call you when it has data for you.

Look for OpenComPort in the HS help file.

George (not everything needs to be a plugin)

[MikeMatthews]

Fair enough. I didn't realize that was available in scripting. In any case, you NEVER are actually polling the port constantly. Both a VB plugin or a scripting solution will ultimately rely on mscommevent to tell the code when data is available. 6 of one half a dozen of the other.

For some hardware, it might appear that you are polling constantly because the hardware will be sending data constantly.

Still, there is a good reason to make a plugin (exe or ocx) instead of a script. For those data intesive devices, the plugin will run in it's own thread, as opposed to a script which will potentially delay other HS operations, especially in the case of nearly continuous data.

[dishman]

Thanks Mike and George - great info.

George - I had read about the call_back script in opencomport, but didn't really understand it. It makes sense now, thanks.

Mike - I'm a little confused in your last post when you talk about a script potentially delaying hs. If you use the cb_script parm function, do you still need a script? Doesn't hs just automatically respond to the event of data showing up on the port? Or does setting a response to the event tie up resources? I'm really just learning here.

btw - what technically is a plug in? I looked at your exe (very nice by the way). How exactly does it send info to hs? It would be very beneficial to see the code behind it. Also, in one of your other posts, I think you mentioned monitoring your vcr for on/off. What are you using to collect the data?

Thanks for the tip on the chip. It looks great.

[MikeMatthews]

The way I understand HS operation is that scripts run in the same thread as HS, and any other scripts that are running. So scripts must run serially, not in parallel, meaning they can potentially delay other scripts. This is why you need to call hs.waitevents within scripts to let other things run.

With an external exe (as my example above) or with a plugin (hmmm, not sure), they are run independent of HS, so they will not delay scripts that are running. The operating system will then take responsibility for giving resources to HS versus your app/plugin, and if it's winNT or W2k, it does a good job of that. The independent plugin/app can handle lots of data and lots of CPU cycles without affecting homeseer as much as it would by trying to do it in scripting. Obviously this depends on the application... serial port communication that occurs infrequently will not slow down HS.

Technically, a plugin is a small dll or ocx code that contains calls to and from homeseer. Homeseer loads these upon startup and treats them as it's own internal code (that's why I'm not sure they are really multi-threaded, but I'm sure my exe above is). It is a nice way to integrate directly with homeseer, and is necessary if you want to SEND data to your code from HS. If you only want to send from your code to HS, then things are much simpler. If you look in your interfaces section of HS (where the cm11a and slinke are), all those things are plugins.

Hope I got all that right. I'm sure someone will let me know if not.

[Barry Gordon]

An ocx plugin runs in Homeseer's thread. An exe plugin runs in its own thread. The plugin concept is really more for a tighter integration and less hassle for the user. If you write the plugin properly it executes various functions at different points in the Homeseer startup process. You can include the effect of a script in the plugin, to eliminate the script(s) and replace them all with the plugin.

Devices representing control points can be automatically built by the plugin. The user has an easier time, they select the plugin when homeseer starts up (one time) and from then on in they are done. Since the plugin is object as opposed to source then the developer has control over the product. I am not sure that the Homeseer community would think that to be an advantage.

I did a plugin to integrate the Jandy aqualink pool system with Homeseer. I did it first as an OCX then converted it to an EXE. It is working fine. I have full control and status notification of all changes including pool/spa/air temp. The values show up as strings on the devices representing the control points. The only negative is that you can not set the pool and spa temperature set points from the web interface only from the Homeseer GUI. That is an acknowledged limitation in the way Rich implemented plugins. No big deal.

If anyone wants the source code to learn from (no laughing allowed however) drop me an email. If you just want the compiled (VB 6) plugin let me know and I will ship you the exe one since that is the one I am using/supporting. All the dll's required should be registered on your system since Homeseer uses the same ones.

When I get time I will convert other systems I have that run as independent exe's to plug ins. One is a full UDP I/O package to allow CF01 touchscreens to communicate with Homeseer or for that matter any PC that has implemented UDP communications. I have CF01's mounted in the wall of the master bedroom and are getting ready to install in all rooms. They are a Better "Leopard" (full color, running win 95). they are all programmed in VB and all will run the same app. I also have a version for TCP.

Another subsystem deals with RCS LCD keypads, and another with the Marrick Lynxport I/O board (script).

So much to code, so little time

[Michael McSharry]

Barry, I'm interested in the project. Especially the serial interface. My email is in my profile.

I do not understand the comment about not being able to set IO from the Web Interface. The only plugin that I have done has all of its control via the web interface. What specific function cannot be done via the web?

[Barry Gordon]

In my application I field a button press on the controls that represent the temperature set points and bring up a dialog to allow the user to set the tmperature which I then send to the Aqualink system. This uses the button press call back in the plugin. All is well when working with the OSD GUI.

If you now go to the web page (the standard one) you can still do the button press, but the plugin does not know that it wasn't the device button but rather the Web page version of the button ergo it puts up the dialog to accept the temperature value on the OSD GUI not the web page. I solved the problem by timing the input dialog and after 15 seconds pulling it down. If you are running from the web page you just don't see it.

I will send you the source to the apps. The exe one is the good one as I stopped development of the ocx when I determined the exe would be better (seperate thread)

[Michael McSharry]

Thank you for the project code. I understand the limitation to be with how homeseer handles it standard buttons. If you do not use these standard buttons and make your own to perform the desired functions then the problem should no longer exist. Of course this would require you to develop a web page to support the functionality desired.