Difference between revisions of "Does the device implement DCE?"
m (Does the device Implement DCE? moved to Does the device implement DCE?) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[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. | ||
| − | + | 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. | |
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.
