mirror of
https://github.com/moparisthebest/xeps
synced 2025-02-07 02:40:22 -05:00
XEP-0325 v0.2: Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic; Corrected the namespace used for parameterGroup elements in the examples of the document; Added support for color values with alpha channel; Updated the schema to more strictly validate references to x-data forms; Schema was updated to reflect the correct relationship between the x-data subelement in a set operation; Fixed links to documents with new numbers; Changed namespace urn:xmpp:sn to urn:xmpp:iot; Schema was corrected: The parameter sub-element in the setResponse element was removed
This commit is contained in:
Matthew A. Miller
parent
4eb67d7f69
commit
0cbb77aaf8
402
xep-0325.xml
402
xep-0325.xml
@ -1,4 +1,5 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!-- TODO: SImple readout: Only control form - no XEP-0323 -->
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
@ -8,7 +9,7 @@
|
||||
<header>
|
||||
<title>Internet of Things - Control</title>
|
||||
<abstract>This specification describes how to control devices or actuators in an XMPP-based sensor network.</abstract>
|
||||
&LEGALNOTICE;
|
||||
&LEGALNOTICE;
|
||||
<number>0325</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
@ -23,29 +24,46 @@
|
||||
<spec>XEP-0141</spec>
|
||||
<spec>XEP-0323</spec>
|
||||
<spec>XEP-0324</spec>
|
||||
<spec>xep-0000-DynamicForms</spec>
|
||||
<spec>xep-0000-ColorParameter</spec>
|
||||
</dependencies>
|
||||
<spec>XEP-0331</spec>
|
||||
<spec>XEP-0336</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
<shortname>sensor-network-control</shortname>
|
||||
<author>
|
||||
<firstname>Peter</firstname>
|
||||
<surname>Waher</surname>
|
||||
<email>peter.waher@clayster.com</email>
|
||||
<jid>peter.waher@jabber.org</jid>
|
||||
<uri>http://se.linkedin.com/pub/peter-waher/1a/71b/a29/</uri>
|
||||
<uri>http://www.linkedin.com/in/peterwaher</uri>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2013-05-06</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revision>
|
||||
<version>0.2</version>
|
||||
<date>2014-03-10</date>
|
||||
<initials>pw</initials>
|
||||
<remark>
|
||||
<p>Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.</p>
|
||||
<p>Corrected the namespace used for parameterGroup elements in the examples of the document.</p>
|
||||
<p>Added support for color values with alpha channel.</p>
|
||||
<p>Updated the schema to more strictly validate references to x-data forms.</p>
|
||||
<p>Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.</p>
|
||||
<p>Fixed links to documents with new numbers.</p>
|
||||
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot</p>
|
||||
<p>Schema was corrected: The parameter sub-element in the setResponse element was removed.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2013-05-06</date>
|
||||
<initials>psa</initials>
|
||||
<remark>
|
||||
<p>Initial published version approved by the XMPP Council.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2013-03-27</date>
|
||||
<initials>pwa</initials>
|
||||
<initials>pw</initials>
|
||||
<remark>
|
||||
<p>First draft.</p>
|
||||
</remark>
|
||||
@ -70,64 +88,68 @@
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0000-ColorParameter</td>
|
||||
<td>Defines extensions for how color parameters can be handled, based on &xep0004;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0000-DynamicForms</td>
|
||||
<td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>exi</td>
|
||||
<td>
|
||||
Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered
|
||||
in all sensor network implementations where memory and packet size is an issue.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-BatteryPoweredSensors</td>
|
||||
<td>xep-0000-IoT-BatteryPoweredSensors</td>
|
||||
<td>Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Concentrators</td>
|
||||
<td>Defines how to handle architectures containing concentrators or servers handling multiple sensors.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Control</td>
|
||||
<td>This specification. Defines how to control actuators and other devices in sensor networks.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Discovery</td>
|
||||
<td>xep-0000-IoT-Discovery</td>
|
||||
<td>Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Events</td>
|
||||
<td>xep-0000-IoT-Events</td>
|
||||
<td>Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Interoperability</td>
|
||||
<td>xep-0000-IoT-Interoperability</td>
|
||||
<td>Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-Multicast</td>
|
||||
<td>xep-0000-IoT-Multicast</td>
|
||||
<td>Defines how sensor data can be multicast in efficient ways.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sensor-network-provisioning</td>
|
||||
<td>Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xep-0000-SN-PubSub</td>
|
||||
<td>xep-0000-IoT-PubSub</td>
|
||||
<td>Defines how efficient publication of sensor data can be made in sensor networks.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sensor-data</td>
|
||||
<tr>
|
||||
<td>xep-0000-IoT-Chat</td>
|
||||
<td>Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0322</td>
|
||||
<td>
|
||||
Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered
|
||||
in all sensor network implementations where memory and packet size is an issue.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0323</td>
|
||||
<td>
|
||||
Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks.
|
||||
It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other sensor network XEPs.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<tr>
|
||||
<td>XEP-0324</td>
|
||||
<td>Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0325</td>
|
||||
<td>This specification. Defines how to control actuators and other devices in Internet of Things.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0326</td>
|
||||
<td>Defines how to handle architectures containing concentrators or servers handling multiple sensors.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0331</td>
|
||||
<td>Defines extensions for how color parameters can be handled, based on &xep0004;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XEP-0336</td>
|
||||
<td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<p>The following table lists common terms and corresponding descriptions.</p>
|
||||
@ -182,22 +204,22 @@
|
||||
<di>
|
||||
<dt>Node</dt>
|
||||
<dd>
|
||||
Graphs contain nodes and edges between nodes. In Sensor Networks, sensors, actuators, meters, devices, gatewats, etc., are often depicted as nodes and links between sensors (friendships)
|
||||
are depicted as edges. In abstract terms, it's easier to talk about a Node, than have to list different types of nodes possible (sensors, actuators, meters, devices, gateways, etc.).
|
||||
Each Node has a Node ID.
|
||||
</dd>
|
||||
Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gatewats, etc., are often depicted as nodes whereas links between sensors (friendships)
|
||||
are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
|
||||
Each Node has a Node ID.
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Node ID</dt>
|
||||
<dd>
|
||||
An ID uniquelly identifying a node within its corresponding context. If a globally unique ID is desired, an architechture should be used using a universally accepted
|
||||
An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
|
||||
ID scheme.
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Parameter</dt>
|
||||
<dd>
|
||||
Readable and/or writable property on a node/device. The XEP xep-0000-SN-Concentrators deals with reading and writing parameters
|
||||
Readable and/or writable property on a node/device. The XEP-0326 &xep0326; deals with reading and writing parameters
|
||||
on nodes/devices. Fields are not parameters, and parameters are not fields.
|
||||
</dd>
|
||||
</di>
|
||||
@ -235,7 +257,7 @@
|
||||
<di>
|
||||
<dt>Token</dt>
|
||||
<dd>
|
||||
A client, device or user can get a token from a provisioning server. These tokens can be included in requeests to other entities in the network, so these entities can validate
|
||||
A client, device or user can get a token from a provisioning server. These tokens can be included in requests to other entities in the network, so these entities can validate
|
||||
access rights with the provisioning server.
|
||||
</dd>
|
||||
</di>
|
||||
@ -282,14 +304,12 @@
|
||||
<p>
|
||||
What type of control parameters there are available in different types of devices is described in
|
||||
<note>
|
||||
XEP-xxxx: Sensor Networks - Interoperability <<link url='xep-0000-SN-Interoperability.html'>xep-0000-SN-Interoperability.html</link>>
|
||||
XEP-xxxx: Internet of Things - Interoperability <<link url='xep-0000-IoT-Interoperability.html'>xep-0000-IoT-Interoperability.html</link>>
|
||||
</note>.
|
||||
</p>
|
||||
<p>
|
||||
If the device is a concentrator, as defined in
|
||||
<note>
|
||||
XEP-xxxx: Sensor Networks - Concentrators <<link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>>
|
||||
</note>, an handles multiple nodes behind it, which node(s) to control is defined using <strong>node</strong> elements. If not a concentrator,
|
||||
If the device is a concentrator, as defined in <link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>,
|
||||
an handles multiple nodes behind it, which node(s) to control is defined using <strong>node</strong> elements. If not a concentrator,
|
||||
the use of <strong>node</strong> elements is not necessary, and control commands are sent directly to the device itself.
|
||||
</p>
|
||||
<section2 topic='Control commands'>
|
||||
@ -301,7 +321,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='digital.output@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<boolean name='Output' value='true'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -321,7 +341,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='digital.output@clayster.com'
|
||||
id='1'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<boolean name='Output' value='true'/>
|
||||
</set>
|
||||
</iq>
|
||||
@ -330,7 +350,7 @@
|
||||
from='digital.output@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='1'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OK'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
@ -348,7 +368,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='analog.output@clayster.com'
|
||||
id='2'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<boolean name='Output' value='true'/>
|
||||
</set>
|
||||
</iq>
|
||||
@ -357,7 +377,7 @@
|
||||
from='analog.output@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='2'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='OtherError'>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OtherError'>
|
||||
<error var='Output'>Invalid parameter type.</error>
|
||||
</setResponse>
|
||||
</iq>]]>
|
||||
@ -377,7 +397,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='digital.output@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<boolean name='Output' value='true'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -392,7 +412,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='analog.output@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<int name='Output' value='50000'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -408,7 +428,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='megaprecision.analog.output@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<long name='Output' value='500000000000000'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -423,7 +443,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='text.display@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<string name='Row1' value='Temperature: 21.4 °C'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -438,7 +458,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='analog.output2@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<double name='4-20mA' value='8.192'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -453,7 +473,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='alarm@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<date name='TariffStartDate' value='2013-05-01'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -468,7 +488,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='alarm@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<time name='Alarm Time' value='08:00:00'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -483,24 +503,9 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='alarm@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<dateTime name='Alarm Time' value='2013-04-02T08:00:00'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section3>
|
||||
<section3 topic='Setting a single time-valued control parameter'>
|
||||
<p>
|
||||
Setting time-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context.
|
||||
The following example shows how a time value can be set in a device.
|
||||
</p>
|
||||
<example caption='Setting a single time-valued control parameter'>
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='alarm@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<time name='Alarm Time' value='08:00:00'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
</example>
|
||||
</section3>
|
||||
@ -513,7 +518,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='alarm@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<duration name='Alarm Duration' value='PT3M30S'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -528,7 +533,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='spotlight@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<color name='Color' value='3399FF'/>
|
||||
</set>
|
||||
</message>]]>
|
||||
@ -543,7 +548,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='dimmer@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<int name='FadeTimeMilliseconds' value='500'/>
|
||||
<int name='OutputPercent' value='10'/>
|
||||
</set>
|
||||
@ -557,7 +562,7 @@
|
||||
</p>
|
||||
<p>
|
||||
The order of control parameters to use depends on the device. The <link url='#controlform'>Control Form</link> lists available control parameters of the device in the
|
||||
order they are expected to be sent to the device. The XEP <link url='xep-0000-SN-Interoperability.html'>xep-0000-SN-Interoperability</link> details what control parameters
|
||||
order they are expected to be sent to the device. The XEP <link url='xep-0000-IoT-Interoperability.html'>xep-0000-IoT-Interoperability</link> details what control parameters
|
||||
must be available for different interfaces, and if the order of control parameters is important.
|
||||
</p>
|
||||
</section3>
|
||||
@ -574,19 +579,19 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='dimmer@clayster.com'
|
||||
id='3'>
|
||||
<getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
|
||||
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='dimmer@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='3'>
|
||||
<getFormResponse xmlns='urn:xmpp:sn:concentrators' result='OK'>
|
||||
<getFormResponse xmlns='urn:xmpp:iot:control' result='OK'>
|
||||
<x type='form'
|
||||
xmlns='jabber:x:data'
|
||||
xmlns:xdv='http://jabber.org/protocol/xdata-validate'
|
||||
xmlns:xdl:='http://jabber.org/protocol/xdata-layout'
|
||||
xmlns:xdd:='http://jabber.org/protocol/xdata-dynamic'>
|
||||
xmlns:xdd:='urn:xmpp:xdata:dynamic'>
|
||||
<title>Dimmer</title>
|
||||
<xdl:page label='Output'>
|
||||
<xdl:fieldref var='FaceTimeMilliseconds'/>
|
||||
@ -624,7 +629,7 @@
|
||||
<p>
|
||||
<strong>IMPORTANT:</strong> The device MUST mark all control parameters in the form as <strong>notSame</strong>, as defined in
|
||||
<note>
|
||||
XEP-xxxx: Dynamic Data Forms <<link url='xep-0000-DynamicForms.html'>xep-0000-DynamicForms.html</link>>
|
||||
XEP-0336: Dynamic Data Forms <<link url='http://xmpp.org/extensions/xep-0336.html'>http://xmpp.org/extensions/xep-0336.html</link>>
|
||||
</note>. If an end user would open the control form and press OK (submitting the form) without having entered a value, no value
|
||||
would be written, and no action taken. If only a few parameter would be edited, only those parameters would be sent to the device
|
||||
and only the corresponding actions taken.
|
||||
@ -640,7 +645,8 @@
|
||||
MUST also be ordered in a way so that when set in that order using the typed commands, the corresponding control actions can be successfully executed.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> There's a difference between node parameters, as described in XEP <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators</link>,
|
||||
<strong>Note:</strong> There's a difference between node parameters, as described in XEP-0326
|
||||
<link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>,
|
||||
and control parameters as described in this document. For more information about this, please see
|
||||
<link url='#nodeparamsvscontrolparams'>Difference between node parameters and node control parameters</link>.
|
||||
</p>
|
||||
@ -648,7 +654,7 @@
|
||||
<section3 topic='Getting a control form, Failure'>
|
||||
<p>
|
||||
A device can reject a control form request. It does this returning an <strong>error</strong> iq stanza, and detailing the error in the <strong>result</strong>
|
||||
attribute of the <strong>getformResponse</strong> element, as is shown in the following example:
|
||||
attribute of the <strong>getFormResponse</strong> element, as is shown in the following example:
|
||||
</p>
|
||||
<example caption='Getting a control form, Failure'>
|
||||
<![CDATA[
|
||||
@ -656,14 +662,14 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='dimmer@clayster.com'
|
||||
id='4'>
|
||||
<getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
|
||||
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
|
||||
</iq>
|
||||
|
||||
<iq type='error'
|
||||
from='dimmer@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='4'>
|
||||
<getFormResponse xmlns='urn:xmpp:sn:concentrators' result='InsufficientPrivileges'/>
|
||||
<getFormResponse xmlns='urn:xmpp:iot:control' result='InsufficientPrivileges'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
</section3>
|
||||
@ -681,7 +687,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='dimmer@clayster.com'
|
||||
id='5'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<x type='submit' xmlns='jabber:x:data'>
|
||||
<field var='xdd session' type='hidden'>
|
||||
<value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
|
||||
@ -700,7 +706,7 @@
|
||||
from='dimmer@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='5'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OK'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
@ -720,7 +726,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='dimmer@clayster.com'
|
||||
id='6'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<x type='submit' xmlns='jabber:x:data'>
|
||||
<field var='xdd session' type='hidden'>
|
||||
<value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
|
||||
@ -739,7 +745,7 @@
|
||||
from='dimmer@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='6'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='FormError'>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='FormError'>
|
||||
<error var='OutputPercent'>Invalid parameter value.</error>
|
||||
</setResponse>
|
||||
</iq>]]>
|
||||
@ -760,7 +766,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<boolean name='Output' value='false'/>
|
||||
</set>
|
||||
@ -776,7 +782,7 @@
|
||||
<![CDATA[
|
||||
<message from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'>
|
||||
<set xmlns='urn:xmpp:sn:control'>
|
||||
<set xmlns='urn:xmpp:iot:control'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -799,7 +805,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'
|
||||
id='7'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -816,7 +822,7 @@
|
||||
from='concentrator@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='7'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='OtherError'>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OtherError'>
|
||||
<error var='Output'>Invalid parameter type.</error>
|
||||
</setResponse>
|
||||
</iq>]]>
|
||||
@ -833,7 +839,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'
|
||||
id='8'>
|
||||
<getForm xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -845,12 +851,12 @@
|
||||
from='concentrator@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='8'>
|
||||
<getFormResponse xmlns='urn:xmpp:sn:concentrators' result='OK'>
|
||||
<getFormResponse xmlns='urn:xmpp:iot:control' result='OK'>
|
||||
<x type='form'
|
||||
xmlns='jabber:x:data'
|
||||
xmlns:xdv='http://jabber.org/protocol/xdata-validate'
|
||||
xmlns:xdl:='http://jabber.org/protocol/xdata-layout'
|
||||
xmlns:xdd:='http://jabber.org/protocol/xdata-dynamic'>
|
||||
xmlns:xdd:='urn:xmpp:xdata:dynamic'>
|
||||
<title>DigitalOutput1, DigitalOutput2, ...</title>
|
||||
<xdl:page label='Output'>
|
||||
<xdl:fieldref var='Output'/>
|
||||
@ -869,13 +875,13 @@
|
||||
</example>
|
||||
<p>
|
||||
Note that only parameters that are common between the nodes defined in the request must be returned. However, all parameters must have the
|
||||
<strong>>notSame</strong> flag set, regardless of current output status.
|
||||
<strong>notSame</strong> flag set, regardless of current output status.
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Getting a control form from multiple nodes, Failure'>
|
||||
<p>
|
||||
A device can reject a control form request. It does this returning an <strong>error</strong> iq stanza, and detailing the error in the <strong>result</strong>
|
||||
attribute of the <strong>getformResponse</strong> element. The following example shows the device rejecting a control form request, because it does not support
|
||||
attribute of the <strong>getFormResponse</strong> element. The following example shows the device rejecting a control form request, because it does not support
|
||||
the handling of common parameters between multiple nodes:
|
||||
</p>
|
||||
<example caption='Getting a control form from multiple nodes, Failure'>
|
||||
@ -884,7 +890,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'
|
||||
id='9'>
|
||||
<getForm xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -896,7 +902,7 @@
|
||||
from='concentrator@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='9'>
|
||||
<getFormResponse xmlns='urn:xmpp:sn:concentrators' result='NotImplemented'/>
|
||||
<getFormResponse xmlns='urn:xmpp:iot:control' result='NotImplemented'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
</section3>
|
||||
@ -911,7 +917,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'
|
||||
id='10'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -931,7 +937,7 @@
|
||||
from='concentrator@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='10'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='OK'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
</section3>
|
||||
@ -947,7 +953,7 @@
|
||||
from='master@clayster.com/amr'
|
||||
to='concentrator@clayster.com'
|
||||
id='11'>
|
||||
<set xmlns='urn:xmpp:sn:control' xml:lang='en'>
|
||||
<set xmlns='urn:xmpp:iot:control' xml:lang='en'>
|
||||
<node nodeId='DigitalOutput1'/>
|
||||
<node nodeId='DigitalOutput2'/>
|
||||
<node nodeId='DigitalOutput3'/>
|
||||
@ -971,7 +977,7 @@
|
||||
from='concentrator@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='11'>
|
||||
<setResponse xmlns='urn:xmpp:sn:control' responseCode='FormError'>
|
||||
<setResponse xmlns='urn:xmpp:iot:control' responseCode='FormError'>
|
||||
<error var='Output'>Invalid type</error>
|
||||
</setResponse>
|
||||
</iq>]]>
|
||||
@ -979,14 +985,40 @@
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section1 topic='Determining Support' anchor='support'>
|
||||
<p>If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:iot:control" in response to &xep0030; information requests.</p>
|
||||
<example caption="Service discovery information request">
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
from='device@clayster.com/device'
|
||||
to='provisioning@clayster.com'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Service discovery information response">
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='provisioning@clayster.com'
|
||||
to='device@clayster.com/device'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:iot:control'/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
|
||||
in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='Reading current control states'>
|
||||
<p>
|
||||
If a client wants to know the current status of control parameters, it must perform a readout of <strong>Momentary</strong> and <strong>Status</strong> values
|
||||
from the device, according to
|
||||
<note>
|
||||
XEP-xxxx: Sensor Data <<link url='sensor-data.html'>sensor-data.html</link>>
|
||||
</note>, and from the returned set of values take the current control parameter value according to the following rules, ordered by priority:
|
||||
from the device, according to &xep0323;, and from the returned set of values take the current control parameter value according to the following rules, ordered by priority:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
@ -1035,7 +1067,7 @@
|
||||
<tr>
|
||||
<th>color</th>
|
||||
<td>N/A</td>
|
||||
<td>RRGGBB</td>
|
||||
<td>RRGGBB or RRGGBBAA</td>
|
||||
<td>N/A</td>
|
||||
<td>N/A</td>
|
||||
<td>N/A</td>
|
||||
@ -1197,7 +1229,11 @@
|
||||
<td>RRGGBB</td>
|
||||
<td>A string of six hexadecimal characters, the first two the red component of the color, the next two the green component and the last two the blue component.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<tr>
|
||||
<td>RRGGBBAA</td>
|
||||
<td>A string of eight hexadecimal characters, the first two the red component of the color, the next two the green component, the following two the blue component and the last two the alpha channel.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Date part</td>
|
||||
<td>Only the date part of the xs:dateTime value should be used.</td>
|
||||
</tr>
|
||||
@ -1225,11 +1261,11 @@
|
||||
</section2>
|
||||
<section2 topic='Difference between node parameters and node control parameters' anchor='nodeparamsvscontrolparams'>
|
||||
<p>
|
||||
A node defined in a concentrator, as defined by <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>, supporting control has
|
||||
A node defined in a concentrator, as defined by <link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>, supporting control has
|
||||
two sets of parameters that are different: First a set of node parameters and then a set of control parameters.
|
||||
</p>
|
||||
<p>
|
||||
Node parameters are defined by the node type in the concentrator, as described in <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>,
|
||||
Node parameters are defined by the node type in the concentrator, as described in <link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>,
|
||||
and they are typically used by the concentrator to define the node and how to communicate or interact with the underlying device. The important part here is to know
|
||||
that the node parameters are maintained by the concentrator, not the underlying device.
|
||||
</p>
|
||||
@ -1240,8 +1276,8 @@
|
||||
</section2>
|
||||
<section2 topic='Grouping control parameters' anchor='parametergroups'>
|
||||
<p>
|
||||
Many control actions avilable in a device can be controlled using only one control parameter. If a device only publishes such control parameters, the order
|
||||
of control paramters is not that important.
|
||||
Many control actions available in a device can be controlled using only one control parameter. If a device only publishes such control parameters, the order
|
||||
of control parameters is not that important.
|
||||
</p>
|
||||
<p>
|
||||
However, there are many control actions that require the client to set multiple control parameters at the same time, for the device to have a complete understanding
|
||||
@ -1287,27 +1323,34 @@
|
||||
<p>
|
||||
To solve the problem of grouping parameters together, so a client can know which parameters belong together, a new element is defined that can be used in
|
||||
data forms: <strong>parameterGroup</strong>. It is optional, but can be added to control parameters in forms, as a way to tell the client that parameters
|
||||
having the same <strong>parameterGroup</strong> belong together and should be written together. The following example illustrates this.
|
||||
having the same <strong>parameterGroup</strong> belong together and should be written together.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> If used, the server must not include a parameter in more than one parameter group at a time. The form may contain multiple group, but each
|
||||
parameter must only have at most one <strong>parameterGroup</strong> element.
|
||||
</p>
|
||||
<p>
|
||||
The following example illustrates the use of the <strong>parameterGroup</strong> element to group parameters together.
|
||||
</p>
|
||||
<example caption='Grouping control parameters'>
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
from='master@clayster.com/amr'
|
||||
to='spotlight@clayster.com'
|
||||
id='12'>
|
||||
<getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
|
||||
<getForm xmlns='urn:xmpp:iot:control' xml:lang='en'/>
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='spotlight@clayster.com'
|
||||
to='master@clayster.com/amr'
|
||||
id='12'>
|
||||
<getFormResponse xmlns='urn:xmpp:sn:concentrators' result='OK'>
|
||||
<getFormResponse xmlns='urn:xmpp:iot:control' result='OK'>
|
||||
<x type='form'
|
||||
xmlns='jabber:x:data'
|
||||
xmlns:xdv='http://jabber.org/protocol/xdata-validate'
|
||||
xmlns:xdl:='http://jabber.org/protocol/xdata-layout'
|
||||
xmlns:xdd:='http://jabber.org/protocol/xdata-dynamic'>
|
||||
xmlns:xdd:='urn:xmpp:xdata:dynamic'>
|
||||
<title>Spotlight</title>
|
||||
<xdl:page label='Output'>
|
||||
<xdl:fieldref var='MainSwitch'/>
|
||||
@ -1331,7 +1374,7 @@
|
||||
<xdv:range min='-180' max='180'/>
|
||||
</xdv:validate>
|
||||
<xdd:notSame/>
|
||||
<parameterGroup xmlns='urn:xmpp:sn:concentrators' name='direction'/>
|
||||
<parameterGroup xmlns='urn:xmpp:iot:control' name='direction'/>
|
||||
</field>
|
||||
<field var='ElevationAngle' type='text-single' label='Elevation angle:'>
|
||||
<desc>Elevation angle of the spotlight.</desc>
|
||||
@ -1340,7 +1383,7 @@
|
||||
<xdv:range min='-90' max='90'/>
|
||||
</xdv:validate>
|
||||
<xdd:notSame/>
|
||||
<parameterGroup xmlns='urn:xmpp:sn:concentrators' name='direction'/>
|
||||
<parameterGroup xmlns='urn:xmpp:iot:control' name='direction'/>
|
||||
</field>
|
||||
</x>
|
||||
</getFormResponse>
|
||||
@ -1351,13 +1394,13 @@
|
||||
(named direction).
|
||||
</p>
|
||||
<p>
|
||||
For more information about common control actions and their parameters, see <link url='xep-0000-SN-Interoperability.html'>xep-0000-SN-Interoperability.html</link>,
|
||||
For more information about common control actions and their parameters, see <link url='xep-0000-IoT-Interoperability.html'>xep-0000-IoT-Interoperability.html</link>,
|
||||
which defines a set of interoperable interfaces and their abilities.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Node commands vs. control parameters'>
|
||||
<p>
|
||||
Nodes behind a concentrator, as defined in <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>, have an additional means of
|
||||
Nodes behind a concentrator, as defined in <link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>, have an additional means of
|
||||
publishing control interfaces: Node Commands.
|
||||
</p>
|
||||
<p>
|
||||
@ -1404,10 +1447,8 @@
|
||||
</section2>
|
||||
<section2 topic='Tokens'>
|
||||
<p>
|
||||
If control interaction is performed in a context of delegated trust, as defined in the Sensor Network Provisioning XEP
|
||||
<note>
|
||||
XEP-xxxx: Sensor Networks - Provisioning <<link url='sensor-network-provisioning.html'>sensor-network-provisioning.html</link>>
|
||||
</note>, tokens should always be included in all calls. This to allow devices to check privileges with provisioning servers.
|
||||
If control interaction is performed in a context of delegated trust, as defined in the Sensor Network Provisioning XEP-0324 &xep0324;,
|
||||
tokens should always be included in all calls. This to allow devices to check privileges with provisioning servers.
|
||||
</p>
|
||||
<p>
|
||||
The <strong>set</strong> and <strong>getForm</strong> commands support the following token attributes:
|
||||
@ -1424,19 +1465,20 @@
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
For more information about provisioning, see <link url='sensor-network-provisioning.html'>sensor-network-provisioning.html</link>.
|
||||
For more information about provisioning, see <link url='http://xmpp.org/extensions/xep-0324.html'>Internet of Things - Provisioning</link>.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Controlling devices in large subsystems'>
|
||||
<p>
|
||||
Most examples in this document have been simplified examples where a few devices containing a few control parameters have been used. However, in many cases large subsystems with
|
||||
very many actuators containing many different control actions have to be controlled, as is documented in <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>.
|
||||
Most examples in this document have been simplified examples where a few devices containing a few control parameters have been used. However, in many cases large subsystems with
|
||||
very many actuators containing many different control actions have to be controlled, as is documented in
|
||||
<link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>.
|
||||
In such cases, a node may have to be specified using two or perhaps even three ID's: a <strong>sourceId</strong> identifying the data source controlling the device, a possible
|
||||
<strong>cacheType</strong> narrowing down the search to a specific kind of node, and the common <strong>nodeId</strong>. For more information about this, see
|
||||
<link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>.
|
||||
<link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note:</strong> For cases where the <strong>nodeId</strong> is sufficient to uniquelly identify the node, it is sufficient to provide this attribute in the request.
|
||||
<strong>Note:</strong> For cases where the <strong>nodeId</strong> is sufficient to uniquely identify the node, it is sufficient to provide this attribute in the request.
|
||||
If there is ambiguity in the request, the receptor must treat the request as a request with a set of nodes, all with the corresponding <strong>nodeId</strong> as requested.
|
||||
</p>
|
||||
</section2>
|
||||
@ -1485,7 +1527,7 @@
|
||||
If using delegated trust, make sure the provisioning servers are properly authenticated and validated before trusting them.
|
||||
</p>
|
||||
<p>
|
||||
More information about provisioning can be found in <link url='sensor-network-provisioning.html'>sensor-network-provisioning.html</link>.
|
||||
More information about provisioning can be found in <link url='http://xmpp.org/extensions/xep-0324.html'>Internet of Things - Provisioning</link>.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
@ -1493,24 +1535,25 @@
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>REQUIRED.</p>
|
||||
<!-- TODO -->
|
||||
</section1>
|
||||
<p>
|
||||
The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code>
|
||||
<![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:sn:control'
|
||||
xmlns='urn:xmpp:sn:control'
|
||||
xmlns:sn='urn:xmpp:sn'
|
||||
targetNamespace='urn:xmpp:iot:control'
|
||||
xmlns='urn:xmpp:iot:control'
|
||||
xmlns:sn='urn:xmpp:iot:sensordata'
|
||||
xmlns:xd="jabber:x:data"
|
||||
xmlns:xdv="http://jabber.org/protocol/xdata-validate"
|
||||
xmlns:xdl="http://jabber.org/protocol/xdata-layout"
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:import namespace='urn:xmpp:sn'/>
|
||||
<xs:import namespace='urn:xmpp:iot:sensordata'/>
|
||||
<xs:import namespace='jabber:x:data'/>
|
||||
<xs:import namespace='http://jabber.org/protocol/xdata-validate'/>
|
||||
<xs:import namespace='http://jabber.org/protocol/xdata-layout'/>
|
||||
@ -1529,13 +1572,7 @@
|
||||
<xs:element name='long' type='LongParameter'/>
|
||||
<xs:element name='string' type='StringParameter'/>
|
||||
<xs:element name='time' type='TimeParameter'/>
|
||||
<xs:element name='form'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
<xs:any minOccurs="1" maxOccurs="1" namespace="jabber:x:data"/>
|
||||
</xs:sequence>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
<xs:element ref='xd:x'/>
|
||||
</xs:choice>
|
||||
<xs:attributeGroup ref='tokens'/>
|
||||
</xs:complexType>
|
||||
@ -1545,11 +1582,6 @@
|
||||
<xs:complexType>
|
||||
<xs:choice minOccurs='0' maxOccurs='unbounded'>
|
||||
<xs:element name='node' type='NodeReference'/>
|
||||
<xs:element name='parameter'>
|
||||
<xs:complexType>
|
||||
<xs:attribute name='name' type='xs:string' use='required'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
<xs:element name='error' type='ParameterError'/>
|
||||
</xs:choice>
|
||||
<xs:attributeGroup ref='responseCode'/>
|
||||
@ -1568,7 +1600,7 @@
|
||||
<xs:element name='getFormResponse'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
<xs:any minOccurs="0" maxOccurs="1" namespace="jabber:x:data"/>
|
||||
<xs:element ref='xd:x' minOccurs="0" maxOccurs="1"/>
|
||||
</xs:sequence>
|
||||
<xs:attributeGroup ref='responseCode'/>
|
||||
</xs:complexType>
|
||||
@ -1694,7 +1726,7 @@
|
||||
|
||||
<xs:simpleType name='Color'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:pattern value='^[0-9a-fA-F]{6}$'/>
|
||||
<xs:pattern value='^([0-9a-fA-F]{6})|([0-9a-fA-F]{8})$'/>
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
|
||||
@ -1713,7 +1745,31 @@
|
||||
</xs:schema>]]>
|
||||
</code>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Joachim Lindborg for all valuable feedback.</p>
|
||||
<section1 topic='For more information' anchor='moreinfo'>
|
||||
<p>
|
||||
For more information, please see the following resources:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>
|
||||
The <link url='http://wiki.xmpp.org/web/Tech_pages/SensorNetworks'>Sensor Network section of the XMPP Wiki</link> contains further information about the
|
||||
use of the sensor network XEPs, links to implementations, discussions, etc.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
The XEP's and related projects are also available on <link url='https://github.com/joachimlindborg/'>github</link>, thanks to Joachim Lindborg.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
A presentation giving an overview of all extensions related to Internet of Things can be found here:
|
||||
<link url='http://prezi.com/esosntqhewhs/iot-xmpp/'>http://prezi.com/esosntqhewhs/iot-xmpp/</link>.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Joachim Lindborg and Tina Beckman for all valuable feedback.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user