Edit Device Template
This is how you define a Device Template, and specify what data it needs, and what commands and events it will implement.
The data, commands and event sections pertain to LinuxMCE Libraries DCE.
Device Template # ....
This will be used as the name of the device template.
If "Implements DCE" is checked, that means this Device Template will be able to run as a stand-alone device, connecting directly to the DCE Router to receive and process its own data, commands and events. Does the device Implement DCE? for an explanation.
The category to which these devices belong.
The company that makes these devices.
Website of forementioned manufacturer.
Internal URL sufix
Design Objects to use as remotes
Design Objects are menus that appear on the Orbiters, and here is where you specify what design objects, or menus, should be used to control this device. Design Objects
This device is controlled via
You also specify here what devices this one will be controlled via, also referred to as what devices are eligible parents. This is an "or" relationship. Any device that matches any of the categories or any of the device templates you specify will be considered a valid parent, and the user will be allowed to create a child device based on this device template. Understanding Controlled Via (aka Parent)
This device is controlled via category
Here you can also specify what package will contain this device's software. If you choose an existing package, then this device will be added to that software package the next time LinuxMCE's "MakeVersion" program is run. Typically, however, each developer will create his own package to contain his software, and only group multiple Device Templates together into a package if they logically belong together as a whole. LinuxMCE's "standard plug-in" package is an example. It contains all the standard plug-in devices since they are really inseparable and belong in the same package. Packages
If the device is an Audio/Video device, whether or not it implements DCE, you should check the box. This will enable a button allowing you to specify a variety of extra information about this device that is specific to A/V equipment, such as what inputs it uses, if it has different 'modes', settings for controlling it via infrared, etc.
Inherits MAC From PC
Is IP Based
When you specify what data parameters this device needs, try to use one of the existing data parameters in the list if there is an appropriate one. Which one you choose is unimportant so long as the type is correct (string, integer, etc.). DCE makes no differentiation between the parameters--they are just names. If this device implements DCE, then DCEGen will create member variables for setting/accessing all the data parameters for your device, and the names of the members and functions will be the same as the name on the list. Also, when the user adds an instance of this device to his system, either manually or with the wizard, he will be able to fill in a value for this parameter if you check "Allowed to Modify". If you check "Required", then some value will be required and the parameter cannot be empty. If you check "Use Device Template Default", then whatever value you put in here as the default will be used by every device. Note that if you put in a default value, do not check "Allowed to Modify", then the device will be created with the default value. However, if you later change the default value, all the devices values will not change unless you check this "Use Device Template Default" box. In that case, the device really has no local value and just uses the current default every time. If "Set by Device" is checked, then when the DCE class is generated a "set" methods will also be created so the device can set the value itself. Otherwise the data parameter is considered 'read-only' by the device and can only be changed using the LinuxMCE Admin Website.
Because most devices implement lots of commands, and similar devices will always implement similar commands, commands are put into groups and the groups are added to the device template rather than adding the commands manually. A TV, for example, can have 100 "standard" commands--like Volume Up/Down, Channel Up/Down, On/Off, Brightness Up, etc. Rather than having to add every command to every TV, a group called "Standard TV commands" can be created, and you just add the group to the TV. Command Groups use the same categories as the device template themselves. By default, you will only see here the command groups within the same category as the device template to keep the screen clean. Just check the command groups you want. However, there is a pull-down listing every single command group so you can add command groups that are not in the same category. You can also create a new command group and then specify what commands belong to that group. When you create or edit a command group you will have the option of creating/editing the commands, and there you will be able to specify what parameters that command takes.
If this device can be controlled via infrared, the infrared code for each command will need to be stored or learned. The number of different models for A/V equipment is staggering. However most manufacturers always use the same infrared codes across their whole line. For example, a Sony remote control for 1 TV will control all other Sony TV's too. So rather than requiring the user to add infrared codes for every Sony TV, we just create an infrared group "Sony TV Commands". Then you can add the DCE Command to Infrared Code commands to the group. Later when someone else adds a Device Template for another model of Sony TV, they can just specify that it uses the same Infrared Group. Note that the infrared group should therefore be a superset of all the commands--every command for every Sony TV. Some high-end models may have commands like "Wide screen" vs "Normal", which the low-end models do not support. In this case, the high-end model may have more commands than the low-end model, but all the commands should be in the infrared group. The low-end model will never use the infrared codes that it doesn't support, but at least they will be there and different infrared groups will not be required. When the manufacturer changes the infrared codes their, then a new infrared group will be required.
Whatever events this device will fire are also added here. When you create/edit an event, you can specify what parameters that event takes.