To ensure uniquness, a logical device SHOULD be identified by a universal unique identifier (UUID) as defined by RFC 4122. Consumers of logical device data need information about the transducers on the device (meta data) as well as the data values themselves. If the XMPP service is capable of handling pub-sub collections (XEP-0248: PubSub Collection Nodes), the node id for the collection node SHOULD be the UUID as defined above. The meta data for the device SHOULD be a leaf node child of the collection node with the name "meta" and the data values for the device SHOULD be a leaf node child of the collection node with the name "data".

If the XMPP service is not capable of handling pub-sub collections, the node id for the meta data SHOULD be in the form of the UUID followed by "_" followed by (what would be) the leaf child node id. Thus, for the meta data, the node id would be UUID_meta and the data value node id would be UUID_data.

For the rest of the document, we will assume that the XMPP service is a basic XEP-0060 compliant service only and use the UUID_??? naming scheme for node id.

If the meta node is configured to include payloads, the subscribers will receive payloads with event notifications:

If the data value node is configured to include payloads, the subscribers will receive payloads with event notifications:

OPTIONAL: Instead of putting all of the transducer values into a single data value node, an adapter MAY want to break up the transducer values into multiple nodes. For example, an adapter may want to do this for reasons of security (allow some entities to subscribe/publish to transducer Y1 and a different set of entities to subscribe/publish to transducer Y2).

As mentioned earlier, if the XMPP service is capable of handling pub-sub collections (XEP-0248: PubSub Collection Nodes), the node id for the collection node SHOULD be the UUID and the leaf child node SHOULD have the same node id as the transducer id listed in the meta node.

If the XMPP service is not capable of handling pub-sub collections, adapters which want to create nodes for individual transducers SHOULD use a node id of the form X_Y where X is the UUID for the device and Y is the transducer id as listed in the UUID_meta node.

If the fan node is configured to include payloads, the subscribers will receive payloads with event notifications:

If an adapter chooses to put the transducer value in its own node, it MUST indicate this in the meta node via the Transducer's hasOwnNode field.

NOTE: For every transducer listed in the UUID_meta node, the transducer value MUST be provided in either the UUID_data node or its own UUID_TransducerId node, but not both. The information in the meta node is used by consumers to determine which node they should subscribe to in order to be notified when new data is available for their chosen transducer.

If the data value node is configured to include payloads, the subscribers will receive payloads with event notifications:

Per the optional note above. If a transducer has the "hasOwnNode" attribute set in the UUID_meta node, then the value set would be done via the UUID_TransducerId node as described above.

If the fan node is configured to include payloads, the subscribers will receive payloads with event notifications:

A data logging agent does not need to create or publish any nodes. Instead, it would use the XMPP pub/sub disco# ability to list available nodes and contact the admin entity to subscribe to nodes of interest. Once subscribed, it can log events, populate an external database (such as MySQL) to allow access to historical information regarding sensors and actuators, provide external notifications based on particular events, etc. Since the mechanism for setting a transducer uses the same pubsub node as showing the transducer's value, logging style entities can also do auditing, independant validation that a device is responding, timing of acutator set/response, etc.

Lady Capulet has purchased an energy monitoring device for use in her home. The sensor used is accurate to the nearest 10 Wh.

Later, Lady Capulet adds a second energy sensor to the monitoring device purchased above. The new sensor is more accurate and can measure to the nearest 1 Wh. The adapter provides this additional information in the meta node and data value node.

Lord Montague purchases a web camera which can sense movement and has a light which can be turned on or off. He also has an agent which responds to the camera motion detector by turning on the camera light in the hopes of catching Romeo sneaking out at night. For security reasons, it is desired to allow an agent to publish to the light (i.e. control the light), but not the motion sensor. To provide for this, the adapter implements the OPTIONAL ability that allows a transducer value to have its own node.

When there is movement, the following would be published by the camera adapter.

Two things to note:

1. The tuple ('4d4335b5-4134-11e0-9207-0800200c9a66_data', 'tid1') uniquely identifies the motion sensor for this camera adapter.
2. It is not relevant to the subscriber of this node (the consumer of information) whether the camera has motion detection built in or whether the adapter is capturing images from the camera and using its own methodology for determining motion.

To continue this example further, let's assume an agent is subscribed to the data value node and can also publish to the tid2 node which controls the light. In this case, an agent will receive notification that movement was sensed and can take action. One action could be to turn on the light, in which case the agent would publish:

In response, the camera adapter would turn on the light and publish an acknowledgement.

In response to this the agent could start recording the video, send an email, use the XEP-0166 (Jingle) extension to send the video to an XMPP client, etc.

Juliet purchases a smartphone and connects it to the diagnostic bus of her chariot. She is interested in capturing real time information regarding the chariot's location and performance. The smartphone is providing some of the data (accelerometer and GPS) while the chariot diagnostic bus is providing the rest (horsepower, engine information, etc).

Note: it is not relevant to the consumers of the data which sensors are connected to the smartphone and which are not. Consumers only need to know the UUID for the chariot adapter's logical device and the corresponding transducer id's to access the specific transducer data by subscribing to the node(s) of interest. The chariot adapter (potentially running on the smart phone) hides the details of data acquisition.

Note: normally engine information is provided as rotations per minute (rpm), but the "on-wire" format should use the base units provided above - in this case hertz is a measure of cycles (or rotations) per second. Thus, the adapter would be required to convert rpm into hertz (i.e. multiply the rpm value by 60 to get hertz) before publishing and an agent could optionally convert the value back to rpm for display.

Since the timestamp indicates the time of data collection, the adapter could store some of the sensor values and then batch publish the values to the data value node. Consumers of the data value node information would get delayed results (increased latency), but this mechanism may provide for improved bandwidth (fewer pub/sub notification overhead for each "unit" of data).

NOTE: It is permissible to publish a subset of transducers in the data value node (such as in this example). If an adapter chooses to publish a subset of transducer data (for example, only the changed values), it is possible for consumers who are off line or recently activated to miss older values. There are a variety of ways to handle this depending on the needs of the implementor including (but not limited to):

• Increase the history size of the node in the xmpp server so old entries can be obtained
• Have the adapter periodicly update all values in the data value node
• Put infrequent events in their own nodes and use data value node for frequent events
• Put frequent events in their own nodes and use data value node for infrequent events

One could carry this further to allow Lord Capulet to keep track of all the chariots in his fleet. For example, the logging agent described above could be used to keep historical information (including location and performance) for all of the vehicles in his fleet. We will leave it as an exercise for the reader to ponder the implications of allowing chariot transducers to be modified on the fly via non-local agents.

Whether or not additional nodes are needed depends on how the information is combined. For example, an adapter could be written to compute the distance a vehicle is from a particular point and the result could be a published to a new node that other adapters and agents could use in their calculations.

The Data Forms shown in this specification include English-language labels for various fields; implementations that will display such forms to human users SHOULD provide localized label text for fields that are defined for the registered FORM_TYPEs.

The ®ISTRAR; includes "http://jabber.org/protocol/pubsub" and "http://jabber.org/protocol/pubsub#errors" and "http://jabber.org/protocol/pubsub#event" and "http://jabber.org/protocol/pubsub#owner" in its registry of protocol namespaces.