lwM2M
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.
Interlocutors
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
Syntax
The general syntax is:
REQUEST := METHOD OBJECT_ID OCCURENCE_ID RESOURCE_ID [ DATA ]
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 |
Examples
| 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,...
Commands
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'.
Configuration
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.
Timeout
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.
Encryption
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.
Reference
The complete list of objects and resources is available on the website dedicated to mobile applications