Introduction
LOM2M is a message oriented middleware implementing the oneM2M standard and its REST API. The aim of the platform is to be used as a gateway in an IoT solution deployment. (MN or ASN in oneM2M terminology)
Have a look to LOM2M technical sheet.
Most of the acronyms used in this wiki are oneM2M acronyms. To refer to those acronyms cf. oneM2M technical specifications. Some of them are defined again here:
Acronym | Definition |
---|---|
IoT | Internet of Things |
CSE | Common Service Entity |
IN | Infrastructure Node |
MN | Middle Node |
Default configuration:
Config | Value |
---|---|
HTTP port | 8282 |
Originator AE Admin | admin:admin |
Remote CSE ID | in-cse |
Remote CSE Name | in-name |
Remote CSE port | 8080 |
cse-id |
mn-cse-<MAC:ADDRESS> or mn-cse-DEBA7AB1E042 (UNIX) |
cse-name |
mn-<MAC:ADDRESS> or mn-DEBA7AB1E042 (UNIX) |
(These values can be changed at build time or dynamically on UNIX targets)
Target deployment
The typical target deployment is a power constrained gateway (microcontroller). Here are some example of memory usage regarding the target:
MCU ESP8266:
- ~500KB (sketch)
- ~50KB RAM
UNIX based systems:
- at least 5MB storage (executable size)
- at least 3MB RAM
DOCKER container:
- at least ~10MB for compressed image (precompiled) LOM2M Dockerfile is based on alpine to run the compiled executable.
(These sizes may vary regarding to the enabled features)
Resources
Global Resources
- Install & Launch
- Features & Capabilities
- Global behavior
- Documents: Software Design Document, test reports, etc.
Specific feature documentation (not included in opensource version)
Node-RED nodes:
Gitlab configuration, Continuous Integration (CI)
A continuous integration is enabled on the project. It is configured to trigger different tasks regarding commits, merge requests, etc. For more details about this configuration, cf.:
Other information
Details around LOM2M project
References to oneM2M specifications
- TS 0001: oneM2M Architecture
- TS 0004: oneM2M Protocol