Serial communication?

[ronbo]

Michel,

 

Having read thru this thread, and other about supporting serial devices, it seams to me that a serialinc interface would be quite usefull. Unless I have read the documantations incorectly, it appears that the serialinc can be programmed or customized to generate insteon commands when it receives certain serial command, and to generate serail command when it receives insteon. I would think that this type of operation would allow for integration to Honeywell alarm systems, DSC alarm systems, and other devices that had an RS232 interface. While I agree that all of these cases could curently be implemented using the network module and an always on PC as a gateway, (such as the DSClink does) the serialinc would/could eliminate the need for the dedicated PC and the translation software.

 

Ron

[Michel Kohanim]

Hi Ron,

 

That's what we thought originally but SeriaLinc is quite limiting. I have yet to see a successful integration with SeriaLinc.

 

With kind regards,

Michel

[Zellarman]

I have 7 serial devices that I currently link to my ISY. I use serial-ethernet servers to do this. The 4-port Qualtech unit can be found used on eBay pretty cheap sometimes.

These devices range from simply turning a stereo on/off, to interfacing with a DSC alarm system or Honeywell thermostat using custom software on a Windows computer.

............................................

Right now I run 5 custom Windows applications to interface with serial devices. I've always been debating writing a single more generic serial link program instead (runs on Windows and links serial devices to program flags or variables on the ISY via REST), maybe it could fit in here somewhere.

 

io-guy,

 

Can I ask how you're controlling serial devices via your ISY? Are you using the network module?

I just picked up a digi portserver, and I'm not really sure how I'm going to set it up. Do I use HTTP protocol or TCP or something else? I know the host and port is straight forward, the commands I got to work directly from my laptop, so i'm figuring I'll be able to get that part right.

 

BUT, I got a little nervous when you mentioned custom window apps, I'm hoping these are only necessary for communicating TO the ISY.

 

My programming experience is practically nil, but I have managed to set up my ISY to control some IR functions of AV equipment with a GC iTach, as well as my DirecTV boxes via network, so I'm not totally clueless, but do need help.

 

Thanks in advance to anyone willing

[io_guy]

Zellarman,

Yea the custom apps are for bringing status into the ISY or custom coding like starting/closing media center and loading a video card profile.

 

In general, to power on/off devices, the ISY network module should be all you need.

 

Command setup is dependent on the device (check your manual).

They will be TCP command and likely C-Escaped (possibly Raw).

It would just be the command in your manual, followed by something like \r (carriage return).

[Zellarman]

Cool. Thanks for the fast response. I'll let you know how it goes, when everything arrives and I have some time to play with it all.

[Zellarman]

So I got the portserver setup, and it works great with one device (no carriage return or line feed required) but a second device I have, actually manufactured by the same company as the first device, but it requires either a carriage return, or a carriage return and line feed. [i'm using another different controller through the same portserver, to control this device and it works with just a carriage return after the command text, but different serial communiication test software also requires a line feed, while another testing software can't sucessfully control this device either way], my question is, what do I use to represent a carriage return and line feed from the ISY?

[Michel Kohanim]

Zellarman,

 

Please use C-Escaped from the Mode button and then:

\r = carriage return

\n = line feed

 

With kind regards,

Michel

[Zellarman]

WORKING! Thanks Michel, for your help, and a most incredible device. I've had my ISY for quite a while now, in the beginning there was a little bit of a learning curve, got past that, sat back and relaxed for some time, and now, in my attempt to ramp it up a bit through using the network module and REST interface, am even more blown away by the capabilities of the ISY than I was in the beginning. I would've never imagined I'd be where I am today working with my budget. I mean ANYTHING is possible, like Bill Gates has (as most of us have read) but I've got ALOT, and did it all myself (with the help of many in this forum of course) ISY ROCKS!

[johnradams]

I have no problem with the ISY only communicating via TCP/IP. An easy (although does cost some $) solution is the GlobalCache product.

 

This thread seems to have a lot of confusion over "what is the reason that someone wants a serial interface?" I can tell you why I want one -- it's to communicate with the Goldline (now Hayward) "ProLogic" pool controller for my swimming pool.

 

The ProLogic system can accept commands and provide status via a serial link. The command format is a little funky, and is not important here because the ProLogic ASCII commands do conform to what is very typical: commands and responses are parsable, and always end with an end-of-line (EOL) character (usually a CR or LF, but not always).

 

Why is this general format important to this conversation? Because it makes it possible for user programs to communicate with such devices without writing a special driver for the ISY. Currently, the missing piece is a piece of "listening software" in the ISY, which would store incoming characters until the (user-defined) EOL character arrives, at which time an event handler (an ISY user program) is run. No, this isn't a low-level event handler -- I'm referring to a regular ISY user program that gets to run, and is passed the character string received from the external device.

 

You might say, "well, this means that people will be effectively writing device drivers in ISY user programs!" Not really. It does mean that users will be able to send simple ASCII sequences to external devices, and process replies (including replies that were not initiated by the ISY). With the ISY handling the input, and handing the full line of text when it encounters the EOL, the user program can focus on parsing the complete line of text, and doesn't have to fool with buffering until the EOL, etc. For those of you who have fooled with serial drivers before, you can think of this as "cooked" mode on UNIX.

 

In my case, the set of commands that I might want to use with the ProLogic is pretty small (although I can imagine expanding it!). For starters, it would be really nice to use an Insteon On/Off switch to control the pool lights. An ISY program simply "watches" the switch, and sends the command to the ProLogic (via the GlobalCache). The ISY user program should then make sure the command is properly received and processed by the ProLogic. One can also query water temperature and such; you get the idea.

 

With the advent of variables in the ISY, the above is closer to reality. With some simple string functions (something as crude as BASIC's MID and LEN functions are almost enough), a few bit-mask functions for parsing goofy characters, etc. and you're got enough.

 

In summary, what I think would be useful is for the ISY to be able to:

1. send characters strings to serial devices via something like the GlobalCache (I understand this is already possible)

2. receive same (not possible at this time?)

3. run an ISY user program when a "complete" line of text has been received, passing that line of text (plus the source TCP/IP address) to the ISY user program.

 

As noted, the EOL character for each remote device needs be configurable.

 

It is furthermore assumed that each remote serial device would have its own TCP/IP address (virtual serial port) on the GlobalCache or equivalent. This address can be ignored by the ISY user program (at your own peril!) if there is only one external serial device.

 

Advantages of this scheme:

(a) UDI only needs to create a SINGLE serial port driver

( use of GlobalCache eliminates need for actual serial port

© this one driver can be used for all sorts of applications

(d) true ISY device drivers don't need to be created for simple bi-directional I/O operations with external serial devices

 

What do others think about this scheme?