Difference between revisions of "A new concept in collaborative development"

From LinuxMCE
Jump to: navigation, search
(Imported document)
 
(LinuxMCEified)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>Pluto introduces 2 new software programs--GSD and sqlCVS--which together greatly simplify collaborative development.  In a smart home environment, there are thousands upon thousands of relatively simple devices that all have proprietary protocols for controlling them.  Many high-end TV's and stereos have rs232 controls, which work much better than infrared.  Plus there are lots of other devices with RS232, RS485 or Ethernet ports, like pool controls, sprinkler systems, alarm panels, lighting controls, etc.</p>
+
[[Category: Programmer's Guide]]
  
<p>For example, call the manufacturers of high-end TV's with RS232 ports.  They will confirm that if they want their TV to work nicely in a smarthome system, they have to ship one TV to http://www.crestron.com">Crestron</a> and another to <a href="http://www.amx.com (the two leading smarthome providers), where C++ coders start writing new software drivers. These drivers then need to be compiled, and the resulting binaries distributed to dealers. It's a terribly expensive and burdensome process.</p>
+
Linux MCE contains two software programs -- GSD and sqlCVS -- which together greatly simplify development for "smart home" devices. There are thousands upon thousands of relatively simple devices that all have proprietary protocols for controlling them.  Many high-end TV's and stereos have RS-232 controls, which work much better than using an IRBlaster like TiVo uses. Plus there are lots of other devices which communicate over RS-232, RS-485 or Ethernet. Like pool controls, sprinkler systems, alarm panels, lighting controls, etc.
  
<p>Further, it means that only software programmers can write new device driversYet, these drivers are really very simple--usually just sending/receiving some characters across a com or network port. So, we wanted a new approach that made it easy for non-programmers to add support for new devices, and that whenever one person added a new device, every other Pluto user would immediately have access to it without downloading or compiling anything.</p>
+
For example, call the manufacturers of high-end TV's with RS-232 portsThey will confirm that if they want their TV to work nicely in a smart home system, they have to ship one TV to [http://www.crestron.com Crestron] and another to [http://www.amx.com AMX] (the two leading smart home providers), there C++ coders start writing new software drivers. These drivers then need to be compiled and  distributed to dealers. This is an expensive and burdensome process for everyone involved. The manufacturer needs to pay for the coding service and the end user needs to get a special driver disk from a dealer and install the driver which may or may not work with their home automation software.
  
<p>So, to add support for a new device, all you do is go into the Pluto Admin web site, click a 'new device' button, and then check off what commands that device knows how to implement (like 'on', 'off', 'skip forward', 'set temperature', etc'), what events it fires (like 'track changed', 'power is off', etc.), and what data parameters it needs.</p>
+
It also means that only software programmers can write new device drivers. But, these drivers are really very simple, usually just sending/receiving a few simple commands, well within the reach of most people setting up home automation software. Instead of requiring custom modules for each of these devices LinuxMCE has a Generic Serial Driver or GSD which pulls device definitions from the local database, and sqlCVS provides a data replication that allows one user to send an updated definition to a central database and have that definition replicated to other users with the same device.
  
<p>The GSD wizard then presents a simple web form with a text box for each of the commands.  Type in each box the command to send the device when it needs to execute that command.  For example, to turn on a Denon Receiver you send it the string PWON followed by a carriage return.  Just put: <$"PWON\r"$>    in the input box next to the "ON" command.  If the protocol is more complicated, GSD includes an embedded Ruby language processor.  Ruby is a very comfortable yet powerful high-level OO language.  Using the snippets of embedded Ruby code you can do almost anything.  Even very complex, bi-directional automation systems, like EIB, are done with the same GSD system.  Since the whole process is very structured, this ensures all devices are uniform and interchangeable. The structure, protocol and Ruby snippets you create are stored in are automatically stored in a local database on your Core.</p>
+
So, to add support for a new device, all the user needs to do is go into the LinuxMCE Admin web site, click a 'new device' button, and then check off what commands that device knows how to implement (like 'on', 'off', 'skip forward', 'set temperature', etc'), what events it fires (like 'track changed', 'power is off', etc.), and what data parameters it needs.
  
<p>This is where the 2nd piece of the puzzle comes in: sqlCVS. If you leave the check box "Share my I/R and GSD devices with other", then sqlCVS will keep your database synchronized a central sqlCVS server. If you know programming with source control programs like CVS or SVN, sqlCVS essentially does the same thing with a database that those programs do with source code. It features atomic commits, tracks ownership at the record-level, gives us at Pluto a control panel to monitor all activity on the database and rollback or correct bad data.</p>
+
The GSD wizard then presents a simple web form with a text box for each of the commands. The user types in each box the command to send the device when it needs to execute that command. For example, to turn on a Denon Receiver you send it the string PWON followed by a carriage return.  Just put: "PWON\r" in the input box next to the "ON" command. If the protocol is more complicated, GSD includes an embedded Ruby language processor. Ruby is a very comfortable yet powerful high-level programing language. Using the snippets of embedded Ruby code you can do almost anything. Even very complex, bi-directional automation systems, like EIB, are handled with the same GSD system. Since the whole process is very structured, this ensures all devices are uniform and interchangeable. The structure, protocol and Ruby snippets you create are stored in are automatically stored in a local database on your Core LinuxMCE system.
  
<p>Together GSD and sqlCVS make adding and sharing smart home device drivers an automatic and trivial task. Since Pluto keeps all devices isolated, a total newbie can experiment knowing he can't do anything to break Pluto. Adding new devices is a simple fill-in-the-blanks process. And without doing anything, automatically all Pluto users can share the same database of devices.</p>
+
This is where the 2nd piece of the puzzle comes in: sqlCVS. If you leave the check box "Share my I/R and GSD devices with other", then sqlCVS will keep your database synchronized a central sqlCVS server.  If you know programming with source control programs like CVS or SVN, sqlCVS essentially does the same thing with a database that those programs do with source code.  It features atomic commits, tracks ownership at the record-level, gives us at LinuxMCE a control panel to monitor all activity on the database and rollback or correct bad data.
 +
 
 +
Together GSD and sqlCVS make adding and sharing smart home device drivers an automatic and simple task. Since LinuxMCE keeps all devices isolated, anyone can experiment knowing that they can't do anything to break LinuxMCE. Adding new devices is a simple fill-in-the-blanks process. All LinuxMCE users can share the same database of devices as soon as the user who wrote the definition for their device clicks the "share my device" checkbox on the website.

Latest revision as of 00:41, 11 October 2007


Linux MCE contains two software programs -- GSD and sqlCVS -- which together greatly simplify development for "smart home" devices. There are thousands upon thousands of relatively simple devices that all have proprietary protocols for controlling them. Many high-end TV's and stereos have RS-232 controls, which work much better than using an IRBlaster like TiVo uses. Plus there are lots of other devices which communicate over RS-232, RS-485 or Ethernet. Like pool controls, sprinkler systems, alarm panels, lighting controls, etc.

For example, call the manufacturers of high-end TV's with RS-232 ports. They will confirm that if they want their TV to work nicely in a smart home system, they have to ship one TV to Crestron and another to AMX (the two leading smart home providers), there C++ coders start writing new software drivers. These drivers then need to be compiled and distributed to dealers. This is an expensive and burdensome process for everyone involved. The manufacturer needs to pay for the coding service and the end user needs to get a special driver disk from a dealer and install the driver which may or may not work with their home automation software.

It also means that only software programmers can write new device drivers. But, these drivers are really very simple, usually just sending/receiving a few simple commands, well within the reach of most people setting up home automation software. Instead of requiring custom modules for each of these devices LinuxMCE has a Generic Serial Driver or GSD which pulls device definitions from the local database, and sqlCVS provides a data replication that allows one user to send an updated definition to a central database and have that definition replicated to other users with the same device.

So, to add support for a new device, all the user needs to do is go into the LinuxMCE Admin web site, click a 'new device' button, and then check off what commands that device knows how to implement (like 'on', 'off', 'skip forward', 'set temperature', etc'), what events it fires (like 'track changed', 'power is off', etc.), and what data parameters it needs.

The GSD wizard then presents a simple web form with a text box for each of the commands. The user types in each box the command to send the device when it needs to execute that command. For example, to turn on a Denon Receiver you send it the string PWON followed by a carriage return. Just put: "PWON\r" in the input box next to the "ON" command. If the protocol is more complicated, GSD includes an embedded Ruby language processor. Ruby is a very comfortable yet powerful high-level programing language. Using the snippets of embedded Ruby code you can do almost anything. Even very complex, bi-directional automation systems, like EIB, are handled with the same GSD system. Since the whole process is very structured, this ensures all devices are uniform and interchangeable. The structure, protocol and Ruby snippets you create are stored in are automatically stored in a local database on your Core LinuxMCE system.

This is where the 2nd piece of the puzzle comes in: sqlCVS. If you leave the check box "Share my I/R and GSD devices with other", then sqlCVS will keep your database synchronized a central sqlCVS server. If you know programming with source control programs like CVS or SVN, sqlCVS essentially does the same thing with a database that those programs do with source code. It features atomic commits, tracks ownership at the record-level, gives us at LinuxMCE a control panel to monitor all activity on the database and rollback or correct bad data.

Together GSD and sqlCVS make adding and sharing smart home device drivers an automatic and simple task. Since LinuxMCE keeps all devices isolated, anyone can experiment knowing that they can't do anything to break LinuxMCE. Adding new devices is a simple fill-in-the-blanks process. All LinuxMCE users can share the same database of devices as soon as the user who wrote the definition for their device clicks the "share my device" checkbox on the website.