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.
Device Related Identification Summary
IoT Connector ID
Unique ID for the IoT Connector.
Unique domain name for use with the Device APIs, which is based off the IoT Connector ID.
Device ID is unique (within the IoT Connector) to the specific 'thing' or 'device' that is sending data to Exosite and will be tracked as a unique connected IoT device. Could be a serial number, MAC address, etc, but is fully definable by the IoT Connector manager and device firmware. This ID is used in addition to the IoT Connector ID to be unique in the Exosite platform, such as
A specific resource that data is sent to / read from under a unique device using the APIs. All devices within an IoT Connector have the same resources.
The resource used along with the Device Identifier and the IoT Connector ID create a unique data event identifier in the Exosite IoT Platform, such as
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
Example of unique IoT Connector device FQDN
Unsecured Communication Dev Mode Endpoint
If devmode is enabled (discussed in the Settings section, below), an additional endpoint is enabled for devices to connect to unsecured on port 80. This unsecured endpoint is nearly identical to the endpoint except
https is changed to
.m2. is changed to
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.
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
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.
The Settings page allows you to configure the
Public Key Infrastructure settings to control what protocol the devices will use to communicate with Murano, how they identify themselves and how they authenticate.
Determine how your devices communicate with the platform.
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¶
NOTE: Enabling the "Enable Developer Mode" checkbox allows unsecured HTTP communications on port 80. Unsecured HTTP communications can be read by third parties who are able to intercept the communications, thereby potentially exposing sensitive information. Although this setting can be useful during certain stages of device development, or in unique payload-level-encrypted systems, it should not typically be enabled.
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.
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
When provisioning a device, the device may present its own identity (assuming "Allow devices to register their own identity" is selected). Such devices will have an identity (such as a MAC address) that must match the specified format. It is possible for illegitimate devices to successfully provision; presented identity provides a slightly greater barrier due to its identity format validation.
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.
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:
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.
An authentication option available with the Token method can disable the use of TLS connections, allowing unsecured HTTP communication between a device and the Murano device gateway. The use of this option is highly discouraged and maintained in Murano as a development tool for easing the validation and development of firmware on a device connecting to Murano.
Token vs CIK
Then Authentication Token is sometime mentioned as "CIK" as compatibility with Exosite's legacy One Platform.
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."
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.
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.
Limitation: Resource values are limited to 64 KB.
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.
You can also disable the synchronization for a give resource, if so the "set" & "reported" will always be the same, and the data will not get pushed to the device. However the device can still actively access it on demand.
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.
There are two methods for uploading content from devices. The standard upload request can handle up to 100MB. For content larger than 100MB, please contact support.
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.
The logging events are not saved, so they can only be viewed in real time either by the Logs section in the IoT-Connector UI or Murano CLI. This is most useful in debugging and development applications.
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.
Event Log by Device Identifier (Identity)
When an Identity is given, event log entries for only that Identity address will be displayed in the IoT-Connector UI.
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.
Debug Log by IP Address
When an IP address is given, log entries for only that IP address will be displayed in the IoT-Connector UI.
Debug Log Messages
|With MQTT connections, this can happen for one of two reasons:
1. The device must send the
CONNECT message within 5 seconds after opening the connection. If that does not happen, Device2 will close the connection with the reason idle_timeout.
2. After successful authentication, the connection will be closed after a configured length of inactivity. The length will be set by the
KeepAlive field or, if not present or set to 0, a default value of 300 seconds.
|With MQTT connections, this will happen if the device attempts to send messages (other than the PUBLISH message to the $provision topic) before sending the
CONNECT message or the
CONNECT message sent does not contain authentication credentials.
With HTTP connections, if an already provisioned device attempts to re-provision, it must authenticate with the old credentials. If that does not happen, the request will fail with 400 not_authenticated.
|With MQTT connections, the
duplicate_connection debug log is generated when a new client connection replaces one which was already active for that same client.
|This error value indicates that a device attempted to provision when the domain it belongs to did not have the
presenter_identity option enabled and the device was not whitelisted.
|This means that the remote end of the connection, i.e. the device, has closed the connection unexpectedly, i.e. without sending the
DISCONNECT message first.
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.
As a typical use-case EveryCloud uses tags for claim and ownership management.
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.
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.
- 1 tag name can hold multiple values.
- When provisioning devices in Bulk, you can provide the tags as part of the provided CSV document.
Tags cannot be set through the Device API.