IoT Connector Management¶

This document covers Exosite's IoT Connector management feature set and provides descriptions of each component's functionality. All device connectivity offerings are located within the realm of your IoT Connector Solution page of your Exosite account.

Unique IoT Connector information¶

Your IoT Connector has a unique identifier called the IoT Connector ID. The connector id is used as the service identifier for integration with applications like ExoSense.

Device data events in Exosite's IoT Platform are uniquely identified using the connector id, device id, and device resource to ensure it's know what the data is for.

In the IoT Connector management view, you have access to the IoT Connector ID and also the unique device fully qualified domain name (FQDN) that is used for the API that your devices will interact with Exosite's IoT Platform with. The

https://09iolmnn8090ol.m2.exosite.io

Devices¶

The Devices tab is where you will add, list, and manage all your devices (real or simulated). Once you have populated your list of devices, you will have the capability to search, sort, and filter your device list to suit your needs.

Adding Devices¶

When you click the + NEW DEVICE(S) button, you will have the option to add one device or many devices at once. More information and examples for bulk addition of devices can be found in the Provisioning Guide

Locking¶

This feature allows Murano administrators to revoke the communication privileges on a per-device basis. Marking a device as locked will cause all connection attempts by the device to be ignored. This can be useful, for example, in development or during in-field management to temporarily disable device communications.

Settings¶

The Settings page allows you to configure the Protocol, Identity-Format, Authentication, Provisioning and Public Key Infrastructure settings to control what protocol the devices will use to communicate with Murano, how they identify themselves and how they authenticate.

Protocol¶

Determine how your devices communicate with the platform.

• HTTP Device API
• MQTT Device API

ALPN support (dual protocol)¶

It is possible for a device to switch protocol independently from the global setting by using the ALPN flag upon connection. For example this enables MQTT based devices to download files over HTTP.

Unsecured Communication Mode¶

Identity Format¶

This feature defines how connecting devices must identify themselves or be considered invalid and ignored in successive communication attempts. Devices are identified differently based on the authentication method chosen—Token or TLS Client Certificate. In the case of Token authentication, the identity of the connecting device is determined by the id field of the HTTP Device activate API method. In the case of TLS Client Certificate authentication, the identity of the connecting device is determined by the common name /CN value of the client certificate. In both of these methods, the Identity Format must be adhered to in order for the device to be recognized in communication requests.

NOTE: Devices that attempt to connect that do not match this format will be ignored for security reasons.

Provisioning¶

The Presenter Identity configuration setting allows devices to identify and provision themselves at the time they first connect to Murano. The Presenter Identity setting simply means that devices connecting to a Murano device gateway do not need to have their identity be whitelisted in advance and that the Murano device gateway will auto-whitelist the identity the device "presents."

When set to true (default), allows devices to provision themselves and any device identity to communicate with the Murano device gateway. When set to false, devices connecting must first be whitelisted onto the device gateway in order for its requests to be honored.

See our provisioning documentation for a complete guide. Provisioning Guide

IP Whitelisting¶

IP Whitelisting can be used to restrict device provisioning. The IP whitelisting manages known IP addresses that devices will connect from when connecting to Murano for the first time. This feature is useful to IoT vendors working closely with hardware manufacturers. If a connecting device's requests originate from an IP address not in the configured whitelist, then the device will be ignored. Once the device has connected from an IP address in this whitelist, it can make successive requests from any other IP, and its requests will be honored.

Authentication¶

The authentication setting defines how devices needs to security identify themselves to the cloud. Devices connect to Murano using their unique IoT-Connector domain. This fqdn (fully qualified domain name) can be found in the IoT-Connector UI as well as via the Device2 getGatewaySettings API method. Secure connection relies on TLS protocol and we invite you to our TLS reference page.

Also see our provisioning documentation for a complete guide.

The following options are supported for authentication:

Token¶

When the Token method of authentication is selected, a device can provision a private authentication Token to be used in subsequent communications to uniquely identify and authenticate itself to the Murano device gateway. If provisioning is disabled, then device authentication Tokens must be managed via Murano CLI and UI tools and manually associated and stored on the device.

Password¶

When the Password method of authentication is selected, a device can provision credentials for the given Password (at least 20 characters) to be used in subsequent communications to identify and authenticate itself to the Murano device gateway. If provisioning is disabled, then device authentication Password must be managed via Murano CLI and UI tools and manually associated and stored on the device.

TLS Client Certificate¶

When the TLS Client Certificate method of authentication is selected, a device uses a unique X509 private and public key that Murano uses to both authorize and identify the connecting device. Murano will use the X509 credentials (which can be provided by a PKI vendor or it can be self-signed) to identify and authenticate the device. Certificate based authentication has two flavors:

Without certificate verification¶

This allows clients to connect to Murano with a certificate (self-signed or signed by a Certificate Authority). Murano will extract the common name /CN=<value> from the certificate and use the <value> to identify the client. Then, it will use the certificate as a password to verify the client's authenticity.

With certificate verification against a Certificate Authority (CA)¶

It is possible to enable and configure a Certificate Authority (CA) for an IoT-Connector under its Protocol settings. If CA is enabled and configured, the certificate presented by the client will be verified against the configured CA. If the configured CA was its issuer and certificate has not yet expired, authentication will be successful. Otherwise, authentication will fail. If CA has not been enabled or it has been disabled and a client connects with a certificate, authentication will fall back to the authentication "Without certificate verification" method.

Public Key Infrastructure¶

A Public Key Infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use store, and revoke digital certificates and manage public-key encryption, see our provisioning documentation page.

** note "This option is only relevant for TLS Client Certificate Authentication."

Resources¶

The Resources page is where you may add attributes (or "alias"es) to your devices (e.g., temperature, status, etc.). Resources represent a device's digital twin in the cloud, like a data model shared by all devices. A resource is identified by its alias, and the resource's unit (e.g., °C) can be specified to further clarify the alias's measurement. It is possible to restrict values to ranges (0-100) or to discrete values ("open", "closed", "jammed"). The current resource value for a given device is visible when browsing the device in the project and is accessible to scripts, which can then act on reported values in any number of ways.

ExoSense has a defined schema for it's resource use.

When you click + NEW RESOURCE, you will be prompted to choose your data format.

• String refers to a unicode sequence of characters.
• Number refers to any positive or negative value.
• Boolean refers to a binary variable (i.e., true or false).

You will also be given the option to "modify this value from the cloud." Leaving this box unchecked will allow only the device itself to write to the alias. Checking this box will allow other applications to modify the value of the resource, depending on the permissions you have put in place.

Undefined resources¶

Devices are not restricted to write to only defined resources. Devices write to "alias"es which may or may not correspond to defined resources. All device messages are sent via the Device2 Murano micro-service event handler to the script and can be processed as other device message, but only writes to defined resources will have the value stored in the device state under the "reported" values, available to devices via "read" and visible when viewing the device data.

Set resource to send data to the device¶

Typically, devices report values to resources that are "read-only" in the cloud. It is possible to enable sending data to the device with the "Send data from the cloud" option, which can be used to support command-and-control behavior. This is done through the setIdentityState Device2 Murano micro-service function. All resources have a "reported" value which represents the last value written by the device (using the write API). Resources that are cloud-writable have an additional "set" value containing the value to send to the device. The device is then expected to acknowledge the received value which updates the "reported" to match the "set". Devices will use either the read API or the long-polling API to receive control requests and then write appropriate resource updates to reflect its having acted on the request. When fetching the device state from the scripting you will have access to both values.

Content¶

The Content page serves as a secure file store powered by the Murano Content Micro-Service. Click “+ NEW CONTENT” and follow the prompts to upload your files. Each content item has an ID, a MIME type, a size (in bytes), and a timestamp. In IoT-Connector, those files can be accessed by your devices through the device API. Devices may list available content, get content info, download and upload content using the HTTP Device API.

There is no restriction as to the kind of content that can be made available to devices. Files can contain anything from audio/video content to config data, but the typical use case is to store firmware updates. For content that gets updated over time, such as with new firmware versions, it is recommended to include in the ID some kind of version tag. Whether this approach is taken or the content is updated in place and a timestamp is used to differentiate, devices will need a means to know which version they are at. Exosite recommends storing this information in a Resource. Additionally, if the resource is cloud-modifiable, the device can be notified when new firmware is available.

Logs¶

The Logs page is where you may access a connection log of each device’s meta data and a "live" view that displays events associated with a product's FQDN that came in while the Murano product UI was running.

There are two types of logs: "events" and "debug". When devices connect, disconnect, make provision attempts, and publish data, these events will be logged to the "events" log. When a failure occurs during a device connection attempt or other device activity, those failures get logged to the "debug" log.

Device Connection Debug Logs¶

The debug log can be filtered to a specific IP address. When the IP address filtering is enabled, it allows additional debug information to be logged that typically happen before a connection is even associated to a domain or a device would have authenticated. This helps with debugging problems associated with TLS negotiation, or issues related to a missing SNI or failed device authentication. Without an IP address specified, there would be no way to associate such failures to any specific domain.

Tags¶

Tags are static device metadata enabling fast and flexible devices search and filtering.

Tags are different from Resources in an IoT Connector. Resources hold device data sent to or by the device. Tags hold meta information and are not accessible to the device.

A tag is a pair of a Tag Name and a Tag Value. Multiple pairs with the same Tag Name with multiple values are possible.

Searching by Tags¶

Tags' main benefit is to enable efficient device search & filtering. On the IoT-Connector Devices tab, each entry have their tags displayed under the tags column.

By default the list of tag names is visible. You can display values for a given tag by selecting the tag name in the header drop down.

This will automatically filter all devices having a value for this tag. Once selected, you can now search devices by the selected tag value in the search box.

Adding tags¶

On each device details page, you can have a full view and control of the tags. Including the ability to add, update or delete Tags.