Difference between revisions of "Does the device implement DCE?"

From LinuxMCE
Jump to: navigation, search
(Imported document)
 
m (Does the device Implement DCE? moved to Does the device implement DCE?)
 
(2 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>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.</p>
+
[[Category:Programmer's Guide]]
 +
[[Category:Admin Website]]
 +
On the Device Template edit page within the [[LinuxMCE Admin Website]] 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.
  
<p>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.</p>
+
The majority of devices do not "Implement DCE" because they are "dumb" devices that do not speak to "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 DCERouter.  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.  LinuxMCE 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.
  
<p>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.</p>
+
When the [[DCERouter]] 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.
 
+
<p>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.</p>
+
  
 +
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 thermostats, Security panels have motion detectors and glass break sensors, and so on.

Latest revision as of 09:21, 14 January 2010

On the Device Template edit page within the LinuxMCE Admin Website 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 to "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 DCERouter. 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. LinuxMCE 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 DCERouter 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 thermostats, Security panels have motion detectors and glass break sensors, and so on.