does/can linuxMCE interface to totally custom applications?

[roustabout]

One of the strengths of Crestron type systems is their ability to literally control or do ANYTHING you can dream up, just expensively through their programmers and interfacing...  am I able to basically do the same via linuxMCE?  Like roughly how difficult would it be for me to interface to something like swimming pool controls (change temperature, solar cover on or off, activate automated pool vaccum 1 hour before it may be used) or even more advanced experiments in home robotics, interfacing just the control interfaces to trigger or talk with external applications which might piggyback or work on the side... 

I'm not even sure what that would be yet, it's just a mental exploration curious whats possible.  The cooler things I can do the more motivation I am to learn the relevant programming, but are they things I can figure out with python scripts and some kind of message passing interface between custom applications to/from linux MCE, or do I have to learn all that C code everything is usually based on? 

[Marie.O]

Takes a month or two for a newbie with logical thinking ability to produce something within LinuxMCE that isn't there yet, in terms of controlling a device.

[phenigma]

*Most* devices are not difficult to interface with if there is a communications spec available.  Simple relay based control is fairly easily acheived through various interface boards.  The complexity and difficulty really depend on the type of interface your device has.

J.

[tschak909]

Like Crestron, new device drivers can be written in C++, (they can also be written in Ruby to be used by our Generic Serial Device, and in shell script to be parsed by our Whisperer).

The general process is this:

* Define a device template, which specifies the capabilities of the device (what commands it can accept, what events it can emit, how to find the device in a plug and play manner, any software that needs to be installed, etc, and any additional related devices that need to be a part of the installation in order for it to function)
* Use DCEGen to create a C++ project containing stubs, or use the built in Ruby Editor to fill in Ruby snippets (Ruby code also defines a few specific loops to handle device input, device initialization, and close, which would otherwise be explicitly defined in C++)
* Fill in the blanks, compile, add the device to your device tree... then test, fix, compile, repeat.

This is explained in detail on the wiki: http://wiki.linuxmce.org/index.php/Developing_a_DCE_Device

And in more detail on pages like:

http://wiki.linuxmce.org/index.php/Developers_Guide
http://wiki.linuxmce.org/index.php/Generic_Serial_Device

and others.

Once the device development has reached a point where things work well enough, you can work with us to push the driver into the source tree, and its relevant database information into the central sqlCVS database.

One important aspect to understand:

LinuxMCE is _not_ Crestron/AMX/etc. It was designed as the Anti-Crestron. That is, instead of explicitly defining from dirt every possible action, and debugging those actions, LinuxMCE provides an architecture of convention where the most common situations are greatly simplified (A/V hookup, for example, is no longer a matter of endless strings of macros, but we derive what needs to be done by a combination of knowing how to control each and every device, as well as the way they are connected in relation to other devices. The end result being that a user has to do much less work to get things working, usually adding devices creates scenarios automatically, with user scenarios added at their own convenience with wizards.)

We have a considerable amount of architecture. Over 4 million lines of C++ code, of our own, not counting the 12 or so projects that we appropriate from upstream. This takes time for any interested developer to understand, and my standard answer to this is, "take a year of your life, and learn this system."

The holes left in our architecture are a result of planned features that never quite left the database schema (such as multiple outputs in a matrix), and that we simply don't have the setup to be able to develop or test.

-Thom