Difference between revisions of "DCE"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | < | + | {| align="right" |
| − | + | | __TOC__ | |
| + | |} | ||
| + | [[Category: Programmer's Guide]] | ||
| + | [[Category: Admin Website]] | ||
| + | DCE, which stands for '''D'''ata, '''C'''ommands and '''E'''vents, 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 | ||
| + | |||
| + | {{P}} | ||
| + | |||
| + | ===DCE routing=== | ||
| + | |||
| + | ====Role of the DCE router==== | ||
| + | An "installation" is a group of devices treated as a unit, and normally corresponds to a physical residence. In each installation, there is one DCE Router through which all messages are routed. Devices in a DCE network do not communicate directly to each other. All messages go through the router. <br> | ||
| + | Each message contains information such as the destination device, the type of message, the message id and any number of optional parameters. The router does nothing else with the message than forward it to the destination device(s). 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'''. | ||
| + | <!-- either a typo @ typed, o ??? --> | ||
| + | |||
| + | |||
| + | ====Device identification==== | ||
| + | Each device you create in your installation is assigned a mysql auto-generated ID, which is the next sequential PK_Device. This ID is the primary key for the entry in the device table (all primary keys in pluto_main are constructred by PK_<name-of-table>. <br> | ||
| + | The PK_Device device identifier is just a simple integer unique to each device, that is assigned at the initial detection of devices that do not yet have a device ID (new devices). | ||
| + | |||
| + | When a DCE device connects to the router, it reports three things: | ||
| + | # a device ID | ||
| + | # an IP address | ||
| + | # a MAC address | ||
| + | If any of these don't match what is on the server, then a BAD DEVICE is sent back, and the device can take the appropriate action. | ||
| + | |||
| + | From the standpoint of other devices, only the device ID (aka PK_Device) is used. The IP and MAC addresses are optional, since some devices are embedded within others (such as the xine player running on a media director, or a media director's onscreen orbiter). Those devices have ''Inherits address from PC'' in their device data. When a request is sent to the device for its IP address, it returs that of its parent.<br> | ||
| + | Also, some devices, such as IR devices, do not have IP addreses at all, but are children of some infrared transmitter. In the end, only PK_Device is important, and IP and MAC addresses serve as a sanity check to make sure that devices that have them are indeed using the right device ID. | ||
| + | |||
| + | |||
| + | ====DCE socket-based communications==== | ||
| + | <!-- The DCE Router is itself quite simple. It just opens a port for incoming connections. --> | ||
| + | When connecting, a device sends its unique ID to the DCERouter which uses it to perform a lookup in a database and return the data (configuration) stored for the device. DCERouter also sends a list of all the other devices in the installation, along with basic information such as the set of commands they can implement. <br> | ||
| + | The DCE Device configures itself with the data it receives, then opens a minimum of 2 socket connections to the router: | ||
| + | :* one for incoming messages from the router (usually commands) | ||
| + | :* one for outgoing messages to the router (usually events) | ||
| + | The DCE Library, which implements the protocol for DCE Devices and the DCE Router, opens another socket connection. The device ends up with 2 outgoing sockets: | ||
| + | :* one dedicated for sending events. | ||
| + | :* one for sending other types of messages, like requests and commands to other devices. | ||
| + | |||
| + | |||
| + | ;Note: Another important library is PlutoUtils. It has cross-platform wrapper classes to handle file, strings, processes, threads synchronization, database utils, etc. | ||
| + | |||
| + | {{p}} | ||
| + | |||
| + | ===DCE standard=== | ||
| + | This is primarily for programmers working on DCE devices. We strive to ensure that all similar devices use the same commands and events and to some extent data so that they are interchangeable. For example, if someone creates a remote control screen to adjust lights, he will add an 'on', 'off' and 'dim' command to the buttons. All DCE lighting devices should respond to these same basic commands in the same way so that the remote control is usable with all of them. | ||
| + | |||
| + | The DCE pages let you see all the data, commands and events that devices use, how they are organized into categories, and what devices use them. | ||
| + | {{p}} | ||
| + | |||
| + | ====Developing a DCE Device==== | ||
| + | '''A new tutorial for [[Developing a DCE Device]] is available. This focuses on developing a device using C++ and the DCE and PlutoUtils libraries.. A new GSD tutorial for Ruby is forthcoming.''' | ||
| + | |||
| + | {{p}} | ||
| + | |||
| + | ===DCE Reference=== | ||
| + | * [[Device Data]] | ||
| + | * [[Commands]] | ||
| + | * [[Events]] | ||
| + | |||
| + | {{p}} | ||
Latest revision as of 18:48, 26 October 2012
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
DCE routing
Role of the DCE router
An "installation" is a group of devices treated as a unit, and normally corresponds to a physical residence. In each installation, there is one DCE Router through which all messages are routed. Devices in a DCE network do not communicate directly to each other. All messages go through the router.
Each message contains information such as the destination device, the type of message, the message id and any number of optional parameters. The router does nothing else with the message than forward it to the destination device(s). The DCE library (from which DCE Devices and the DCE Router are derived) knows how to receive incoming messages and route them to a message handler in the DCE Device.
Device identification
Each device you create in your installation is assigned a mysql auto-generated ID, which is the next sequential PK_Device. This ID is the primary key for the entry in the device table (all primary keys in pluto_main are constructred by PK_<name-of-table>.
The PK_Device device identifier is just a simple integer unique to each device, that is assigned at the initial detection of devices that do not yet have a device ID (new devices).
When a DCE device connects to the router, it reports three things:
- a device ID
- an IP address
- a MAC address
If any of these don't match what is on the server, then a BAD DEVICE is sent back, and the device can take the appropriate action.
From the standpoint of other devices, only the device ID (aka PK_Device) is used. The IP and MAC addresses are optional, since some devices are embedded within others (such as the xine player running on a media director, or a media director's onscreen orbiter). Those devices have Inherits address from PC in their device data. When a request is sent to the device for its IP address, it returs that of its parent.
Also, some devices, such as IR devices, do not have IP addreses at all, but are children of some infrared transmitter. In the end, only PK_Device is important, and IP and MAC addresses serve as a sanity check to make sure that devices that have them are indeed using the right device ID.
DCE socket-based communications
When connecting, a device sends its unique ID to the DCERouter which uses it to perform a lookup in a database and return the data (configuration) stored for the device. DCERouter also sends a list of all the other devices in the installation, along with basic information such as the set of commands they can implement.
The DCE Device configures itself with the data it receives, then opens a minimum of 2 socket connections to the router:
- one for incoming messages from the router (usually commands)
- one for outgoing messages to the router (usually events)
The DCE Library, which implements the protocol for DCE Devices and the DCE Router, opens another socket connection. The device ends up with 2 outgoing sockets:
- one dedicated for sending events.
- one for sending other types of messages, like requests and commands to other devices.
- Note
- Another important library is PlutoUtils. It has cross-platform wrapper classes to handle file, strings, processes, threads synchronization, database utils, etc.
DCE standard
This is primarily for programmers working on DCE devices. We strive to ensure that all similar devices use the same commands and events and to some extent data so that they are interchangeable. For example, if someone creates a remote control screen to adjust lights, he will add an 'on', 'off' and 'dim' command to the buttons. All DCE lighting devices should respond to these same basic commands in the same way so that the remote control is usable with all of them.
The DCE pages let you see all the data, commands and events that devices use, how they are organized into categories, and what devices use them.
Developing a DCE Device
A new tutorial for Developing a DCE Device is available. This focuses on developing a device using C++ and the DCE and PlutoUtils libraries.. A new GSD tutorial for Ruby is forthcoming.
DCE Reference
