RFC 8428
Sensor Measurement Lists (SenML)
Internet Engineering Task Force (IETF) C. Jennings Request for Comments: 8428 Cisco Category: Standards Track Z. Shelby ISSN: 2070-1721 ARM J. Arkko A. Keranen Ericsson C. Bormann Universitaet Bremen TZI August 2018 Sensor Measurement Lists (SenML)Abstract
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8428.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 7 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Records and Their Fields . . . . . . . . . . . . . . . . 9 4.5.1. Names . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.2. Units . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.4. Values . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Resolved Records . . . . . . . . . . . . . . . . . . . . 12 4.7. Associating Metadata . . . . . . . . . . . . . . . . . . 12 4.8. Sensor Streaming Measurement Lists (SenSML) . . . . . . . 12 4.9. Configuration and Actuation Usage . . . . . . . . . . . . 13 5. JSON Representation (application/senml+json) . . . . . . . . 13 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Single Data Point . . . . . . . . . . . . . . . . . . 14 5.1.2. Multiple Data Points . . . . . . . . . . . . . . . . 14 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 15 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 17 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 17 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 18 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 18 6. CBOR Representation (application/senml+cbor) . . . . . . . . 19 7. XML Representation (application/senml+xml) . . . . . . . . . 21 8. EXI Representation (application/senml-exi) . . . . . . . . . 23
9. Fragment Identification Methods . . . . . . . . . . . . . . . 26 9.1. Fragment Identification Examples . . . . . . . . . . . . 26 9.2. Fragment Identification for XML and EXI Formats . . . . . 27 10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 27 11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 12.1. SenML Units Registry . . . . . . . . . . . . . . . . . . 30 12.2. SenML Labels Registry . . . . . . . . . . . . . . . . . 35 12.3. Media Type Registrations . . . . . . . . . . . . . . . . 36 12.3.1. senml+json Media Type Registration . . . . . . . . . 37 12.3.2. sensml+json Media Type Registration . . . . . . . . 38 12.3.3. senml+cbor Media Type Registration . . . . . . . . . 39 12.3.4. sensml+cbor Media Type Registration . . . . . . . . 41 12.3.5. senml+xml Media Type Registration . . . . . . . . . 42 12.3.6. sensml+xml Media Type Registration . . . . . . . . . 43 12.3.7. senml-exi Media Type Registration . . . . . . . . . 44 12.3.8. sensml-exi Media Type Registration . . . . . . . . . 45 12.4. XML Namespace Registration . . . . . . . . . . . . . . . 47 12.5. CoAP Content-Format Registration . . . . . . . . . . . . 47 13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 48 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 15.1. Normative References . . . . . . . . . . . . . . . . . . 49 15.2. Informative References . . . . . . . . . . . . . . . . . 51 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 541. Overview
Connecting sensors to the Internet is not new, and there have been many protocols designed to facilitate it. This specification defines a format and media types for carrying simple sensor information in protocols such as HTTP [RFC7230] or CoAP [RFC7252]. The SenML format is designed so that processors with very limited capabilities could easily encode a sensor measurement into the media type, while at the same time, a server parsing the data could collect a large number of sensor measurements in a relatively efficient manner. SenML can be used for a variety of data flow models, most notably data feeds pushed from a sensor to a collector, and for the web resource model where the sensor data is requested as a resource representation (e.g., "GET /sensor/temperature"). There are many types of more complex measurements and measurements that this media type would not be suitable for. SenML strikes a balance between having some information about the sensor carried with the sensor data so that the data is self-describing, but it also tries to make that a fairly minimal set of auxiliary information for
efficiency reasons. Other information about the sensor can be discovered by other methods such as using the Constrained RESTful Environments (CoRE) Link Format [RFC6690]. SenML is defined by a data model for measurements and simple metadata about measurements and devices. The data is structured as a single array that contains a series of SenML Records that can each contain fields such as a unique identifier for the sensor, the time the measurement was made, the unit the measurement is in, and the current value of the sensor. Serializations for this data model are defined for JSON [RFC8259], CBOR [RFC7049], XML [W3C.REC-xml-20081126], and Efficient XML Interchange (EXI) [W3C.REC-exi-20140211]. For example, the following shows a measurement from a temperature gauge encoded in the JSON syntax. [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ] In the example above, the array has a single SenML Record with a measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a current value of 23.1 degrees Celsius.2. Requirements and Design Goals
The design goal is to be able to send simple sensor measurements in small packets from large numbers of constrained devices. Keeping the total size of the payload small makes it easy to also use SenML in constrained networks, e.g., in an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944]. It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on an 8-bit microprocessor. Experience with power meters and other large-scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request. This "batch" upload capability allows the server side to efficiently support a large number of devices. It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time. The multiple measurements could be from multiple related sensors or from the same sensor but at different times.
The basic design is an array with a series of measurements. The
following example shows two measurements made at different times.
The value of a measurement is given by the "v" field, the time of a
measurement is in the "t" field, the "n" field has a unique sensor
name, and the unit of the measurement is carried in the "u" field.
[
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
"v":23.5},
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,
"v":23.6}
]
To keep the messages small, it does not make sense to repeat the "n"
field in each SenML Record, so there is a concept of a Base Name,
which is simply a string that is prepended to the Name field of all
elements in that Record and any Records that follow it. So, a more
compact form of the example above is the following.
[
{"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
"v":23.5},
{"u":"Cel","t":1.276020091e+09,
"v":23.6}
]
In the above example, the Base Name is in the "bn" field, and the "n"
fields in each Record are empty strings, so they are omitted.
Some devices have accurate time while others do not, so SenML
supports absolute and relative times. Time is represented in
floating point as seconds. Values greater than or equal to 2**28
represent an absolute time relative to the Unix epoch. Values less
than 2**28 represent time relative to the current time.
A simple sensor with no absolute wall-clock time might take a
measurement every second, batch up 60 of them, and then send the
batch to a server. It would include the relative time each
measurement was made compared to the time the batch was sent in each
SenML Record. If the server has accurate time based on, e.g., the
Network Time Protocol (NTP), it may use the time it received the data
and the relative offset to replace the times in the SenML with
absolute times before saving the SenML information in a document
database.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document also uses the following terms: SenML Record: One measurement or configuration instance in time presented using the SenML data model. SenML Pack: One or more SenML Records in an array structure. SenML Label: A short name used in SenML Records to denote different SenML fields (e.g., "v" for "value"). SenML Field: A component of a record that associates a value to a SenML Label for this record. SenSML: Sensor Streaming Measurement List (see Section 4.8). SenSML Stream: One or more SenML Records to be processed as a stream. This document uses the terms "attribute" and "tag" where they occur with the underlying technologies (XML, CBOR [RFC7049], and the CoRE Link Format [RFC6690]); they are not used for SenML concepts, per se. However, note that "attribute" has been widely used in the past as a synonym for the SenML "field". All comparisons of text strings are performed byte by byte, which results in the comparisons being case sensitive. Where arithmetic is used, this specification uses the familiar notation of the programming language C, except that the operator "**" stands for exponentiation.4. SenML Structure and Semantics
Each SenML Pack carries a single array that represents a set of measurements and/or parameters. This array contains a series of SenML Records with several fields described below. There are two kinds of fields: base and regular. Both the base and regular fields can be included in any SenML Record. The base fields apply to the entries in the Record and also to all Records after it up to, but not
including, the next Record that has that same base field. All base fields are optional. Regular fields can be included in any SenML Record and apply only to that Record.4.1. Base Fields
Base Name: This is a string that is prepended to the names found in the entries. Base Time: A base time that is added to the time found in an entry. Base Unit: A base unit that is assumed for all entries, unless otherwise indicated. If a record does not contain a Unit value, then the Base Unit is used. Otherwise, the value found in the Unit (if any) is used. Base Value: A base value is added to the value found in an entry, similar to Base Time. Base Sum: A base sum is added to the sum found in an entry, similar to Base Time. Base Version: Version number of the media type format. This field is an optional positive integer and defaults to 10 if not present.4.2. Regular Fields
Name: Name of the sensor or parameter. When appended to the Base Name field, this must result in a globally unique identifier for the resource. The name is optional, if the Base Name is present. If the name is missing, the Base Name must uniquely identify the resource. This can be used to represent a large array of measurements from the same sensor without having to repeat its identifier on every measurement. Unit: Unit for a measurement value. Optional. Value: Value of the entry. Optional if a Sum value is present; otherwise, it's required. Values are represented using basic data types. This specification defines floating-point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value"), and binary data ("vd" for "Data Value"). Exactly one Value field MUST appear unless there is a Sum field, in which case it is allowed to have no Value field. Sum: Integrated sum of the values over time. Optional. This field is in the unit specified in the Unit value multiplied by seconds. For historical reasons, it is named "sum" instead of "integral".
Time: Time when the value was recorded. Optional.
Update Time: Period of time in seconds that represents the maximum
time before this sensor will provide an updated reading for a
measurement. Optional. This can be used to detect the failure of
sensors or the communications path from the sensor.
4.3. SenML Labels
Table 1 provides an overview of all SenML fields defined by this
document with their respective labels and data types.
+---------------+-------+------------+------------+------------+
| Name | Label | CBOR Label | JSON Type | XML Type |
+---------------+-------+------------+------------+------------+
| Base Name | bn | -2 | String | string |
| Base Time | bt | -3 | Number | double |
| Base Unit | bu | -4 | String | string |
| Base Value | bv | -5 | Number | double |
| Base Sum | bs | -6 | Number | double |
| Base Version | bver | -1 | Number | int |
| Name | n | 0 | String | string |
| Unit | u | 1 | String | string |
| Value | v | 2 | Number | double |
| String Value | vs | 3 | String | string |
| Boolean Value | vb | 4 | Boolean | boolean |
| Data Value | vd | 8 | String (*) | string (*) |
| Sum | s | 5 | Number | double |
| Time | t | 6 | Number | double |
| Update Time | ut | 7 | Number | double |
+---------------+-------+------------+------------+------------+
Table 1: SenML Labels
(*) Data Value is a base64-encoded string with the URL-safe alphabet
as defined in Section 5 of [RFC4648], with padding omitted. (In
CBOR, the octets in the Data Value are encoded using a definite-
length byte string, major type 2.)
For details of the JSON representation, see Section 5; for CBOR, see
Section 6; and for XML, see Section 7.
4.4. Extensibility
The SenML format can be extended with further custom fields. Both new base and regular fields are allowed. See Section 12.2 for details. Implementations MUST ignore fields they don't recognize unless that field has a label name that ends with the "_" character, in which case an error MUST be generated. All SenML Records in a Pack MUST have the same version number. This is typically done by adding a Base Version field to only the first Record in the Pack or by using the default value. Systems reading one of the objects MUST check for the Base Version field. If this value is a version number larger than the version that the system understands, the system MUST NOT use this object. This allows the version number to indicate that the object contains structure or semantics that is different from what is defined in the present document beyond just making use of the extension points provided here. New version numbers can only be defined in an RFC that updates this specification or its successors.4.5. Records and Their Fields
4.5.1. Names
The Name value is concatenated to the Base Name value to yield the name of the sensor. The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others. The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", and "0" to "9", as well as "-", ":", ".", "/", and "_"; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding; note that a name that contains "/" characters maps into multiple URI path segments) and can be used directly in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. See Section 14 for privacy considerations that apply to the use of long-term stable unique identifiers. Although it is RECOMMENDED that concatenated names be represented as URIs [RFC3986] or URNs [RFC8141], the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used. As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set. One approach is to include a bit string
that has guaranteed uniqueness (such as a 1-wire address [AN1796]). Some of the examples within this document use the device URN namespace as specified in [DEVICE-URN]. Universally Unique Identifiers (UUIDs) [RFC4122] are another way to generate a unique name. However, the restricted character set does not allow the use of many URI schemes, such as the "tag" scheme [RFC4151] and the "ni" scheme [RFC6920], in names as such. The use of URIs with characters incompatible with this set and possible mapping rules between the two are outside the scope of the present document.4.5.2. Units
If the Record has no Unit, the Base Unit is used as the Unit. Having no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context.4.5.3. Time
If either the Base Time or Time value is missing, the missing field is considered to have a value of zero. The Base Time and Time values are added together to get a value representing the time of measurement. Values less than 268,435,456 (2**28) represent time relative to the current time. That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now". A negative value indicates seconds in the past from roughly "now". Positive values up to 2**28 indicate seconds in the future from "now". An example for employing positive values would be actuation use, when the desired change should happen in the future, but the sender or the receiver does not have accurate time available. Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time), and the time is counted the same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" [TIME_T]. Therefore, the smallest absolute Time value that can be expressed (2**28) is 1978-07-04 21:24:16 UTC. Because Time values up to 2**28 are used for representing time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2**28 (i.e., absolute time) when relative time was intended to be used.
Obviously, SenML Records referenced to "now" are only useful within a specific communication context (e.g., based on information on when the SenML Pack, or a specific Record in a SenSML Stream, was sent) or together with some other context information that can be used for deriving a meaning of "now"; the expectation for any archival use is that they will be processed into UTC-referenced records before that context would cease to be available. This specification deliberately leaves the accuracy of "now" very vague as it is determined by the overall systems that use SenML. In a system where a sensor without wall-clock time sends a SenML Record with a time referenced to "now" over a high-speed RS-485 link to an embedded system with accurate time that resolves "now" based on the time of reception, the resulting time uncertainty could be within 1 ms. At the other extreme, a deployment that sends SenML wind-speed readings over a Low-Earth Orbit (LEO) satellite link from a mountain valley might have resulting reception Time values that are easily a dozen minutes off the actual time of the sensor reading, with the time uncertainty depending on satellite locations and conditions.4.5.4. Values
If only one of the Base Sum or Sum value is present, the missing field is considered to have a value of zero. The Base Sum and Sum values are added together to get the sum of measurement. If neither the Base Sum nor the Sum is present, then the measurement does not have a Sum value. If the Base Value or Value is not present, the missing field(s) is considered to have a value of zero. The Base Value and Value are added together to get the value of the measurement. Representing the statistical characteristics of measurements, such as accuracy, can be very complex. Future specification may add new fields to provide better information about the statistical properties of the measurement. In summary, the structure of a SenML Record is laid out to support a single measurement per Record. If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate Records linked through their Time value; this is even true when one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time).
4.6. Resolved Records
Sometimes it is useful to be able to refer to a defined normalized format for SenML Records. This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. Also, if SenML Records are used outside of a SenML Pack, they need to be resolved first to ensure applicable base values are applied. A SenML Record is referred to as "resolved" if it does not contain any base values, i.e., labels starting with the character "b", except for Base Version fields (see below), and has no relative times. To resolve the Records, the applicable base values of the SenML Pack (if any) are applied to the Record. That is, for the base values in the Record or before the Record in the Pack, Name and Base Name are concatenated, the Base Time is added to the time of the Record, the Base Unit is applied to the Record if it did not contain a Unit, etc. In addition, the Records need to be in chronological order in the Pack. An example of this is shown in Section 5.1.4. The Base Version field MUST NOT be present in resolved Records if the SenML version defined in this document is used; otherwise, it MUST be present in all the resolved SenML Records. A future specification that defines new base fields needs to specify how the field is resolved.4.7. Associating Metadata
SenML is designed to carry the minimum dynamic information about measurements and, for efficiency reasons, does not carry significant static metadata about the device, object, or sensors. Instead, it is assumed that this metadata is carried out of band. For web resources using SenML Packs, this metadata can be made available using the CoRE Link Format [RFC6690]. The most obvious use of this link format is to describe that a resource is available in a SenML format in the first place. The relevant media type indicator is included in the Content-Type (ct=) link attribute (which is defined for the link format in Section 7.2.1 of [RFC7252]).4.8. Sensor Streaming Measurement Lists (SenSML)
In some usage scenarios of SenML, the implementations store or transmit SenML in a stream-like fashion, where data is collected over time and continuously added to the object. This mode of operation is optional, but systems or protocols using SenML in this fashion MUST specify that they are doing this. SenML defines separate media types to indicate Sensor Streaming Measurement Lists (SenSML) for this
usage (see Section 12.3.2). In this situation, the SenSML Stream can be sent and received in a partial fashion, i.e., a measurement entry can be read as soon as the SenML Record is received and does not have to wait for the full SenSML Stream to be complete. If times relative to "now" (see Section 4.5.3) are used in SenML Records of a SenSML Stream, their interpretation of "now" is based on the time when the specific Record is sent in the stream.4.9. Configuration and Actuation Usage
SenML can also be used for configuring parameters and controlling actuators. When a SenML Pack is sent (e.g., using an HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as names) to given values at the given time(s). The semantics of the target resource supporting this usage can be described, e.g., using [RID-CoRE]. Examples of actuation usage are shown in Section 5.1.7.5. JSON Representation (application/senml+json)
For the SenML fields shown in Table 2, the SenML Labels are used as the JSON object member names within JSON objects representing the JSON SenML Records. +---------------+-------+-----------+ | Name | Label | JSON Type | +---------------+-------+-----------+ | Base Name | bn | String | | Base Time | bt | Number | | Base Unit | bu | String | | Base Value | bv | Number | | Base Sum | bs | Number | | Base Version | bver | Number | | Name | n | String | | Unit | u | String | | Value | v | Number | | String Value | vs | String | | Boolean Value | vb | Boolean | | Data Value | vd | String | | Sum | s | Number | | Time | t | Number | | Update Time | ut | Number | +---------------+-------+-----------+ Table 2: JSON SenML Labels
The root JSON value consists of an array with one JSON object for each SenML Record. All the fields in the above table MAY occur in the Records with member values of the type specified in the table. Only the UTF-8 [RFC3629] form of JSON is allowed. Characters in the String Value are encoded using the escape sequences defined in [RFC8259]. Octets in the Data Value are base64 encoded with the URL- safe alphabet as defined in Section 5 of [RFC4648], with padding omitted. Systems receiving measurements MUST be able to process the range of floating-point numbers that are representable as IEEE double- precision, floating-point numbers [IEEE.754]. This allows Time values to have better than microsecond precision over the next 100 years. The number of significant digits in any measurement is not relevant, so a reading of 1.1 has exactly the same semantic meaning as 1.10. If the value has an exponent, the "e" MUST be in lower case. In the interest of avoiding unnecessary verbosity and speeding up processing, the mantissa SHOULD be less than 19 characters long, and the exponent SHOULD be less than 5 characters long.5.1. Examples
5.1.1. Single Data Point
The following shows a temperature reading taken approximately "now" by a 1-wire sensor device that was assigned the unique 1-wire address of 10e2073a01080063: [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ]5.1.2. Multiple Data Points
The following example shows voltage and current "now", i.e., at an unspecified time. [ {"bn":"urn:dev:ow:10e2073a01080063:","n":"voltage","u":"V","v":120.1}, {"n":"current","u":"A","v":1.2} ]
The next example is similar to the above one, but it shows current at
Tue Jun 8 18:01:16.001 UTC 2010 and at each second for the previous 5
seconds.
[
{"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,
"bu":"A","bver":5,
"n":"voltage","u":"V","v":120.1},
{"n":"current","t":-5,"v":1.2},
{"n":"current","t":-4,"v":1.3},
{"n":"current","t":-3,"v":1.4},
{"n":"current","t":-2,"v":1.5},
{"n":"current","t":-1,"v":1.6},
{"n":"current","v":1.7}
]
As an example of SenSML, the following stream of measurements may be
sent via a long-lived HTTP POST from the producer of the stream to
its consumer, and each measurement object may be reported at the time
it was measured:
[
{"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
"bu":"%RH","v":21.2},
{"t":10,"v":21.3},
{"t":20,"v":21.4},
{"t":30,"v":21.4},
{"t":40,"v":21.5},
{"t":50,"v":21.5},
{"t":60,"v":21.5},
{"t":70,"v":21.6},
{"t":80,"v":21.7},
...
5.1.3. Multiple Measurements
The following example shows humidity measurements from a mobile
device with a 1-wire address 10e2073a01080063, starting at Mon Oct 31
13:24:24 UTC 2011. The device also provides position data, which is
provided in the same measurement or parameter array as separate
entries. Note that time is used to correlate data that belongs
together, e.g., a measurement and a parameter associated with it.
Finally, the device also reports extra data about its battery status
at a separate time.
[
{"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
"bu":"%RH","v":20},
{"u":"lon","v":24.30621},
{"u":"lat","v":60.07965},
{"t":60,"v":20.3},
{"u":"lon","t":60,"v":24.30622},
{"u":"lat","t":60,"v":60.07965},
{"t":120,"v":20.7},
{"u":"lon","t":120,"v":24.30623},
{"u":"lat","t":120,"v":60.07966},
{"u":"%EL","t":150,"v":98},
{"t":180,"v":21.2},
{"u":"lon","t":180,"v":24.30628},
{"u":"lat","t":180,"v":60.07967}
]
The following table shows the size of this example in various forms,
as well as the size of each of these forms compressed with gzip.
+----------+------+-----------------+
| Encoding | Size | Compressed Size |
+----------+------+-----------------+
| JSON | 573 | 206 |
| XML | 649 | 235 |
| CBOR | 254 | 196 |
| EXI | 161 | 184 |
+----------+------+-----------------+
Table 3: Size Comparisons
5.1.4. Resolved Data
The following shows the example from the previous section in resolved format. [ {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, "v":20}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, "v":24.30621}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09, "v":60.07965}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09, "v":20.3}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09, "v":24.30622}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09, "v":60.07965}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09, "v":20.7}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09, "v":24.30623}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09, "v":60.07966}, {"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09, "v":98}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09, "v":21.2}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09, "v":24.30628}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09, "v":60.07967} ]5.1.5. Multiple Data Types
The following example shows a sensor that returns different data types. [ {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1}, {"n":"label","vs":"Machine Room"}, {"n":"open","vb":false}, {"n":"nfc-reader","vd":"aGkgCg"} ]
5.1.6. Collection of Resources
The following example shows the results from a query to one device that aggregates multiple measurements from other devices. The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011 and has gotten two separate values as a result: a temperature and humidity measurement as well as the results from another device at http://[2001:db8::1] that also had a temperature and humidity measurement. Note that the last record would use the Base Name from the 3rd record but the Base Time from the first record. [ {"bn":"2001:db8::2/","bt":1.320078429e+09, "n":"temperature","u":"Cel","v":25.2}, {"n":"humidity","u":"%RH","v":30}, {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, {"n":"humidity","u":"%RH","v":67} ]5.1.7. Setting an Actuator
The following example shows the SenML that could be used to set the current set point of a typical residential thermostat that has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override. [ {"bn":"urn:dev:ow:10e2073a01080063:"}, {"n":"temp","u":"Cel","v":23.1}, {"n":"heat","u":"/","v":1}, {"n":"fan","u":"/","v":0} ] In the following example, two different lights are turned on. It is assumed that the lights are on a network that can guarantee delivery of the messages to the two lights within 15 ms (e.g., a network using 802.1BA [IEEE802.1BA] and 802.1AS [IEEE802.1AS] for time synchronization). The controller has set the time of the lights to come on at 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time. [ {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":1}, {"n":"2001:db8::4","v":1} ]
The following shows two lights being turned off using a
non-deterministic network that has high odds of delivering a message
in less than 100 ms and uses NTP for time synchronization. The
current time is 1320078429. The user has just turned off a light
switch that is turning off two lights. Both lights are immediately
dimmed to 50% brightness to give the user instant feedback that
something is changing. However, given the network, the lights will
probably dim at somewhat different times. Then 100 ms in the future,
both lights will go off at the same time. The instant, but not
synchronized, dimming gives the user the sensation of quick
responses, and the timed-off 100 ms in the future gives the
perception of both lights going off at the same time.
[
{"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":0.5},
{"n":"2001:db8::4","v":0.5},
{"n":"2001:db8::3","t":0.1,"v":0},
{"n":"2001:db8::4","t":0.1,"v":0}
]
(page 19 continued on part 2)
