Premise Control devices via TCP/IP?

Motorola Premise

123

Senior Member
I've seen support for serial and IR device interfaces but what about TCP/IP? How can you open a TCP port and send/receive data?

I'm trying to convert an existing Elk M1 driver, written in Perl, to work in Premise. In Perl, one employs the "IO::Socket::INET", or "IO::Socket::SSL", module to provide simplified access to a TCP port. How does one achieve this with Premise scripting? Are Premise's TCP classes employed? If so, an example would be greatly appreciated!

An Elk M1 driver for Premise would provide a whole new audience for this great HA app. The M1 offers security plus automation interfaces (relays, thermostats, temperature probes, X10/Zwave/Insteon lighting, etc) and the combination would be very powerful. The M1 does have a serial interface but many DIYers get the optional Ethernet interface (M1XEP)to maximize flexibility.

More info:
http://www.cocoontech.com/index.php?showtopic=8920
http://sourceforge.net/projects/elkm1control

======================
Premise supports TCP/IP. Both the Barix and Global Cache drivers are written as such. Having said that, I don't think the driver SDK supports TCP/IP as an option.
======================
Yes, I've seen that several drivers (Axis, Barix, GlobalCache, PanasonicCameras) do provide TCP/IP communications. However, they are based on DLLs, probably developed using the driver SDK, and I can't find any documentation on how they were written.

There are plenty of examples of module-based drivers but they all use serial or IR interfaces. I'm looking for an example of a module-based driver that communicates via TCP/IP. There are many devices that have Ethernet interfaces and documented APIs(Tivo, Roku Soundbridge, etc).

Can anyone provide a simple example of how to communicate via TCP/IP using a module/scripting?
======================
Some devices are upnp enabled (like the roku). If they are, the upnp av control point in the files area should work.
======================
With the driver SDK you can write these types of drivers directly using C++, although I don't know if it is still available anywhere. For simple uses, it is harder than the other way.

You can also use the following mechanism.
  1. Create a custom serial device and implement it however you want.
  2. Add the Lantronix devices add-in and create a UDS-10 device. Specify the IP address and port number that your real device uses.
  3. Set the custom devices "Network" property to point to the fake UDS-10 device.
The reason this works is that a UDS-10 is just a passthrough device.
SYS just opens the IP address/port and sends/recvs data. All of the baudrate and other serial port options are ignored when going through a UDS-10. It is assumed the UDS was already configured appropriately.

--jim

======================
Try using the lantronix uds10 driver, but without really hooking up the uds10. Premise will allow you to put the IP address and TCP port of the device you are trying to connect to and let you communicate to it as if it were a serial port. I use this for communicating over ethernet to a microsoft mediacenterPC. Works well.
======================
I want to confirm that this tip worked for me.

I'm developing an Elk M1 driver module and I want it to communicate via Ethernet (using the M1's XEP module). I've established basic communciations between Premise and the M1 via port 2101 ... so I'm a happy camper.

Many thanks for this valuable tip!
======================
Good luck on the Elk M1G work! I'd be very interested when you complete this.
======================
Thanks! I've divided the problem in two halves: building the logic to receive/transmit Elk M1 messages (an exercise in string-parsing!) and constructing Premise classes and logic to expose/manage the M1 data (scouring the forums for module examples!).

So far I've learned how to construct a hierarchy of container classes (more or less) to hold the Areas, Zones, Outputs, Keypads, etc. I'm also receiving and interpreting the M1's messages (but simply dumping it out to the Windows Debug Console).

The challenge will be to "wire-up" the message data to the correct Device object and property so that it will be useful to Home-level objects.
 
Back
Top