Skip to content


Duetware is made up of two complementary machines:

  • an lwM2M that responds to requests. lwM2M is a communication protocol between machines.
  • A JVM that will provide flexibility and autonomy.

We present below the main principles of the lwM2M implemented in Duetware. Duetware has a partial implementation of the Open Mobile Alliance LWM2M protocol.

This implementation corresponds to the part commonly referred as an lwM2M client that will respond to requests from either outside or inside.


From the outside, the interlocutors can be:

  • a mobile application that requests, for example, the status of variables in order to display them,

  • A server or any computer that wants, for example, to reconfigure a module.

From the inside, the Java machine will be able to run lwM2M commands. The target protocol handler can also, under certain conditions, issue commands to write or read variables (e.g. as in modbus slave context).

Iotize's implementation is based on an older version of lwM2M that has evolved a lot since then. In this, it can be considered a specific implementation.

Command structure


The general syntax is:


List of supported objects

The following standard lwM2M objects are supported:

Id Object Main resources
3 DEVICE SN, Power, Memory,...
5 FIRMWARE Versioning, updates,..

The Ids greater than or equal to 1024 correspond to specific Duetware objects:

Id Object Main resources
1024 INTERFACE Login, radio protocols, application, ...
1025 PROFILE Rights, pwd, name,...
1027 TARGET Wired protocols, connection,...
1028 BUNDLE Name, ACL, global read,...
1029 VARIABLE Address, type, length, read, ...
1031 DATALOG Frequency, mode, ...
1032 FILESYSTEM List, accesses to files


Command Meaning
GET/1028/2/4 Read(GET) the name(4) of bundle #2
POST/5/./6 Execute(POST) the CRC(6) check-of firmware (5)

When an element is missing (the same as for the previous POST command), the value -1 (65535) is sent instead of the missing value. Very often, the occurence is missing because of the unicity of the object: device, firmware, target,...


The historical methods of CoAP are those implemented in Duetware.

Methodology Description
GET Reading a resource
PUT Writing a resource
DELETE Destroying an Object
POST Executing/Modifying a Resource

Return Codes

Each GET command returns a response. But all commands will return a return code that will indicate if the order has been successfully placed (e.g. without error). The list of return codes is available here.

General principles of lwM2M

The principles of query execution are as follows:

A single interlocutor

Generally speaking, only one external device is allowed for a dialog/session. If one mobile is connected to a Tap, another mobile will not be able to connect. Neither locally (BLE/WiFI), nor remotely (MQTT). Nevertheless:

  • It is optionally possible to allow NFC to break the current session to establish itself as a single interlocutor.

  • Java and slave servers protocol handlers (e.g. modbus in slave mode) can intersperse into a session to execute commands of their own, without disturbing the main session. However, commands sent by a Java program could interfere intentionally...

Session and singlepacket modes

In a standard communication, the interlocutor connects and opens a session that corresponds to a succession of requests. However, it is also possible to send a 'singlepacket' which is a batch of basic commands that will be executed at once. Singlepackets are both encrypted and signed, and will be executed with the signer's rights. This option is used in particular to perform firmware updates.

Target and Host Protocols

Upstream of the lwM2M, a multiplexer allows you to receive commands from the available wireless channels: NFC, BLE, Wi-Fi, etc. The upstream protocol is called 'Host protocol'.

Downstream, a second multiplexer will provide access to an external target via a wired protocol (SWD, SPI, S3P, Modbus, CAN, etc.). The downstream protocol is called 'Target protocol'.


The majority of PUT commands are intended to configure the lwM2M. However, they can also be used to access variables. The configuration data is stored in a FLASH file. At startup, this file is copied back to RAM. It is this that will be taken into account at all times.

At any time, it is possible to save the current configuration in FLASH.


A session will be stopped when no more command are received after a pre-defined time (configurable timeout). An alternative to 'keep the session alive' consists in sending some dummy requests.

Permissions (ACL)

All orders are subject to permissions that correspond to the rights granted to the current profile. A user will therefore have to make a login if he wants to execute commands outside the 'anonymous' context.


The first requests are made in unencrypted mode. It is the interlocutor who asks to switch to encrypted mode. This is possible, even in anonymous. However, the encryption will be stronger for a logged in user because it will then be possible to create keys that take into account a shared secret.


The complete list of objects and resources is available on the website dedicated to mobile applications

Back to top