LinuxMCE - User contributions [en]

GSD - Ruby codes

2007-08-11T15:16:57Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

== GSD ==
Generic Serial Device is a module that offers basic functionality for accessing devices via the serial port (mostlly through the RS232 interface). The project sources are located in pluto/src/Generic_Serial_Devices.

== Command implementation in Ruby ==
For Generic Serial Devices the architecture allows implementing the commands directly from the LinuxMCE Admin Web Page, using Advanced/Device Templates. After picking the device template, select ruby codes and add the command groups that you want to implement (should be supported by the devices for witch you want to create the template)

The framework offers an Ruby ''Command'' object that actually behaves as a container for data also found in the C++ class Command from DCE. In order to create an instance of the ruby command use:

cmd = Command.new( <device from>, <device to>, <priority>, <type>, <id>)

There is a hash map associated with the command object that allows setting values for the command parameters:

cmd.params_[<parameter id>] = <string value for command parameter>

And for sending the command you should use the SendCommand function:

SendCommand(cmd)

Directly implementing each command this way may prove inconvenient. You can use the Private Method dummy command for writing helper functions. Besides from the params_ member, the ruby Command object has members for all the parameters from the constructor. Still, the wrapper offers only simple access to what a command really is in the DCE Framework, but, of course, it can be extended to allow more by adding members to the RubyCommandWrapper C++ class. All that's implemented here gets translated to Ruby.

The actual forwarding to the DCE framework is done in the Generic_Serial_Device project, in classes implementing RubyDCEConnector (ex: RubyIOManager). These are used at their turn from the RubySerialWrapper, witch offers the actual context where the Ruby code runs (Ruby twin classes are generated for each device at runtime). The SendCommand used above is a method of the RubySerialWrapper class.

Orbiter with OpenGL enabled

2007-08-11T15:00:11Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

OpenGL drawing work in a separate thread which may mean that will not mix with actual Orbiter as architecture and will draw only when effects are pending, else it stays in idle mode.
Also OpenGL painting is not frame based: to understand easy what means that you may think that OpenGL "screen shots" on one moment the stage of the animation and display on screen. If it gets many "frames" the look will be animated.
If your computer's hardware is capable to made a fluid animation, everything will look nice, else the animation skip the frames to complete in setted time.
If you get lower performance you may reduce the resolution of your screen or bpp (bits/pixel = bit color depth of image). Too you must assure that your accelerated drivers are enable.

That implementation splits the OpenGL drawing by Effect part.
- the high level class for drawing of 2D components is named Widget, and is covered by DrawingWidgetsEngine.
- effects are covered by class GL2DEffectFactory

The DrawingWidgetsEngine::Paint() and DrawingWidgetsEngine::Flip() are usually not called by an effect/opengl programer.

First of them iterates all widgets and draw them if they have the visible flag set true.
Flip method will made the complete update to the screen.

The decision of separation of the Paint (3D render) and flipping is cause some implementations may add different OpenGL code, for instance it may mix with one texture, etc.

Photo Screen Saver

2007-08-11T14:59:41Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

Photo Screen Saver is an OpenGL application that will slide different images which are taken from www.flickr.com site.
They are downloaded by the script /usr/pluto/bin/flickr.pl
The params of that script are: minwidth, minheight, and which number of previous days should be searched.

The all files are downloaded by at the folder /home/flickr/[year]/[mount]/[day]

After the script saves some files the PhotoScreenSaver (PSS) is started.

PSS is a child device of Orbiter which means that will get different parameters from the admin page and will be started/stopped by Orbiter itself.

What is the normal flow of PSS?

[[1. Initialization]]

[[2. Animation thread]]

[[3. Finalization]]

OpenGL Introduction

2007-08-11T14:58:43Z

Mstovenour: Added to Category: Programmer's Guide

STEngine

2007-08-11T14:57:14Z

Mstovenour: Added to Category: Programmer's Guide

Sql2cpp

2007-08-11T14:54:19Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<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><h1>How does it work?</h1>
<p>sql2cpp creates a C++ library that makes it very easy to work with a relational database. Just run sql2cpp passing in the login information for a database. This will create a stand-alone library with a "Database" class that has members for each of the tables. Each table has a "Table" class that has members to get row(s), and each table has a "Row" class with members for each of the fields. sql2cpp creates member functions that make it very easy to traverse foreign key relationships. You can traverse multiple tables across several relationships on one command line, and with one line get pointers to all other rows referencing it. This often reduces 20 or so lines of code down to 2 or 3 and makes the code much more readable.</p>
<h1>Examples:</h1>
<p>You have a simple database called "Accounting". It contains tables "Sale", "Product" and "Manufacturer". The respective Primary keys are "PK_Sale", "PK_Product", and "PK_Manufacturer". Sale has a foreign key to Product (FK_Product), indicating the product that was sold. Product has a foreign key to Manufacturer (FK_Manufacturer) indicating who made the Product. sql2cpp will create classes Database_Accounting, Table_Sale, Row_Sale, Table_Product, Row_Product, Table_Manufacturer, Row_Manufacturer.</p>
<p>If you want to get the row for sale #82 (ie where the primary key is 82), just do:</p>
<p><h4>Database_Accounting myAccounting;<br>
Row_Sale *pSale = myAccounting.Table_Sale.get().GetRow(82);</h4></p>
<p>Then if you want to know the name of the Manufacturer who made the product sold, you can traverse the relationships across all 3 tables with 1 line:</p>
<p><h4>string Name = pSale->FK_Product_getrow()->FK_Manufacturer_getrow()->Name_get();</h4></p>
<p>If you want to want to get a list of all products made by manufacturer #94, just create a vector of Row_Product, and call this function:</p>
<p><h4>vector<Row_Product *> vectProducts;<br>
myAccounting.Manufacturer_get().GetRow(94).Product_FK_Manufacturer_getrows(&vectProducts);</h4></p>
<p>That will fill the vector with all the rows in Product that reference this manufacturer by the field FK_Manufacturer.</p>

<p>You want to add a new manufacturer:</p>
<p><h4>Row_Manufacturer *pRow_Manufacturer = myAccounting.Table_Manufacturer.AddRow();<br>
pRow_Manufacturer->Name_set("Acme Tools"); // Set the other fields too<br>
myAccounting.Table_Manufacturer.Commit(); // Commits any new, modified or deleted rows<br>
int New_Auto_Increment_PrimaryKey = pRow_Manufacturer->PK_Manufacturer_get(); // It was set during the Commit<br>
pRow_Manufacturer->Delete(); // Delete the record after all</h4></p>

<h1>Give it a try</h1>
<p>To try it out, just run sql2cpp with login information for your database. It will create a complete project including a gcc-compatible Makefile and a Microsoft Visual Studio .NET project. If you want it to handle traversing foreign keys you will need to follow our naming convention, described in the Programmer's Guide, so sql2cpp can figure out what are foreign keys and what tables they refer to.</p>

SqlCVS

2007-08-11T14:52:42Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<h1>Sample Uses</h1>
<p>A chain of retail stores wants all the stores to share a common customer database, but not all the stores have high-speed internet connections to the main server. Each gets a local copy of the database and synchronizes nightly with the main server.</p>
<p><b>*or*</b> At the end of the year a company wants to let the accountants work on year-end adjustments off-site or off-line. The accountants can do audits, make changes, roll-back changes that don't seem right and work with the database without touching the main database. Only when they are finished they merge in their changes.</p>
<p><b>*or*</b> For faster performance and less strain on the master server employees work on local copies of the database and merge changes nightly.</p>
<p><b>*or*</b> Even if you don't care about synchronizing or working off-line you still want good history tracking and the ability to roll-back erroneous changes. You could enable full logging in MySQL, but that doesn't let you roll-back one user's transactions on June 10, or remove everything that one user did, or checkout a copy of your database as of May 15 at 11:45.</p>
<h1>Why did LinuxMCE develop it?</h1>
<p>We built it for our LinuxMCE smart home system because our product is very database dependent. Everything is stored in a database--the documentation, the infrared codes, the programmer's class definitions, even the graphics user interface. We have a fully automated sqlCVS repository that automatically gives every user a working copy of the database and synchronizes shared tables, like infrared codes, with every other user.</p>
<h1>How does it work?</h1>
<p>The User's Manual has more details, but in a nutshell, you put the 'master' database on a server which only sqlCVS has access to, and run sqlCVS listen on the server which opens a port for incoming connections. Any clients then do a sqlCVS import (like a checkout) to get a local working copy. The clients do a sqlCVS update to merge their changes back into the master database, and pull changes from other users.</p>
<p>If there are conflicts because multiple people checked in records with the same auto-increment primary key, sqlCVS handles re-assigning the new number, and propagates the changes to all the foreign key's that reference it. If you change a row that someone else has changed, you are shown the difference and given the option of using your version or the other person's. sqlCVS keeps a full, permanent history of every modification and features atomic commits, so the database is "versioned" after each checkin. It tracks permissions and table + record level ownership. So, if user A makes changes to a row or table that belongs to user B, when he does a checkin, user A's changes are isolated and he is given a batch number and user B's user ID. User B can review the changes user A made, and then approve the batch, causing those changes to be merged into the master database. sqlCVS also supports forking, and remerging branches. At LinuxMCE we use this when we want to change versions, and to allow different people to work with the 'development', 'testing', and 'release' versions.</p>
<h1>What changes do I have to make to my application?</h1>
<p>sqlCVS is completely transparent. The software that uses the database does not need to be aware of sqlCVS. The only database consideration is that the field names must follow a logical naming convention so sqlCVS can determine what are foreign keys.</p>

Message Interceptors

2007-08-11T14:49:51Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<p>This allows your device to tell DCERouter that it wants to get copies of all messages that meet a certain criteria. For example, a device may want to work with the lights and get copies of all messages going to a light, or another may want a copy of all events from the disk drive. When you register a message interceptor with DCERouter you specify 6 numeric parameters which limit the messages you will receive. For each you can specify 0, which means match all, or a non-zero integer which means only match messages which match that criteria. If you register a message interceptor with all 0's, you will get all messages. Be sure to provide restrictions so you only get the messages you really need. DCERouter processes lots of messages, so if you register a message interceptor that is too vague, you could get flooded. For example, the media players typically broadcast a message every second with an updated time code. If you register a message interceptor to grab all messages from a media device, you would get time-code messages every second. Note that parameters act as 'AND' not 'OR'. If you register for DeviceCategory="Media Player" and MessageID="Play Media" you will get messages that are both going to Media Players AND have an ID of Play Media. If you wanted to get messages that go either to Media Players OR have an ID of Play Media, then register 2 separate interceptors.</p>

<p>From (PK_Device): If specified you will only get messages from this particular device ID.</p>
<p>To (PK_Device): If specified you will only get messages to this particular device ID.</p>
<p>Template (PK_DeviceTemplate): If specified you will only get messages to devices of this particular DeviceTemplate. Note that if the message type is an Event, that is coming from a device rather than going to it, the Router will look at the template of the From device.</p>
<p>Category (PK_DeviceCategory): If specified you will only get messages to devices of this particular DeviceCategory. Note that if the message type is an Event, that is coming from a device rather than going to it, the Router will look at the category of the From device.</p>
<p>MessageType: The type of message, as defined in the source file DCE/Message.h. The 2 most common message types are 1 and 2 (MESSAGETYPE_COMMAND=1, MESSAGETYPE_EVENT=2). But you can also receive message of type 7 (MESSAGETYPE_SYSCOMMAND=7) if DCERouter is reloaded. In this case MessageID is 1 and it means 'Reload'</p>
<p>MessageID: The ID of the message, as defined in the source file DCE/Message.h. The ID depends on the message type. Event ID's are defined in the table 'Event' in pluto_main. Command ID's are defined in the table 'Command'. In LinuxMCE Admin you can choose 'Advanced', 'DCE' to see the command and event ID's. If you specify an ID, you should also specify a type. A command ID of 19 is "Set House Mode" whereas an event ID of 19 is "Watching Media". So if you only specify the ID of 19, and leave MessageType as 0, your interceptor will get both "Set House Mode" commands and "Watching Media" events.</p>

<p>To register a message interceptor, call the RegisterMsgInterceptor member function, with the Command_Impl class that all plugins and devices are derived from:</p>
<p>RegisterMsgInterceptor( ( MessageInterceptorFn )( &Media_Plugin::MediaInserted ), 0, 0, 0, 0, MESSAGETYPE_EVENT, EVENT_Media_Inserted_CONST );</p>
<p>This means the member function Media_Plugin::MediaInserted, which must match the definition of MessageInterceptorFn, will be called whenever a device fires a "Media Inserted" Event.</p>

<p>If you are not using the DCE C++ library, you can send a message to DCERouter manually to register the message interceptor, and then you will get intercepted messages encapsulated within another message. To register a message interceptor this way, send a message to DCERouter, which is always device ID -1000 (#define DEVICEID_DCEROUTER -1000) with a MessageType of 8 (MESSAGETYPE_REGISTER_INTERCEPTOR=8). The parameters for the message are the 6 interceptor parameters: enum { PARM_FROM=1, PARM_TO, PARM_TEMPLATE, PARM_CATEGORY, PARM_MESSAGE_TYPE, PARM_MESSAGE_ID };<p>

<p>Here is the same interceptor sent by hand, not using the framework:<p>
<p>Message *pMessage = new Message(m_dwPK_Device,DEVICEID_DCEROUTER,PRIORITY_NORMAL,<br>
MESSAGETYPE_REGISTER_INTERCEPTOR,2,<br>
PARM_MESSAGE_TYPE,MESSAGETYPE_EVENT,<br>
PARM_MESSAGE_ID,EVENT_Media_Inserted_CONST);<br>
QueueMessageToRouter(pMessage);<br>
</p>

<p>In this case you will receive all intercepted messages embedded within a message of type: MESSAGETYPE_MESSAGE_INTERCEPTED. The actual intercepted message will be the single embedded message in m_vectExtraMessages.</p>

DCE Libraries

2007-08-11T14:43:53Z

Mstovenour: Corrected link to LinuxMCE_main database page

[[Category: Programmer's Guide]]

<h1>Introduction</h1>
<p>If you want to dive right in to the "make your own DCE Device in 5 minutes" tutorial, [[Make a DCE Device in 5 minutes]].</p>
<p>DCE (Data, Commands, Events) is a lightweight network protocol allowing any device to access its configuration (ie data) from a central database, send + receive commands, and fire + respond to events. The intended use is in a smart home solution. The goal is to allow the homeowner to plug anything into his network (motion detector, intercom, telephone, media station, camera, etc.) and immediately start using it without any complicated setup. Also, we want all the devices to be interchangeable, and controllable with the same remote using the same UI. This aspect requires that developers of new devices implement, at a minimum, a standard set of commands pre-determined for that type of device. For example, if there exists a standard "Swimming Pool" remote control with buttons for temperature up & down, which fires temp_up and temp_down commands, then any new swimming pool control devices must implement the same commands for the homeowner to be able to control that device using his existing remote control. Therefore, the entire database of all devices is publicly available so a developer of a new device can share the same commands.</p>
<p>This makes a huge difference in terms of usability. Consider how popular new multi-media keyboards have become for Windows, and how convenient it is for a user to be able to press the "pause" button on his keyboard and know that whatever media player he is using--no matter who made it--will pause. This finally made universal remote controls for PC's possible, and made the PC practical as a home media player. This is only possible because Microsoft established a standard scancode/message for "pause" and all the media player manufacturers implemented it. Prior to this standardization, every media player had its own proprietary way of receiving a pause command. DCE intends to expand this standardized interoperability to all types of commands for every device in a smart home. But instead of one company dictating the standards as with the multi-media keyboard example, DCE is an open source project. The standardization becomes a cooperative effort amongst all the device developers.</p>
<h1>Compatible Software & Hardware Platforms</h1>
<p>The DCE protocol itself can be implemented with any device that supports standard networking. LinuxMCE provides a DCE library written in Ansi C++ that implements the protocol on any socket-compatible operating system, and has been tested on Linux and Windows. Porting to other languages should not be a big task. Because the messaging is socket-based, any device, regardless of operating system or language, can be used with any other device.</p>

<h1>Plug & Play Support</h1>
<p>The LinuxMCE platform includes a utility that monitors requests for IP addresses from the DHCP server. When a new device is detected with an unrecognized Mac Address, it looks up the Mac Address in a master database to see what type of device it is and if it corresponds to a DCE Device. If so, the device is automatically added to the system, the software is added, a configure script is executed, and the user is notified. When you make a DCE Device, you are able to specify all these options, including ranges of Mac Addresses for your devices and what default data parameters they should use.</p>

<h1>How do DCE Devices talk to each other?</h1>
<p>In each installation there is also 1 DCE Router, through which all messages are routed. An "installation" is a group of devices treated as a unit, and normally corresponds to a physical residence.</p>
<p>The DCE Router is itself quite simple. It just opens a port for incoming connections. When a device connects, the device sends its unique ID, or MacAddress. The DCE Router does a lookup in a database, and returns that device's data (configuration). DCERouter also sends back a list of all the other devices in the installation with basic information including the commands they know how to implement. The DCE Device then opens a minimum of 2 socket connections to the router. One is for incoming messages (usually commands) from the router, another for outgoing messages (usually events) to it. The DCE Library, which implements the protocol for DCE Devices and the DCE Router, will also open a 3rd socket connection so that it has 2 outgoing sockets: 1 dedicated for sending events and the other for sending other types of messages, like requests and commands to other devices.</p>
<p>All messages go through the router--devices do not communicate directly to each other. The message will contain information such as the destination device, the type of message, the message id, and any number of optional parameters. The router does nothing with the message but forward it to the destination device, or devices if the message is being sent to more than one. The DCE library, from which DCE Devices and the DCE Router are derived, knows how to receive incoming messages of the type command, and route them to a message handler in the DCE Device. This works in conjunction with the [[DCE Generator]] utility.</p>
<h1>DCE Generator builds a complete Linux/Windows DCE Device for you</h1>
<p>The definition of the device, including its data, commands and events is stored in a central database, described [[LinuxMCE_main_database]].</p>
<h1>Next Steps</h1>
<p>This section of the documentation explains the specifics of DCE. You can also learn how to configure DCE Device definitions, called templates, [[LinuxMCE Admin Website]] using the LinuxMCE Admin web site. Under Developers/Source Code docs you will find documentation for the DCE library code.</p>
<p>[[Make a DCE Device in 5 minutes]] will show you how to make a DCE Device in 5 minutes.</p>
<p>Download the source code for the C++ DCE library using the http://LinuxMCE.com/support/index.php?package=0&section=mainDownload, or check it out from our [[Building from source]].</p>

Pluto main database

2007-08-11T14:41:45Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<p>Virtually everything about LinuxMCE is stored in this database. The DCE definitions, the documentation, the list of software and the requirements to use it, the boot scripts, even the graphical user interface on the Orbiters is here. Most of the software modules in LinuxMCE will need this database to run. The [[LinuxMCE Admin Website]] web site is the primary front-end for the database. Use it to configure everything in your LinuxMCE system, browse your local copy of the documentation, and just about everything else. The one exception is the graphical user interface on the Orbiters. It would not be practical to build a GUI in a web, so there is a separate program, Designer, which is used to edit the GUI.</p>
<p>The database contains a collection of sqlCVS repositories, with tables grouped by function. All LinuxMCE systems have the same database, with the same data, except for the tables in the "local" repository. These include the Devices, Installation and Users, and their related tables. This information is only in your local copy. LinuxMCE's central database only keeps track of the ID's that have been used so that we can ensure that every device, installation and user is globally unique, allowing you to join houses, and do other things that require unique ID's. The LinuxMCE Admin web site will request a unique ID from www.linuxmce.com when you add a Device, User or Installation.</p>

DCERouter

2007-08-11T14:39:14Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<p>DCERouter has no options or user interface, so there is no documentation for users--only technical documentation.</p>
<p>DCERouter is the central piece of software that all [[LinuxMCE DCE Devices]] for documentation on the DCE socket-based messaging protocol.</p>
<p>Normally DCE Devices run separately from the router. Since they communicate over a socket, they can be on the same computer, or another computer with an internet connection. A DCE Device can also be run in the DCE Router's memory space. These devices are called plug-ins. However, they are really identical to the other DCE Devices. In fact, all DCE Devices come with 2 projects/Makefiles--1 to run as a normal, external DCE Device, and 1 to run as a plug-in. Of course, running as a plug-in is much more dangerous since it is in the same memory space and can therefore crash the whole router, and bring the whole LinuxMCE system down. Therefore it is encourages to run devices as plug-ins only when necessary because the device needs to be able to intercept messages that may not be directed to it. Since all the plug-ins run in the same memory space, they have access to the actual class pointers for the other plug-ins, and can therefore efficiently share data and call each other's functions. To make your DCE Device a plug-in, just check the "Is Plug-in" box when defining the device in the "Device Template" section of the configuration web site. Then compile it using the DLL-version of the project under Windows, or the so (for shared object) switch on the Makefile under Linux.</p>

DCE Devices

2007-08-11T14:38:38Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

A DCE Device is any device that can connect to a [[DCE Router]] to get its Data (ie configuration settings), receive commands, and fire events. Nearly everything in LinuxMCE is a DCE Device, including telephones, lights, DVD players, TV's, etc. Many devices, like a TV, may not implement DCE directly, but rather they are children of another device that does, such as the infrared transmitting gc100. In that case, the parent, which does implement DCE, is responsible for controlling the children. Alarm panels are another example. There is usually a DCE Device that implements DCE for the panel itself, but the children (motion sensors, smoke detectors, etc.) are just controlled by the panel.</p>
<p>This section includes documentation for the DCE Devices. For an explanation of the DCE protocol and accompanying libraries, see the [[LinuxMCE Libraries DCE]].</p>

DCE Generator

2007-08-11T14:37:14Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<p>To create a new [[LinuxMCE DCE Devices]] to start receive commands immediately.</p>
<p>DCEGen creates a Command class that has stubs for all the commands you need to implement. The default implementation just echoes to the screen that the command was received and lists the parameters. The Command class will also have member variables for the device's data, and methods to call to fire events.</p>
<p>If you later change the device, adding commands, changing event parameters, removing data, etc., just re-run DCEGen. It will fix your project file with these changes. If you already began implementing the commands and changing the class that is not a problem. DCEGen will simply merge the changes in, creating new methods for new commands, and changing the declarations and definitions for commands that have changed. It will also re-write the 'Events' and 'Data' section each time since there is nothing for you to implement there.</p>

GSD to drive a Weeder I/O WTDIO-M

2007-08-11T14:35:30Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

== General notes ==

Weeder boards are very nice and inexpensive pieces of hardware that fit well enough to many situations related to home automation.

The model I'm referring to is WTDIO-M, that is a 14 channel digital I/O board that connects to pc via RS232 and is also stackable to a max of 32 modules (that means 448 I/O channels, quite enough ...).
Further details can be found here -> http://www.weedtech.com/wtdio-m.html

Usually they require some extra hardware (you cannot drive directly any relays, so some transistor are needed in between) but it's something that does not require a rocket scientist to be done.

== How to talk to the board ==

The board has its own communication protocol, that allow you to write/read a specific channel of a specific module by sending the appropriate string to the serial port and by reading back the answer.
The protocol takes care also of collision on the common media (serial line) so you don't have to bother with anything else.

The command string usually is something like this:

'''ModuleAddress-Command-ChannelAddress-OptionalParameters'''

So from a LinuxMCE point of view it is a matter of defining a GSD device with some child devices attached (each child device corresponding to a board channel we want to control), and to define in the parent device some logic (Ruby code) to handle the commands that suit our needs.
It is not necessary to handle Ruby code in each and every child device, as LinuxMCE allows to pass the command received from a child device to its parent, that is in charge to process it.

== A (very) simple example ==

In this example I will explain how to use this board to switch on/off some channel (corresponding to some lights/simple appliances).

First of all let's create a GSD device in LinuxMCE Admin to your core/hybrid or to the MD where the board is physically connected. Say that we name it "Weeder Board".

Let's configure it with proper parameters:

''COM Port BaudRate:'' B9600 (write it like this, "B9600", I lost days entering simply "9600" and having it not working ...)

''COM Port on PC:'' /dev/ttyS1 (or whatever applies to your box)

''COM Port ParityBit/Stop:'' N81 (that stands for No parity, 8 bits, 1 stop bit, as said before enter it exactly like this if you want it working)

Then we can add some child devices. Go to LinuxMCE Admin - Advanced->Configuration->Devices, select the newly added GSD device (Weeder Board) and add some new child devices, naming them according to your needs.
On each child device record don't forget to fill in the field ''#12 Port/Channel Number(string)''.
This field allows to establish the correspondence between child device and board channel. It will be more clear in the following.

Then we are ready to add some Ruby code to manage our channels. To do it we can press the button "Ruby Source Code" that we can find in LinuxMCE Admin - Wizard->Devices ->Generic Serial Devices

Following you'll find the ruby code I use form my own board. It's very simple and rude, but it's working.

Basically it processes all command issued to child devices (that in my case are related to channels of the board, i.e. lights/appliance).
If command (cmd.id) equals to 192 (means "ON") then it checks from wich child it is coming from (device_.childdevices_[cmd.devidto_].devdata_[12]), and according to this it decides which is the proper command string to send to GSD (Weeder Board, in this example).

Say that I press "ON" button on Orbiter (button that actually is a light scenario that corresponds to channel 1 of my Weeder Board).
The proper command string to send is:

AHA

that stands for '''A''' module, '''H'''igh level, '''A''' channel. Don't forget to add a "\r" to properly close the string.
In case I press "ON" for channel 3, the string is

AHC

The same story applies when pressing "OFF", that corresponds to a cmd.id = 193

The question now is: how can I tell that a specific child device corresponds to a specific board channel?

As I mentioned above, this is done by the value entered in the field ''#12 Port/Channel Number(string)'' of each child device record, that is accessed in Ruby by reading the variable ''device_.childdevices_[cmd.devidto_].devdata_[12]''. With this value (treated as a string) you can decide what to send to what channel of your Weeder Board or in general to your Generic Serial Devices that can drive multiple channels/device.

This is the code that I entered in the ''Process Receive Command For Child'' section of the Ruby code interface (LinuxMCE Admin - Wizard->Devices ->Generic Serial Devices->Ruby Source Code)

if cmd.id_ == 192 #192 is ON
id=device_.childdevices_[cmd.devidto_].devdata_[12] #get child device number
if id=="1"
conn_.Send("AHA\r")#send string to set High the A channel of A board
end
if id=="2"
conn_.Send("AHB\r")#send string to set High the B channel of A board
end
if id=="3"
conn_.Send("AHC\r")#send string to set High the C channel of A board
end
end
if cmd.id_ == 193 #193 is OFF
id=device_.childdevices_[cmd.devidto_].devdata_[12]
if id=="1"
conn_.Send("ALA\r")#send string to set Low the A channel of A board
end
if id=="2"
conn_.Send("ALB\r")#send string to set Low the B channel of A board
end
if id=="3"
conn_.Send("ALC\r")#send string to set Low the C channel of A board
end
end

You can monitor the messages to GSD by looking at the corresponding log file in LinuxMCE, o by using the "Follow Log" option in the LinuxMCE Admin - Advanced->Configuration->Devices->Weeder Board (or whatever name you gave to your device).

To have some feedback from your serial device, you may add two simple lines in the ''Process Incoming Data'' section:

buffer = conn_.Recv(100,500);
print buffer;

This basically receives the output from the serial device and prints it into the log.

There are many other section in the Ruby code interface that may be interesting to use (or use better than I do), i.e ''Process IDLE'' and ''Process Incoming Data''.
The first should deal with some polling to perform when no commands are issued, the second should be used to give some decent feedback from serial device to the rest of LinuxMCE system.
It is a matter of parsing the received strings and interact with proper LinuxMCE variables or talking directly to DCE router.

No clear idea of the possible use of the remaining section, but I'm sure that someone will add interesting notes to help us to find it out.

Make a DCE Device in 5 minutes

2007-08-11T14:32:41Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<p>There are 2 ways to add a new device. 1) For most external devices that are controlled by RS232, USB or Ethernet, you can use GSD (Generic Serial Device). There is a 'fill-in-the-blanks' web form for you to specify the protocol--no programming is required. GSD also includes an embedded Ruby-language processor, so you can do almost anything and even complex, sophisticated devices can be created easily. Whatever protocol and Ruby commands you input are automatically sent back to our master database and shared with all other LinuxMCE users, so everyone can use the device (you can turn this option off). Nearly all external devices, like home automation components, use GSD. 2) We also have a generator that will build you a cross-platform C++ project. LinuxMCE's sophisticated, internal devices like Bluetooth communication, software media players, etc. are all written in C/C++.</p>
<p>Either way, the first step is to define the data, commands and events for your device. Go to the [[LinuxMCE Admin Website]] that was installed on your computer when you installed LinuxMCE. Login, and choose "Advanced", "Device Templates".</p>
<p>First see if you can find an existing device that has a similar function to the one you want to create. Choose an existing manufacturer and/or category to see some the devices in the "Models" list. Click edit to view the device's data, command and events. Note that the command are put into 'groups', so you will need to click on the command group to see the commands that device implements. Now figure out what data, commands and events your device will use. You can also click on "Advanced", "DCE", and view a list of all the commands in the system and which devices implement them.</p>
<p>The data parameters is not really important. It can be anything your device will need to run. If the device is going to control some equipment via RS232, you'll want a parameter to indicate the COM port, for example.</p>
<p>Next, figure out what command your device will want to implement. Here it's more important to try to use the same commands in the same way as other, similar devices. This will mean that the remote controls (Orbiters) for those devices will work for yours too. Also, other developers may expect your device to implement a logical command. For example, someone may develop a doorbell device, which allows the user to pause all his media when someone is at the door so he will hear the bell. The doorbell device may, therefore, send a "Pause" command destined to every device in the house of the category "Media Player", expecting that any media player should know what that means. From the Device Template list page there is also a link to manage commands which lets you see all the existing commands, what parameters they take, what devices implement them, and how, so that you can be sure your device is capable of behaving in a similar manner. Of course, you can add as much custom functionality as you want, but it's recommended that your device implements at least the basics in a consistent manner. On/Off, skip forward, skip back, etc.</p>
<p>Lastly, decide on what events your device should fire. Again, try to use the same events in the same way as similar devices. The user may have created an event handler, for example, that turns on a siren when the "Security Breach" event is detected. If you are making a device for an alarm panel and see that the other panels fire the "Security Breach" event, then if yours fires the same event the user will be swap his current panel for yours and know that all his event handlers will still work.</p>
<p>Once you decided on the data, command and events, you've done the hard part. Now just go back to the [[List Page]] page, choose the manufacturer, or add one, and choose a category. Once those are chosen, the 'add new' box is available under the Models list. Type in a descriptive name for your device, and click 'add'.</p>
<p>You are now on the [[Edit Page]] page. Check that the device implements DCE. You can leave alone the remotes, controlled via, package and a/v sections for now.</p>
<p>Add your device's data parameters. You can use an existing parameter if it's applicable, or add one. The name is really just a description.</p>
<p>You will see here all the Command Groups that other devices in this category already implement. Click 'Edit Commands' to see what commands are in that group. If there is a group that is appropriate for your device, just enable it to add those commands to your device. You can also create one more new groups. All commands in all groups you select will be implemented by your device. Then add the commands to your device, explaining how your device implements them. You can also add new commands. When adding the parameters for your commands, you can make the parameters "out" parameters. This means when another device sends you the command, you will get a pointer to this parameter--rather than the parameter itself. You just assign the value you want to return, and the other device that sent you the command will see it.</p>
<p>Lastly, add the events, and click save.</p>
<p>Now, decide how you want to implement your device. Choose one of the following: [[GSD]].</p>

Programmer's Guide

2007-08-11T14:31:09Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

==Introduction to the LinuxMCE Architecure==
Our distribution includes hundreds of scripts and utilities that LinuxMCE has written to fully automate everything so that a PC with LinuxMCE becomes a 'turn it on and press play' appliance, rather than a traditional software application. However if you strip away all this stuff, the guts of LinuxMCE is software written in cross-platform c++. In fact nearly all LinuxMCE's code runs on Windows too.

This guide explains the architecture of the main C++ code. Documentation for all the scripts and utilities that make up the distribution is [http://plutohome.com/support/doxygen/ here].

LinuxMCE uses an extremely modular architecture. The heart of LinuxMCE, the 'main application' DCERouter is nothing but a general-purpose message router. It has absolutely no code relating to any of LinuxMCE's functionality--it just relays messages between devices. The functionality of LinuxMCE is, therefore, entirely in separate modules (ie Devices) which all run independently and communicate with each other by passing messages through DCERouter over sockets. There can be hundreds of these devices in a smart home, that do all sorts of things. As shown in the diagram below, many of LinuxMCE's devices are actually 'wrappers' we have written for existing open source projects that allow them to work together seamlessly in a LinuxMCE system. For example, we wrote a wrapper for Asterisk that sends event messages to DCERouter whenever a phone call comes in, and receives command messages when it is time to place a call. How the wrapper communicates with the open source project depends on that project. Our Asterisk wrapper, for example, communicates with Asterisk over a socket. It is really a translator converting messages from its socket connection with DCERouter into messages from its socket connection with Asterisk. The wrapper for the Xine media player links in Xine's own library and calls Xine functions directly.

<img src="include/images/quickstart/swmodules.jpg" border="0">

Since there are literally thousands of home automation components and pieces of a/v equipment that require controlling with RS232, USB and Ethernet we developed a special system for these devices using GSD. It's fast and often doesn't require any real programming skills. It can be used to support lighting control systems, climate and pool systems, external devices like i/r emitters, cameras, etc. If that's your interest skip this whole page and [[What if you don't have a driver for my home automation device]] Otherwise if you're a "real" programmer interested in adding new software modules or adding wrappers for existing software, then continue with this section.

==Programmer's Guide Sections==

*[[Why should I use the LinuxMCE platform for my project?]]
**[[Overview of the software modules]]
**[[A new concept in collaborative development]]
**[[Adding support for home automation devices]]
*[[STEngine]]
**[[OpenGL implementation]]
**[[Photo Screen Saver]]
*[[ZWave implementation]]
*[[AVWizard specifications]]
*[[Orbiter]]
*[[wxWidgets]]
*[[Window manager]]
*[[Window controller]]
*[[X11 locking]]
*[[X11 pointer shapes]]
*[[LinuxMCE Plugins]]
*[[I want my software to run on LinuxMCE but it isn't open source]]
*[[Will you host, compile and support the LinuxMCE plug-ins for my]]
*[[GSD - Ruby codes]]
** [[Apex Destiny 6100]] (alarm panel)
*[[Automated_Builder]]

==Is LinuxMCE a stand-alone software product, or a development platform?==

LinuxMCE is sold commercially as a complete turnkey appliance. To the end user it appears to be 1 single application with 1 common user interface. From a developer's standpoint, however, LinuxMCE is actually a platform for developing smart home modules that all work together. Much of the top-level functionality is provided by a variety of open source projects. LinuxMCE adds it's own home automation engine, UI front-end, configuration web site, and the heart of it all, [[LinuxMCE Libraries DCE]], which allows this collection of devices and software projects to work together as a seamless whole.

In many cases, a LinuxMCE DCE device is just a thin wrapper for another open source project. The wrapper's job is to launch the open source project with the right parameters, forward incoming commands to it, and fire DCE events in response to triggers within it. We added DCE wrappers for the projects Asterisk (pbx telephone switch), Linphone (SIP software telephone) and Motion (surveillance video capture). In most cases, no modifications to the open source project were needed since the project already contained a mechanism for feeding it commands.

The software is completely modular and we offer a wealth of development tools, like code generators, design tools, a rapid development module for adding new devices (GSD), our own messenging platform and a ton of general-purpose libraries. Our GSD+sqlCVS is an entirely [[A new concept in collaborative development]] for quickly adding support for communicating with external equipment. If you're a developer, you can add to LinuxMCE, or even remove our modules and use LinuxMCE as a platform to do something else entirely.

==LinuxMCE allows projects to work together==

By allowing these various projects to work together seamlessly, many new features and benefits are now possible. For example, if there's a security breach in your house, the lights and TV's in the house come on automatically using our home automation DCE device interfaces, and the security pn pad appears on all the Windows webpads and PDA's. After 30 seconds a menacing video plays for the burglar using Xine, while the surveillance cameras monitored by Motion feed a live video to your mobile phone over GPRS. Hit 'Talk' on the phone and Xine suspends, passing control to Linphone which makes a call using Asterisk to your mobile phone with the audio piped through the stereo so you can shout at the intruder and let him know you're watching him from a remote location and calling. To the end-user, it works seamlessly, like 1 cohesive whole, but in reality, what LinuxMCE did is enable a bunch of existing applications to work together.

DCE Libraries

2007-08-11T14:30:11Z

Mstovenour: Added to Category: Programmer's Guide

[[Category: Programmer's Guide]]

<h1>Introduction</h1>
<p>If you want to dive right in to the "make your own DCE Device in 5 minutes" tutorial, [[Make a DCE Device in 5 minutes]].</p>
<p>DCE (Data, Commands, Events) is a lightweight network protocol allowing any device to access its configuration (ie data) from a central database, send + receive commands, and fire + respond to events. The intended use is in a smart home solution. The goal is to allow the homeowner to plug anything into his network (motion detector, intercom, telephone, media station, camera, etc.) and immediately start using it without any complicated setup. Also, we want all the devices to be interchangeable, and controllable with the same remote using the same UI. This aspect requires that developers of new devices implement, at a minimum, a standard set of commands pre-determined for that type of device. For example, if there exists a standard "Swimming Pool" remote control with buttons for temperature up & down, which fires temp_up and temp_down commands, then any new swimming pool control devices must implement the same commands for the homeowner to be able to control that device using his existing remote control. Therefore, the entire database of all devices is publicly available so a developer of a new device can share the same commands.</p>
<p>This makes a huge difference in terms of usability. Consider how popular new multi-media keyboards have become for Windows, and how convenient it is for a user to be able to press the "pause" button on his keyboard and know that whatever media player he is using--no matter who made it--will pause. This finally made universal remote controls for PC's possible, and made the PC practical as a home media player. This is only possible because Microsoft established a standard scancode/message for "pause" and all the media player manufacturers implemented it. Prior to this standardization, every media player had its own proprietary way of receiving a pause command. DCE intends to expand this standardized interoperability to all types of commands for every device in a smart home. But instead of one company dictating the standards as with the multi-media keyboard example, DCE is an open source project. The standardization becomes a cooperative effort amongst all the device developers.</p>
<h1>Compatible Software & Hardware Platforms</h1>
<p>The DCE protocol itself can be implemented with any device that supports standard networking. LinuxMCE provides a DCE library written in Ansi C++ that implements the protocol on any socket-compatible operating system, and has been tested on Linux and Windows. Porting to other languages should not be a big task. Because the messaging is socket-based, any device, regardless of operating system or language, can be used with any other device.</p>

<h1>Plug & Play Support</h1>
<p>The LinuxMCE platform includes a utility that monitors requests for IP addresses from the DHCP server. When a new device is detected with an unrecognized Mac Address, it looks up the Mac Address in a master database to see what type of device it is and if it corresponds to a DCE Device. If so, the device is automatically added to the system, the software is added, a configure script is executed, and the user is notified. When you make a DCE Device, you are able to specify all these options, including ranges of Mac Addresses for your devices and what default data parameters they should use.</p>

<h1>How do DCE Devices talk to each other?</h1>
<p>In each installation there is also 1 DCE Router, through which all messages are routed. An "installation" is a group of devices treated as a unit, and normally corresponds to a physical residence.</p>
<p>The DCE Router is itself quite simple. It just opens a port for incoming connections. When a device connects, the device sends its unique ID, or MacAddress. The DCE Router does a lookup in a database, and returns that device's data (configuration). DCERouter also sends back a list of all the other devices in the installation with basic information including the commands they know how to implement. The DCE Device then opens a minimum of 2 socket connections to the router. One is for incoming messages (usually commands) from the router, another for outgoing messages (usually events) to it. The DCE Library, which implements the protocol for DCE Devices and the DCE Router, will also open a 3rd socket connection so that it has 2 outgoing sockets: 1 dedicated for sending events and the other for sending other types of messages, like requests and commands to other devices.</p>
<p>All messages go through the router--devices do not communicate directly to each other. The message will contain information such as the destination device, the type of message, the message id, and any number of optional parameters. The router does nothing with the message but forward it to the destination device, or devices if the message is being sent to more than one. The DCE library, from which DCE Devices and the DCE Router are derived, knows how to receive incoming messages of the type command, and route them to a message handler in the DCE Device. This works in conjunction with the [[DCE Generator]] utility.</p>
<h1>DCE Generator builds a complete Linux/Windows DCE Device for you</h1>
<p>The definition of the device, including its data, commands and events is stored in a central database, described [[pluto_main database]].</p>
<h1>Next Steps</h1>
<p>This section of the documentation explains the specifics of DCE. You can also learn how to configure DCE Device definitions, called templates, [[LinuxMCE Admin Website]] using the LinuxMCE Admin web site. Under Developers/Source Code docs you will find documentation for the DCE library code.</p>
<p>[[Make a DCE Device in 5 minutes]] will show you how to make a DCE Device in 5 minutes.</p>
<p>Download the source code for the C++ DCE library using the http://LinuxMCE.com/support/index.php?package=0&section=mainDownload, or check it out from our [[Building from source]].</p>

Upcoming Features

2007-08-09T23:31:28Z

Mstovenour: Fixed typo in URL

Visit the [http://linuxmce.org/smf/index.php?board=350.0 Upcoming features forum] to discuss new features, changes or ideas. If you are willing to offer some cash or other compensation to a developer to get something done right away, visit the [http://linuxmce.org/smf/index.php?board=349.0 Help Wanted forum].

When a developer has decided to implement some new feature or change, please edit this wiki to add a brief summary including a link to the original forum topic for this new idea, so other users can post to that topic to discuss this, and where you will post updated progress info. Visit the [http://linuxmce.org/wiki/index.php/Contacts Contacts Page] to find developers who can commit your work to the main LinuxMCE branch, or to request svn write access.

This page lists the features which developers we are working to implement in the next release. There is also a forum dedicated to discussing features here . Please post to this page only those features which have been decided to be included.

Read about the long-term goals and strategy here: [[History|History of LinuxMCE, why I started this project, and the goals]]

----
== Google Summer of Code Ideas: ==

'''internet radio'''
Integrate internet radio into the existing media menu option so radio stations can be browsed the same way local media can.

'''internet tv / videos.google / youtube'''
Integrate these online video sources into the existing media menu option so this video can be browsed the same way local media can.

'''gsd events'''
The embedded Ruby interpretor presently only handles controlling devices; ie processing commands. The same code could be adapted in reverse to respond to events.

'''Standardized to be included in Ubuntu'''
LinuxMCE still has a lot of non-standard scripts that Pluto wrote for use in commercial, black-box systems, which need to be rewritten in a more standard manner so that LinuxMCE plays nicely by Ubuntu's rules and be accepted into Ubuntu's main repository and included in their build.

'''Download audio podcast/video podcast'''
A way with the GUI to subscribe to podcasts, and have them automatically downloaded and aggregated with the media in the home. Including playcount so a list of not listened to podcasts can be created.

'''Capture video from firewire camera'''
The current plug and play detection engine already recognizes firewire digital camcorders. There should be a very rudimentary, simple 'capture' option that appears on screen to do basic video capture and save it to the managed media. Users can use a video editor like Kino for real editing; this is just for quick capture.

'''Better organize and manage photos'''
The current UI could use some optimization to make it work better for managing photos.

Main Page

2007-07-14T15:35:14Z

Mstovenour:

==What is LinuxMCE?==
[http://LinuxMCE.com LinuxMCE] is the only solution seamlessly combining:
# media & entertainment with a server for music, movies and tv shows, plus a PVR and DVD Player,
# a home automation system to control everything in the home with touch-screen tablet and Bluetooth mobile phone controllers,
# a phone system with video conferencing,
# a security system that feeds you live video on your mobile phone when something happens, and lets you speak to visitors through your stereos, and
# a home PC solution.

A typical LinuxMCE system consists of a '''Core''': one PC acting as a dedicated server and interface with all the sub-components. The Core includes our own plug-and-play back-end so it listens for and auto configures all sorts of devices like network audio players (such as Squeeze Box), IP phones and cameras. The Core automatically exposes a network boot for any other PC's or thin clients you want to use as '''Media Directors''', which you hook up to your TV/Stereo's to use as set top boxes, complete with a media player, PVR, video conferencing, intercom, and a GUI to control everything in the home. All Media Directors work together seamlessly as a total whole-house solution.

In addition to the usual infrared remote controls, LinuxMCE includes remote control software that runs on Symbian Bluetooth mobile phones as well as Linux, Windows and Windows CE devices like webpads and pda's. They all feature cover art, interactive maps and floor plans, and let you control any device in the house. The UI is skinnable and multi-language. The mobile phone has a "follow-me" feature so your media and other settings follow you from room to room. It switches from Bluetooth to cellular gprs/wap when you leave the house you're always in control.

__TOC__

==News==
==Features==

LinuxMCE is an all-in-one solution for your home that seamlessly combines media & entertainment, home automation, security, telecommunications and computing. Browse the [[Features|features page]], along with [[What can I do with LinuxMCE?]] to see the possibilities available from LinuxMCE.

==Screenshots==
[[Image:MainMenu2.jpg|left|thumb|UI2 Main Menu]]
[[Image:FileBrowserUI1.jpg|left|thumb|UI1 Media Files Browser]]
[[Image:DialNumberUI1.jpg|none|thumb|UI1 Phone Dial Pad]]
-

==Download==

To get Linux MCE, please download and install Linux MCE installer from the main page of website. After this, please start the "Linux MCE Installer" application - it will download and install required packages.

==Getting Started==

This section has moved to [[Getting Started]].

==Support==

===User's Manual===

This section has moved to [[User's Manual]].

===Mailing List===

Support beyond that contained in this wiki can be found via the official LinuxMCE [http://forum.linuxmce.com/index.php forums] and through the available [http://LinuxMCE.com/support/index.php?section=mail mailing lists].

===Configuring LinuxMCE===

[[LinuxMCE Admin Website|Configuring LinuxMCE]]

[[Users_Page | Users' Documentation]]

===FAQ===
*[[What hardware I will need]]
*[[Development status for all modules]]
*[[What does an appliance solution like LinuxMCE cost?]]
*[[Is LinuxMCE an appliance or software solution?]]
*[[Do I need LinuxMCE? Can I use the projects by themselves?]]
*[[How do I login to a Linux console?]]
*[[How are media files organized?]]
*[[I can't access my media files over the network]]
*[[Reset the password for the LinuxMCE Admin site]]
*[[What if you don't have a driver for my home automation device]]
*[[What scenarios are created automatically?]]
*[[I'm a Linux user already. Should I use LinuxMCE's distribution]]
*[[Encrypted DVD's|Why doesn't LinuxMCE support encrypted DVD's?]]

===Troubleshooting===
* [[svn default properties]]
* [[Adding new computing apps]]
* [[Installing on a new platform]]
* [[Windows|Installer for Windows]]
* [[Installer Problems]]

==Development==

===Author's Information===

Information regarding author information can be found on the LinuxMCE [http://wiki.linuxmce.com/index.php/Contacts contacts] page.

===Programmer's Guide===

There is a great deal of documentation on the LinuxMCE platform available in the [[Programmer's Guide]]. This guide provides an overview of the LinuxMCE architecture,

===Software Used by LinuxMCE===

LinuxMCE is often called a platform for developing smart home modules constructed by a variety of open source projects. The integration of these open source projects, such as [http://xinehq.de Xine], [http://www.mythtv.org Mythtv], and [http://www.asterisk.org Asterisk], can be found in the LinuxMCE Software Documentation.

[[Documentation by Device Templates]]

[http://wiki.linuxmce.com/index.php/Doxygen doxygen diagrams]

LinuxMCE is an open source project and uses open source software. More information regarding LinuxMCE's relationship to open source can be found on the [[Open Source Info|open source information]] page, the [http://LinuxMCE.com/support/index.php?section=license&package=0 license information] page, what to do if you're an [http://LinuxMCE.com/index.php?section=developer open source developer], and LinuxMCE's [http://LinuxMCE.com/index.php?section=letter open source strategy].

===Report Bugs===

Bugs may be [http://www.linuxmce.com/mantis/ reported] via the bug tracking system, [http://www.mantisbugtracker.com/ Mantis].

===Source===

LinuxMCE is a pretty big project. Not counting [[GSD]] devices, LinuxMCE's own code is already well over a million lines in hundreds of modules, with over 1,000 pages of online documentation, and in addition LinuxMCE also incorporates lots of other big open source projects like Asterisk, Xine, MythTV, Firefox, VideoLan, SlimServer, etc., all of which have special LinuxMCE 'wrappers' to allow them to work together seamlessly as a total home solution. For the brave of heart, you can also download [http://LinuxMCE.com/support/index.php?section=mainDownload&package=0 modules by hand], and see all the dependencies and compatibility for each module.

You can browse the [http://linuxmce.svn.sourceforge.net/viewvc/linuxmce/trunk/ web based repository viewer]. Or you can you do an anonymous svn checkout as follows:

svn co <nowiki>http://</nowiki>linuxmce.svn.sourceforge.net/svnroot/linuxmce/trunk/''modulename''

You can checkout all the software with if you use http://linuxmce.svn.sourceforge.net/viewvc/linuxmce/trunk/ as the repository location for the module name, or go to the [http://linuxmce.svn.sourceforge.net/viewvc/linuxmce/trunk/ repository viewer] to find the name of the SVN directory for the module you are interested in.

Here are short instructions if you want compile your module with svn sources : [[Building_From_Source]].

=== Versions ===

The current version of Linux MCE is '''1.0''', as of March 15, 2007.

== Short Howto on Wiki ==

This section has been moved to [[Short Howto on Wiki]].

What hardware I will need

2007-07-14T15:26:13Z

Mstovenour:

= Hardware requirements =
== Minimum == Standard Definition (SD) DVD and audio (MP3, OGG, etc) player.
* The simple answer is a machine that can install and boot [http://www.ubuntu.com Ubuntu] (presently Edgy Eft 6.10).

== Standard == Standard Definition DVR + Audio/Video player
From the [http://www.mythtv.org/docs/mythtv-HOWTO-3.html MythTV Hardware Requirements] page.
=== CPU ===
* A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
* A developer states that his AMD1800+ system can almost encode two MPEG-4 video streams and watch one program simultaneously.
* A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
* A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.
* A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
* A video capture card supported by Linux.

=== Firewire (Optional) ===

You may use the Firewire output of the Motorola DCT6200 or the SA3250. If your provider uses 5C encryption on a particular channel, you won't be able to get any content.
DBoxII or other devices running Neutrino

You may use the Ethernet port of an DBoxII or a similar device to capture MPEG2. Your set top box has to be running the Neutrino GUI.
USB Capture Devices.

The Plextor ConvertX PVR devices are supported through Linux drivers available from http://www.plextor.com/english/support/LinuxSDK.htm. MythTV uses the Plextor to capture hardware encoded MPEG-4, so the host CPU requirements are low.

Hauppauge WinTV-PVR-USB2 (driver available at http://www.isely.net/pvrusb2/) emulates a PVR-x50 card.
IP Recorder (RTSP, RTS, UDP)

MPEG-2, MPEG-4 and H.264 internet TS stream recording is supported using the IPTV recorder in MythTV. This recorder expects the channels to be supplied as a m3u playlist. If your DSL/Fiber provider supplies television service, but does not provide a m3u playlist for the channels, you can construct one for your own use. You do not need to download it from the same server as the streams themselves, and can also read it from a file if this is more convenient.

=== Sound card ===

The system needs a sound card or an on-board equivalent on the motherboard to play back and in most cases, to record sound. Any sound card that can be operated by the ALSA (Advanced Linux Sound Architecture) kernel modules will work with MythTV. However, some cards and drivers will provide better quality or compatibility than others. In particular, many audio devices included on motherboards can be problematic.

The usual practice for capturing the audio associated with the video is to run a cable from an audio output on the video capture card to the Line input on a sound card. However, some video capture cards provide on-board audio capabilities that work with the kernel btaudio module instead, thereby eliminating the need for a cable. This is useful if you will be using multiple capture cards in a single chassis, since each capture card will not need its own sound card. Note that a separate sound card is still required for playback when using btaudio, and that often the audio recorded in this way will be mono only. See the btaudio section for more information.

== Forum Discussions ==
* [http://forum.linuxmce.com/index.php?topic=1711.0 Building a New Rig]
* [http://forum.linuxmce.com/index.php?topic=1353.msg8341#msg8341 For those wanting to roll your own box ...]

[[ Category : Hardware ]]

What hardware I will need

2007-07-14T15:02:29Z

Mstovenour:

= Hardware requirements =
== Minimum == Standard Definition (SD) DVD and audio (MP3, OGG, etc) player.
* The simple answer is a machine that can install and boot [http://www.ubuntu.com Ubuntu] (presently Edgy Eft 6.10).

== Standard == Standard Definition DVR + Audio/Video player
From the [http://www.mythtv.org/docs/mythtv-HOWTO-3.html MythTV Hardware Requirements] page.
=== CPU ===
* A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
* A developer states that his AMD1800+ system can almost encode two MPEG-4 video streams and watch one program simultaneously.
* A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
* A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.
* A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
* A video capture card supported by Linux.

=== Firewire (Optional) ===

You may use the Firewire output of the Motorola DCT6200 or the SA3250. If your provider uses 5C encryption on a particular channel, you won't be able to get any content.
DBoxII or other devices running Neutrino

You may use the Ethernet port of an DBoxII or a similar device to capture MPEG2. Your set top box has to be running the Neutrino GUI.
USB Capture Devices.

The Plextor ConvertX PVR devices are supported through Linux drivers available from http://www.plextor.com/english/support/LinuxSDK.htm. MythTV uses the Plextor to capture hardware encoded MPEG-4, so the host CPU requirements are low.

Hauppauge WinTV-PVR-USB2 (driver available at http://www.isely.net/pvrusb2/) emulates a PVR-x50 card.
IP Recorder (RTSP, RTS, UDP)

MPEG-2, MPEG-4 and H.264 internet TS stream recording is supported using the IPTV recorder in MythTV. This recorder expects the channels to be supplied as a m3u playlist. If your DSL/Fiber provider supplies television service, but does not provide a m3u playlist for the channels, you can construct one for your own use. You do not need to download it from the same server as the streams themselves, and can also read it from a file if this is more convenient.

=== Sound card ===

The system needs a sound card or an on-board equivalent on the motherboard to play back and in most cases, to record sound. Any sound card that can be operated by the ALSA (Advanced Linux Sound Architecture) kernel modules will work with MythTV. However, some cards and drivers will provide better quality or compatibility than others. In particular, many audio devices included on motherboards can be problematic.

The usual practice for capturing the audio associated with the video is to run a cable from an audio output on the video capture card to the Line input on a sound card. However, some video capture cards provide on-board audio capabilities that work with the kernel btaudio module instead, thereby eliminating the need for a cable. This is useful if you will be using multiple capture cards in a single chassis, since each capture card will not need its own sound card. Note that a separate sound card is still required for playback when using btaudio, and that often the audio recorded in this way will be mono only. See the btaudio section for more information.

== Forum Discussions ==
[http://forum.linuxmce.com/index.php?topic=1711.0 Building a New Rig]

[[ Category : Hardware ]]

What hardware I will need

2007-07-14T15:01:40Z

Mstovenour:

= Hardware requirements =
== Minimum == Standard Definition (SD) DVD and audio (MP3, OGG, etc) player.
* The simple answer is a machine that can install and boot [http://www.ubuntu.com Ubuntu] (presently Edgy Eft 6.10).

== Standard == Standard Definition DVR + Audio/Video player
From the [http://www.mythtv.org/docs/mythtv-HOWTO-3.html MythTV Hardware Requirements] page.
=== CPU ===
* A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
* A developer states that his AMD1800+ system can almost encode two MPEG-4 video streams and watch one program simultaneously.
* A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
* A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.
* A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
* A video capture card supported by Linux.

=== Firewire (Optional) ===

You may use the Firewire output of the Motorola DCT6200 or the SA3250. If your provider uses 5C encryption on a particular channel, you won't be able to get any content.
DBoxII or other devices running Neutrino

You may use the Ethernet port of an DBoxII or a similar device to capture MPEG2. Your set top box has to be running the Neutrino GUI.
USB Capture Devices.

The Plextor ConvertX PVR devices are supported through Linux drivers available from http://www.plextor.com/english/support/LinuxSDK.htm. MythTV uses the Plextor to capture hardware encoded MPEG-4, so the host CPU requirements are low.

Hauppauge WinTV-PVR-USB2 (driver available at http://www.isely.net/pvrusb2/) emulates a PVR-x50 card.
IP Recorder (RTSP, RTS, UDP)

MPEG-2, MPEG-4 and H.264 internet TS stream recording is supported using the IPTV recorder in MythTV. This recorder expects the channels to be supplied as a m3u playlist. If your DSL/Fiber provider supplies television service, but does not provide a m3u playlist for the channels, you can construct one for your own use. You do not need to download it from the same server as the streams themselves, and can also read it from a file if this is more convenient.

=== Sound card ===

The system needs a sound card or an on-board equivalent on the motherboard to play back and in most cases, to record sound. Any sound card that can be operated by the ALSA (Advanced Linux Sound Architecture) kernel modules will work with MythTV. However, some cards and drivers will provide better quality or compatibility than others. In particular, many audio devices included on motherboards can be problematic.

The usual practice for capturing the audio associated with the video is to run a cable from an audio output on the video capture card to the Line input on a sound card. However, some video capture cards provide on-board audio capabilities that work with the kernel btaudio module instead, thereby eliminating the need for a cable. This is useful if you will be using multiple capture cards in a single chassis, since each capture card will not need its own sound card. Note that a separate sound card is still required for playback when using btaudio, and that often the audio recorded in this way will be mono only. See the btaudio section for more information.

=== Forum Discussions ===
[http://forum.linuxmce.com/index.php?topic=1711.0 Building a New Rig]

[[ Category : Hardware ]]