Version 2.25 (2018-04-10)

Important notices

Technical documentation available online

All technical documentation for Managed IoT Cloud, including API specifications, Release notes and Getting Started Guides, are available online: https://docs.telenorconnexion.com/mic/

Features

Device Management with Device Campaigns

We are now launching enhanced device management capabilities built on AWS IoT Device Management, on top of which we have added support for the MIC domain model and permission model.

The Device Campaigns can be used to remotely update settings, instructions, data or firmware on large populations of Things. A dedicated user interface for device managment tasks is available in App Board under the Settings top menu item, but the functionality can be reached from the Cloud API too.

A Device Campaign is called a Job and it is executed on one or many defined Targets where each target is a Thing Group.

Thing Groups

Thing groups allow you to manage several Things at once by categorizing them into groups. You can create, update, delete and list groups and for each group you can add and remove Things.

You add things to a group either from the complete Things List, or by using the Things Filter. You can either cherry-pick selected Things, or add all Things that matches the filter criteria.

Jobs

A Job is the actual description of what shall be done by the Things specified in the Targets for the Job. When creating a Job, you specify the Targets, i.e. a list of Thing Groups on which the Job shall execute on.

There are two types of Jobs

  • Snapshot Job
    • One-time Jobs that are executed for all things in the Targets
    • Once a Snapshot Job is started, the Targets cannot be changed (no Things Groups nor Things can be added or deleted)
    • After all Things in the Targets have completed the Job (or report that they are unable to do so), the Job is complete
  • Continuous Job
    • A Continuous Job runs continuously and is executed when a change is detected in the Targets. E.g. the Job will execute on a Thing when the Thing is added to a Thing Group which is part of the Targets, even when adding it after the Job was completed by all Things originally in the Thing Group
    • A Continuous Job can be used to onboard or upgrade devices as they are added to a Thing Group, e.g. initial bootstrapping or initial configuration
    • You can make a Job continuous by setting an optional parameter when you create the Job
    • Continuous Jobs will never be completed - they exists until deleted

The Job Document is the description of the remote operations to be performed by the Things. It can contain any information your Things need to perform a Job. For example, the Job document may provide the instructions required by the Thing to execute a firmware update, or it could contain instructions corresponding to a batch change of a resource or any other setting or command on the Thing. The Job Document is UTF-8 encoded JSON documents and will most likely contain one or more URLs where the Things can download an update or some other data.

When starting a Job, MIC sends a message to all Things in the Targets to inform that a Job is available. The progress of the Job can be followed as the Things reports their status performing the tasks in the Job. Once finished, each Thing reports complete and if it was not able to complete the Job, that is reported too.

In order for Device Campaigns to work end-to-end, the Thing application need to support the communication mechansims used for device management and the instructions used in the Job Document. Documentation for how to enable this is available at the MIC documentation site.

The MIC Connector has full support for Device Management incl Device Campaigns.

In order to have controlled roll-out of new firmware and other updates, Device Campaigns are limited to notify 100 Things per minute about the Job.

TCP Proxy over MQTT

In addition to the already available TCP proxy, we are now launching an additional TCP Proxy that sends data over MQTT. While the normal TCP Proxy is intended for temporary use when a TCP client application needs direct access to a Thing, the TCP Proxy over MQTT targets more continuous use, e.g. connecting Things to a SCADA system.

The TCP Proxy over MQTT establishes a TCP connection to the Thing over MQTT and sends all TCP payload over MQTT. This ensures security in the transport to/from the Thing since the MQTT channel is encrypted using TLS.

A TCP connection is established by calling the TCP Proxy API (part of Cloud API) with the Thing ID. The proxy is activated and IP address and port number is returned to be entered in the SCADA system / TCP Client Application within 60 seconds. Should the connection somehow go down, the sessions are persisted and connections will be set up again to ensure reliability.

The service is limited to reasonable amounts of data, e.g. larger file transfers cannot be performed. Payload format does not need to be JSON.

New Cloud API: System Management API for Storage Retention

The System Management API contains controls for storage retention. By calling the API you can specify what retention policies you want for

  • Raw Observation Retention (the S3 data lake) - Retention can be specified by day
  • Indexed Observation Retention (the Elastic Search Observation index) - Retention can be specified by month

Per default, retention is not enabled (i.e. by default, no data is removed automatically).

IMPORTANT NOTE: Retention shall be used with great care - data older than the retention policy will actually be deleted and cannot be recovered.

Minor improvements and corrections

Numerous minor enhancements and bug fixes are delivered by the new release, including:

  • An extract of personal data stored in MIC can now be requested - Such requests shall be sent to Telenor Connexion Technical Support and MIC user name shall be included in the request.
  • Improved performance in Rule Engine.
  • Further improvements in App Board on the issue with “Not found” message which also causes the user to be logged out.
  • Fixed error in documentation on Update Thing in the Thing Management API.
  • Fixed issue in App Board where desired state for sub things was displayed wrong if the desired value was “0”.
  • Fixed issue in rule engine message content: Now messages can contain both old (before last update) and new value (last update) of a resource. Previously, only the new value was available.