Summary of LWM2M services:
- A simple object based resource model
- Resource observation and notification
- Create, read, update, delete, and configure device attributes
- Support for TLV, JSON, Plain text, and opaque data formats
- User Datagram Protocol (UDP) support
- Security via DTLS
- LWM2M bootstrap server support
- LWM2M management server support
Basic LWM2M functionality includes:
- LWM2M server/client models
- Device bootstrapping, registration and connectivity
- Access control
- Firmware updates
- Device metrics
LWM2M provides four interfaces, each designed for specific purpose as shown below:
- Bootstrap - used to provide LWM2M management server credentials to a LWM2M client for registration purposes.
- Client Registration - enables the LWM2M client to register with one or more LWM2M servers.
- Device Management and Service Enablement - used by the LWM2M Server to access an
- Object Instance or Resource on the client side. The main operation are: read, write, delete, execute, write attribute and discover.
- Information Reporting - used by the LWM2M Server to observe any changes in a resource on a LWM2M client and to receive notifications from the client when an observed value changes.
The Object/Instance/Resource (O/I/R) Model
A Resource, is a single typed item of data, which is exposed by a LWM2M client for consumption by a control or management application. As an example, a remote temperature sensing device could expose several items of data such as:
- Its manufacturer (type string)
- Its unique serial number (type string)
- Its unique identifier or device name (type string)
- Its present status (type integer)
- Its present sensor measurement value (type float)
- Its geographic location (type array of integer)
- Its present RTC time (type integer) and so on.
Each of the above would be defined as an individual Resource associated with that device, which is made available (directly or indirectly) to the managing application. Resources are defined in terms of:
- data type - the data type of the value of the resource (integer, string, float, array ...)
- multiplicity - whether the resource may have more than one concurrent instance and whether or not the resource is mandatory
- operation - the types of operation that may be performed on the resource (read, write, readWrite, execute)
- access control - depending on allowed operations
The collection which contains and associates a group of Resource definitions is called an Object, and an instance of such an Object is called an Object Instance (or just an Instance). It follows that an Object Instance contains actual Resource values, whereas an Object contains only the definition of Resources. An Object then, is a named collection of individual Resource definitions which can be mapped directly to a device or to a software component for the purpose of data sharing. In the case of a device which is complex enough to have several discrete functions, multiple Objects could be defined on the same device. It is also possible to host multiple Instances of the same Object on a device should the need arise. Since the same principle applies to Resources, the means to address a Resource follows a semantic approach such that:
Addresses: Object 1000 / Instance 0 / Resource 1
The strength of the above Object/Instance/Resource Model lies in its ability to support interoperability between unrelated devices or applications such that each exposed Resource is fully described to any function that consumes it. Client Objects are required to be duplicated on the LWM2M Server and/or any management application that interacts with the client via LWM2M. The Client application is responsible for updating the server Resource data when the respective Client Resource value changes. This approach ensures that any application that queries the server will have access to the most up-to-date Resource information and that the last reported state of that Resource will still be available in the event that the device hosting it goes off-line.
IPSO object definitions
The Internet Protocol for the networking of Smart Objects (IPSO) Alliance seeks to register extensible smart object definitions based on the OMA LWM2M object resource model, with the ultimate aim of ensuring device and application interoperability via an agreed set of objects, resources, properties, attributes and operations. Since IPSO has pre-defined data models for a wide variety of device types, based on the OMA LWM2M standard, they are readily usable by any application that implements OMA LWM2M.
An IPSO object list can be found here. The Awa client API tools support simple operations, such as defining a custom object type, setting a resource value, retrieving a resource value, and waiting for a resource to change or be executed.
Object Definition files
Object Definition files may be used to load object and resource definitions into the Client or Server daemon. This is useful when object definitions need to be in place before the client daemon connects to a LWM2M bootstrap server or LWM2M server, or before clients register with the LWM2M server. The files are loaded at the time the daemon starts.
Note: it is not possible to use this feature to extend objects that are already defined, for example by attempting to add resources to an existing object. Only new objects can be defined at this time.
The client or server daemon can load an object definition file with the --objDefs/-o option, for example:
$ awa_clientd --bootstrap coap://bootstrap:15683 --objDefs myObjects.xml
What do Object Definition files look like?
Object Definition files are XML files that begin with either an
Note: All XML tags and values are case sensitive!
To define a single object and any accompanying resources, the
Find more information about object definition files and XML tags here