Release Notes

Managed IoT Cloud is usually released every three weeks and in this section you can find the release notes for all releases.

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.

Version 2.24 (2018-03-20)

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

Thing Management API now exposes Sub Things

It is now possible to search for Sub Things using the Thing Management API. To use the new feature, you add a type parameter to either the FIND action in the Thing Management API, or if you’re using the Cloud REST API, add the type parameter to the body of the thing/find request. For more information, see https://docs.telenorconnexion.com/mic/rest-api/thing-management/#find

Minor improvements and corrections

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

  • Improved logic for enabling and disabling the cancel/delete/save buttons in Unit management
  • Improved rendering of Thing Type Management table
  • RuleEngine can now properly decode 0 as a value when using NotEqual expressions
  • Older style Elasticsearch queries are now being properly filtered within Elasticsearch 5
  • It is no longer possible to create a Thing without first creating a Thing Type
  • Fixed issue related to that geo-fence rules with the isInside and isOutside operators could trigger on observations that did not contain the latlng resource
  • The Rule Engine can now properly handle resources that are sent in with different case vs what has been defined in the Rule definition

Version 2.23 (2018-02-27)

Important notices

API changes - coming deprecation

CREATE_VIRTUAL_RESOURCE in the Resource API will be deprecated in a future release. Instead CREATE_RESOURCE shall be used with a metadata flag “isvirtual: true” set.

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

Thing Type Resource Management

In this release we launch major enhancements of the Resource Management functionality (found in the Settings -> Thing Types menu). In summary, many aspects of the data model for a Thing Type can be controlled, and the configuration is refelcted throughout the MIC Platform and App Board.

Firstly we have added the possibility to add new resources from the list of resources view. In the resource details view (that is also displayed for newly added resources), most attribute fields can now be edited; resource name (only for newly created resources), label (mandatory field), unit, allow set (controls if resource updates can be sent to the Thing through the Cloud API, or not), and virtual (controls if resource data is sent to the Thing or stored in the cloud only).

We have also modified the behavior for configuring setting resources from widgets

  • Configuration of the available values to set has moved from the widget edit to the Resource Details edit in Thing Type Resource Management section
  • Widget edit now only contains the option “Enable set value” (Yes/No)

In addition we have moved virtual resource creation from widget edit to Resource Details edit in Thing Type Resources Management in order to have a consistent management of resources in MIC.

Finally we have added a more robust handling and management of Units (more info below). For a specific resource, you select the Unit from the list of available Units. The Unit need to exist in the Unit list to be able to add it.

To sum up Thing Type Resource Management, all the resource attributes are now is use in App Board, meaning that you can control how the resource shall be handled and displayed in the MIC Platform and App Board.

  • Label: Label is now used in App Board instead of resource name. Exceptions: Resource name is still used when creating formulas in “Custom Widget” and in “Rule edit”. For all existing resources, resource name have been copied into the label attribute.
  • Units: Units are now displayed next to the value in App Board if the resource is configured with the Units attribute. In a specific widget, you can override the Units by entering the desiered value for unit in widget edit (space means no unit). Existing units in widgets have been kept as overriding the default (global) units.
  • Setting of a resource: In Thing Type Resource Management you Allow set resource - if the resource shall be possible to set from the Cloud API (incl App Board). For a resource that is allowed to be set, a widget can be enabled to set the resource (configured in widget edit). For all existing resources, Allow set has been set to “Yes”.
  • Virtual: A virtual resource is not representing any “real” resource on a Thing, but exists only in the cloud platform. It is always allowed to be set. Existing virtual resources have been migrated to the new resources management functionality.

Unit Management

A new interface and API for managing units in MIC has been added. By enabling a stricter definition of unit metadata, typos can be avoided and data from different sources can be compared with greater confidence.

Units can only be defined by a root level user, ensuring a system-wide definition.

It is possible to override the global unit definition per widget, if required. This is done in widget edit.

Enhanced webhook mechanism targeting Salesforce integration

Webhooks can be used as a rule action to integrate with 3rd party systems. In the new release, the possibility to add authentication and custom headers to a webhook has been added.

This functionality is generic, and useful in many integrations scenarios. As an example it supports integration with Salesforce IoT Scale input streams.

De-grouping of resources in All Things Dashboard

In previous versions, resource data in the All Things Dashboard (e.g. All Things list) was grouped by resource name. This created ambiguity in certain situations, when two different thing types had the same naming for resources. Example: a resource “name” from one thing type might, or might not, contain comparable data as a “name” resource on a different thing type.

To avoid this, the grouping is now done on the combination of thing type and resource name.

There is one exception to this - resources reported on the TCXN payload convention (https://docs.telenorconnexion.com/mic/thing-api/conventions/) are still grouped across thing types.

Minor improvements and corrections

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

  • Minor documentation updates and bug fixes to the Cloud REST API.
  • After a period of inactivity in App Board, the error message “Not Found” was sometimes shown, forcing the user to re-login without any further explanation. This has now been improved and expired logins are handled in a more user friendly way.
  • Improved styling of lists in Firefox
  • Fixed issue with rule criteria summary in rules edit.

Version 2.22 (2018-02-06)

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

Support for LoRa networks based on the TTI (The Things Industries) network server

We are introducing support for LoRa networks based on the TTI network server. MIC is driving the provisioning, allowing users of MIC to provision and ensure communicate with LoRa devices in a seamless way, all driven by MIC App Board and APIs. LoRa devices are mapped to MIC Things. To connect a LoRa device only a few simple steps is needed

  • Create a Thing in MIC, then app_key, app_eui and dev_eui are generated automatically. dev_eui can be defined by the user in the External ID field, e.g. when device has pre-defined Device EUI.
  • TTI automatically creates the device representation with app_key, app_eui and dev_eui values from MIC
  • Enter the app_key, dev_eui and app_eui in the device firmware and connect to the LoRa network (TTI network server).

Since version 2.6, MIC supports script field type for Thing Types. This is used for payload encoding and decoding, i.e. translating the LoRaWAN byte buffers <=> JSON documents that can be interpreted automatically by MIC giving a seamless experience visualizing the sensor data in dashboards widgets.

Since version 2.7, MIC have support for LoRa Networks based on the Semtech network server. Over time, we will discontinue the support for the Semtech network server. Exact time will be announced at a later stage.

Retry and confirmed delivery of webhooks

As a Rule action, webhook is a powerful tool for simple integrations and calls to 3rd party systems. In this release we introduce confirmation of webhook delivery, including up to three retries if not confirmed by the 3rd party system. The retries happen after 1, 10 and 60 minutes. Typical use cases are delivery of alarms and important events to 3rd party systems.

API to manage Resources and their attributes

We have added functionality to the Resource API to support management of Resources and their attributes

  • Resource – create and update Attributes
  • Resource Name – create. Mandatory.
  • Resource Label – create and update. Is by default set to Resource Name. Mandatory.
  • Resource Unit – create, update and delete. Is by default empty. Not mandatory.
  • Allow set Resource – create and update. Is by default set to “Yes”. Mandatory. Allow set is always “Yes” for a Virtual Resource.
  • Virtual Resource – create. Is by default set to “No”. Mandatory.

In the next release, App Board will support the above described management of Resources and their attributes. Details in next Release Notes.

Resources attributes are used in App Board

Resource attributes introduced are now used in visualizations throughout App Board. Examples are

  • Resource Labels are used instead of Resource Names. Exception: When creating formulas in “Custom Widget” and in “Rule edit” we will keep Resource Name
  • Resource Units are displayed next to values

Minor improvements and corrections

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

  • Added Set Resource capability to the REST API
  • Improved usability in App Board Resources Management section, including sorting on all columns in the Resources list
  • The filtering behavior of the new selection tools in Rule edit has been improved for increased usability
  • The rendering of the selection tools in Rule edit has been improved in Internet Explorer 11 and Firefox
  • The rendering of the new process widget has been improved in Internet Explorer 11
  • Fixed issue when creating a user: Email is no longer required when SMS is used for verification
  • Fixed issue with Elasticsearch indexing of larger Thing shadows
  • Fixed issue with Elasticsearch where a user in some cases couldn’t see observations for Things belonging to a subdomain

Version 2.21 (2018-01-16)

Important notices

Changes to the APIs due to upgrade of Elasticsearch

As previously announced, since release 2.18 MIC has support for Elasticsearch versions 2.3 and 5.5. During an interim period intended to facilitate migration to Elasticsearch 5.5, the version used for each individual Customer account can be configured. The upgrade will impact the Observation API, Thing API and Event API since these APIs allow developers to query Elasticsearch directly, and there are differences in the Elasticsearch query syntax between the two versions. Depending on how these APIs are used, updated queries might be required in bespoke applications. If you are using the Elasticsearch query capability in the any of these APIs, you are kindly requested to contact Telenor Connexion for joint establishment of a migration plan.

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

Thing Type and Resources Management

We are introducing a tool to manage all your Thing Type Resources and their attributes. It is found in a new section in the Settings top menu, called Thing Types. In this release we are introducing

  • List all Thing Types and the domain where they are defined
  • List all Thing Type attributes (per Thing Type). The Thing Type attributes are ID, Label, Description and Domain
  • List all Resources per Thing Type
  • List all Resource attributes (per Resource). The attributes are Name, Label, Data type, Unit, Settable (if Cloud API can change the state of the Resource) and Virtual (If the Resource is reported from the Thing or just Virtual) No edit is available at this point, it will be added in later coming releases.

Process Widget

In the process widget customers can upload an image of a machine or a machine process and add overlay resources to get a visual monitoring view of the process with multiple resources.

REST API

All API:s are now available as REST, please see online API documentation for details.

Improved selection tool in rule edit

In rule edit, both the selection of Domains and Thing Types has been improved with search to cater for better usability, especially when number of Domains and Thing Types become large.

Added sorting in the Things Lists

Almost all of the columns are now possible to sort on, including added columns containing resources. A few limitations apply: it is not possible to sort of Last Heard From and

Minor improvements and corrections

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

  • Improved security at login by not revealing whether a user exists if some part of the user credentials are incorrect
  • Fixed issue with rule triggering under certain circumstances when using backdated observation and time comparison