Difference between revisions of "DCE Libraries"

Latest revision as of 18:44, 26 October 2012

Introduction

DCE, which stands for Data, Commands and Events, is a lightweight network protocol designed for smart home communications. Devices in a DCE network use the DCE network protocol to:

• access their configuration (ie data) from a central database
• send and receive commands
• fire and respond to events

The DCE protocol's messaging is socket-based, allowing standard networking devices to interact, regardless of operating system or language. 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, including the ability to interchange all the devices, and still control them with the same remote using the same UI.

DCE uses:

• socket-based communication (which allows standard networking devices to interact)
• a database back-end to catalog all devices and serve software
• a unified interface that standardizes commands and device interactions by category

This unified interface 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.

The entire database of all devices has been made publicly available to enable developers of new devices to 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. Since the DCE is an open source project, unlike the multi-media keyboard example with one company dictating the standards, the standardization is a cooperative effort amongst all the device developers.

DCE Compatible Software & Hardware Platforms

The DCE protocol 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 MAC-address. The DCERouter does a look up 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: the Pluto main database.

What is 'pluto_main'

Virtually everything about LinuxMCE is stored in the database schema called pluto_main. The DCE definitions, the documentation, the list of software and the requirements to use it, the boot scripts, even the graphical user interface on the Orbiters is here. Most of the software modules in LinuxMCE will need this database to run. The LinuxMCE Admin Website web site is the primary front-end for the database. Use it to configure everything in your LinuxMCE system, browse your local copy of the documentation, and just about everything else. The one exception is the graphical user interface on the Orbiters. It would not be practical to build a GUI in a web, so there is a separate program, Designer, which is used to edit the GUI.

The database contains a collection of sqlCVS repositories, with tables grouped by function. All LinuxMCE systems have the same database, with the same data, except for the tables in the "local" repository. These include the Devices, Installation and Users, and their related tables. This information is only in your local copy. LinuxMCE's central database only keeps track of the ID's that have been used so that we can ensure that every device, installation and user is globally unique, allowing you to join houses, and do other things that require unique ID's. The LinuxMCE Admin web site will request a unique ID from www.linuxmce.org when you add a Device, User or Installation.

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.org/support/index.php?package=0&section=mainDownload (Broken Link), or check it out from our Building from source.