Device Management Edge 0.9.0
- Added support for Texas Instruments AM4378 SDK (relevant metalayer added).
- Added handling for pending JSON RPC requests. Requests are cleaned with an error response if the client doesn't respond within the maximum time limit. You can configure this timeout in
cmake/edge_configure.cmakeby modifying values
SERVER_REQUEST_TIMEOUT_THRESHOLD_MSfor Edge Core and
CLIENT_REQUEST_TIMEOUT_THRESHOLD_MSfor protocol translator C API v2 client. The entity that made the request will get
- Added handling for pending JSON RPC requests if the connection breaks. The entity that made the request will get
- Added certificate renewal JSON RPC and C APIs.
- Added KCM certificate
GETand KCM public key
GETJSON RPC APIs.
- Pelion Device Management updated to version 3.0.0 (from version 2.2.1).
- See the Client release notes.
- Updated Mbed TLS to version 2.17.0.
Added certificate renewal support to MQTT example, simple PT example and simple JS example.
systemdin the Raspberry Pi reference.
- New metalayer for Texas Instruments AM437x SDK.
Fixed the decoding buffer size in Base64 library.
Edge examples use
git submodules. Currently, the references are with git protocol. This requires the user to be authenticated to GitHub for the submodule init to work. You will see the following failure:
firstname.lastname@example.org: Permission denied (publickey). fatal: Could not read from remote repository.
Firmware update from
mortyversion of Yocto to
sumodoes not work and makes devices unusable. The differences in the device trees of different versions cause problems when starting the kernel after the update.
Edge communicates on behalf of multiple devices. There is an underlying limitation in the CoAP communication to effectively reduce the number of requests in flight to be one. On very heavy communication cases, this introduces extra latency. An example calculation:
- 30 mediated devices with a resource tree of 20 resources.
- Round trip time to Device Management is 200 ms.
- 10 KB registration message.
- Underlying Device Management Client sends data in 1 KB blocks and waits for an acknowledgement for each block. This equals to 10 * 200 ms = 2 seconds.
- During that time, other messages are not processed.
- If there are lots of notification updates passed to from Edge to Device Management, the responsiveness to Device Management initated requests may be hindered.
There is a maximum size limit to the full registration message, which limits the number of devices Edge can host.
- Maximum registration message size is 64 KB.
- Hosted devices with five typical Resources consume ~280 bytes (the exact size depends, for example, on the length of resource paths). This limits the maximum number to 270 devices.
- The more Resources you have, the fewer devices can be supported.
- The Edge device Resources are also included in the same registration message.
- Test the limits with your configuration and set guidance accordingly.
Protocol translators may cause side effects on devices connecting through another protocol translator if both use the same names for the devices. Edge Core identifies the devices by their name. It is not always clear which protocol translator owns the device, and clashing names can cause unknown behavior. Ensure that devices have unique names across the protocol translators. For example, add a prefix or suffix based on the protocol translator name, which must be unique.
DELETE(CoAP/LwM2M) operation is not supported.
Devices moving between Edge instances have corner cases that are not supported. You need to deregister the devices from the current Edge instance before connecting to an another Edge instance.
Device lifetime tracking of mediated devices is not supported. Devices have the same lifetime as the Edge device. The default is one hour. The
#defineto change the lifetime is
glibversion used by default (2-48.2) can raise thread sanitizer errors. Updating
glibcan reduce those errors.