Revision as of 15:30, 11 August 2007

Introduction

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.

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.

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.

Compatible Software & Hardware Platforms

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.

Plug & Play Support

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.

How do DCE Devices talk to each other?

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.

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.

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.

DCE Generator builds a complete Linux/Windows DCE Device for you

The definition of the device, including its data, commands and events is stored in a central database, described pluto_main database.

Next Steps

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.

Make a DCE Device in 5 minutes will show you how to make a DCE Device in 5 minutes.

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.