Does the device implement DCE?

From LinuxMCE
Revision as of 16:43, 5 June 2006 by Wikiadmin (Talk | contribs) (Imported document)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
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.

On the Device Template edit page within the Pluto Admin site you can check whether or not the device will Implement DCE. If the device does implement DCE, then the DCE Generator will create a C++ class to implement this device.

The majority of devices do not "Implement DCE" because they are "dumb" devices that do not speak "DCE" directly, but are rather controlled by some other device that does. All the infrared-remote-controlled audio/video devices fall into this category. The device does not have an Ethernet connection, it does not know how to connect to the DCE Router. It is a device that will implement commands, like Stop, Play, Pause, etc., but all those commands will have to go to another DCE Device that will be responsible for processing them. In this case that device is an interface module, like the GC100. Pluto has a DCE Device driver for the GC100, and all commands for an infrared TV (like on, off, etc.) will actually go to the GC100.

When the DCE Router gets a message, it will check if the device implements DCE. If it does, then the router will send the message directly to the device. If it does not, then the router will go up the parent tree, defined by the device's "Controlled Via" pointer, until it finds a device that does implement DCE, and the message will be sent to that device. When you create a DCE Device, you will need to add some special code if your device will have children (ie other devices "Controlled Via" this device) and this device is supposed to handle the commands for the children, like the GC100 does. Otherwise, the framework will cause your DCE Device to ignore messages for its children because there is no default way to handle them.

Virtually all the device templates in the interface category have this same relationship with a parent device that implements DCE, and which has children that do not. Lighting interfaces have as children light switches, Climate interfaces have thermostates, Security panels have motion detectors and glass break sensors, and so on.