-[launch from prebuilt docker images available on the gitlab packages - NOT AVAILABLE FOR NOW -](LOM2M/Install,-configure-and-launch#launch-lom2m-with-available-docker-image)
-[build LOM2M from source using the provided Dockerfile and docker](LOM2M/Install,-configure-and-launch#build-using-docker-and-the-dockerfile): a Dockerfile is provided with the source code in lom2m/docker/LOM2M to build a container for UNIX target compilation or esp8266 target
-[compile LOM2M yourself from source code using provided scripts](LOM2M/Install,-configure-and-launch#compile-lom2m-from-source)(emulator or ESP)
Once you have launched successfully LOM2M, you can use the provided [request collection to test the platform](LOM2M/Install,-configure-and-launch#test-the-api).
# Pre-build configuration
LOM2M is structured in order to be malleable at build time. For instance, you can enable or disable some features à pre-build time to reduce the size of the final executable (typically this is useful when you work on an embedded device such as ESP8266).
You can find all the possible features to enable/disable in the `configuration.h` file present in the source code repository (`LOM2M/src/server/librairies/lom2m/configuration.h`).
**N.B.:** If some features are disabled in the `configration.h` file, they are disabled **before** build. Therefore, these features **WILL NOT be compiled nor included in the final executable**.
If you want to keep the possibility to enable or disable dynamically a feature be sure to let it activated for build time in order for the feature to be included in the executable. _(UNIX targets only)_
LOM2M is structured in order to be malleable at build time. For instance, you can enable or disable some features à pre-build time to reduce the size of the final executable (typically this is useful when you work on an embedded device such as ESP8266). You can find all the possible features to enable/disable in the `configuration.h` file present in the source code repository (`LOM2M/src/server/librairies/lom2m/configuration.h`).
**N.B.:** If some features are disabled in the `configration.h` file, they are disabled **before** build. Therefore, these features **WILL NOT be compiled nor included in the final executable**. If you want to keep the possibility to enable or disable dynamically a feature be sure to let it activated for build time in order for the feature to be included in the executable. _(UNIX targets only)_
By default, some feature are disabled for ESP targets (to limit the memory and processor occupation). However, they are all enabled by default on UNIX target so they can be managed dynamically through environment variables. (cf. next section)
Here are some examples of what you can configure before building the project:
`#define PERSISTENCE_FEAT 1` you can set the to `0` to disable the backup feature and work only in memory mode, or let it set to `1` to enable the backup to the filesystem.
Here are some examples of what you can configure before building the project: `#define PERSISTENCE_FEAT 1` you can set the to `0` to disable the backup feature and work only in memory mode, or let it set to `1` to enable the backup to the filesystem.
`#define MQTTS_BINDING 1` you can set this one to `0` to disable the MQTTS feature and all its related code.
`#define HTTP_BINDING 1` you can do the same for the HTTP feature.
`#define MQTTS_BINDING 1` you can set this one to `0` to disable the MQTTS feature and all its related code. `#define HTTP_BINDING 1` you can do the same for the HTTP feature.
# Dynamic configuration and environment variables
Those variables are to be used in a **UNIX** environment. **On ESP target, this feature is not available**.
Here are the environment variables you can use to configure dynamically LOM2M:
## Dependencies versions
These variables enable to set default version to be used at build time for dependencies.
(if not set, default values are used in `install-deps.sh` script.)
In docker, this is used as `ARG` values that are used only at build time. If you need to use different versions, you can change it in the docker-compose file or use the `--build-arg` options with the `docker build` command.
These variables enable to set default version to be used at build time for dependencies. (if not set, default values are used in `install-deps.sh` script.) In docker, this is used as `ARG` values that are used only at build time. If you need to use different versions, you can change it in the docker-compose file or use the `--build-arg` options with the `docker build` command.
-`ESP8266ARDUINO_VERSION=2.7.4`
-`ARDUINO_JSON_VERSION=v6.16.1`
-`DALLAS_TEMPERATURE_VERSION=3.9.0`
...
...
@@ -40,6 +38,7 @@ In docker, this is used as `ARG` values that are used only at build time. If you
@@ -48,19 +47,23 @@ In docker, this is used as `ARG` values that are used only at build time. If you
-`LOM2M_DEFAULT_PROTOCOL=http` (use http or mqtts)
## Remote CSE configuration:
-`LOM2M_REMOTE_POA=http://ip:port/context`
-`LOM2M_REMOTE_CSE_ID=cse-id`
-`LOM2M_REMOTE_CSE_NAME=cse-name`
## Backup feature
-`LOM2M_DATA_PATH="/path/to/backup/file"` (This can be set if changing the default backup file location is needed)
-`LOM2M_BACKUP_PERIOD=30000` (Use this to setup a specific backup period (ms))
-`LOM2M_BACKUP_ENABLED=1` (set it to 0 to disable the backup feature)
## HTTP binding
-`LOM2M_HTTP_BINDING=1` (set it to 0 to disable the HTTP protocol binding)
## MQTTS binding **NEW**
## MQTTS binding **(not included in opensource version)**
-`LOM2M_MQTTS_BINDING=0` set it to 1 to enable MQTTS protocol binding. MQTTS binding must be included in the compiled target
-`LOM2M_MQTTS_ENDPOINT="mqtt.broker.endpoint"` adress of the MQTTS endpoint
-`LOM2M_MQTTS_PORT=8883`
...
...
@@ -68,14 +71,11 @@ In docker, this is used as `ARG` values that are used only at build time. If you
-`LOM2M_MQTTS_TIMEOUT=30000` : configure timeout for MQTT client (ms)
-`LOM2M_MQTTS_CLIENT_ID_PREFIX="example.prefix-"` : can be used to setup a specific prefix to be used for the MQTT client identifier
These variables can be saved in a file, or used directly.
It is recommended to save the environment variables in a file and to add it in argument of the docker run command.
These variables can be saved in a file, or used directly. It is recommended to save the environment variables in a file and to add it in argument of the docker run command.
# Launch LOM2M with docker-compose
You can use the provided docker-compose file to test locally LOM2M (by default everything is configured to run locally. You can use this docker-compose as a template to deploy LOM2M).
You can find the docker-compose file in `lom2m/LOM2M-compose-local-build-LOM2M-only.yml`.
You can use the provided docker-compose file to test locally LOM2M (by default everything is configured to run locally. You can use this docker-compose as a template to deploy LOM2M). You can find the docker-compose file in `lom2m/LOM2M-compose-local-build-LOM2M-only.yml`.
To do so, you need to have docker-compose installed in your machine. If not, check [this page](https://docs.docker.com/compose/install/).
...
...
@@ -88,6 +88,7 @@ docker-compose -f LOM2M-compose-local-build-LOM2M-only.yml up --build
You can use the `-d` option to launch the services in detached mode.
To bring the services down use this command:
```bash
docker-compose -f LOM2M-compose-local-build-LOM2M-only.yml down
```
...
...
@@ -96,27 +97,27 @@ To perform more complex tests you can use the `LOM2M-compose-local-build-FULL.ym
# Launch LOM2M with available docker image
N.B.: before downloading the image, you must add credentials in your docker to be able to access the private repository. (i.e. gitlab.laas.fr:4567)
N.B.: before downloading the image, you must add credentials in your docker to be able to access the private repository. (i.e. gitlab.laas.fr:4567) (cf. [Docker login](https://docs.docker.com/engine/reference/commandline/login/))
4. Once your image is built, you can use it to run a container (cf. previous section, point 2)
# Compile LOM2M from source (script)
## Build LOM2M on a UNIX system (Linux / MacOS) (LIBC, GIT)
What you need:
- gcc
- git
...
...
@@ -199,12 +201,13 @@ cd $ESP8266ARDUINO/tests/host/bin/builtinLed
```
## Build LOM2M for ESP8266
You can use the provided Dockerfile to have a container all configured to build the target for ESP (cf. docker/LOM2M/Dockerfile-espbuilder). Or you can set up your own environment to do so. Be careful with MacOS systems and Arduino build (32 bits issues if you use Catalina or newer).
The given example is for use on LINUX.
If you want to use MacOS, you will need to download the Arduino IDE and point `ARDUINO` VAR to `\<path-to-Arduino.app\>/Contents/Java`.
The given example is for use on LINUX. If you want to use MacOS, you will need to download the Arduino IDE and point `ARDUINO` VAR to `\\<path-to-Arduino.app\\>/Contents/Java`.
What you need:
- python3
- JRE
- gcc
...
...
@@ -247,19 +250,18 @@ cd \<path-to-lom2m\>/src/server
./espbuildnflash.sh $sketch\<serial-port-dev\>
```
# Test the API
To test the oneM2M API, you can try any oneM2M request in HTTP or MQTTS.
A postman collection is provided in the source code (in `lom2m/tests` folder).
You can import the request collection in Postman client and the environment. The environment provides variables such as IP address, port, etc., to be configured for your specific deployment. By default, the parameters are set to be used locally with the emulator (Unix).
A postman collection is provided in the source code (in `lom2m/tests` folder). You can import the request collection in Postman client and the environment. The environment provides variables such as IP address, port, etc., to be configured for your specific deployment. By default, the parameters are set to be used locally with the emulator (Unix).
You can change the values as you like to test in a different deployment.
