Devices and Device Profiles

A data gateway has knowledge of each of its devices, stored in the system as Devices. Each device that communicates with Fusion Connect is registered with the system on the service UI using a unique identifier (such as a serial number) called a Device Code.

For any passive cloud adapter, all devices are required to include their unique identifiers in their messages. When the listener receives a message, then, it can compare this code to those of all its registered messages, and thereby connect the live message to the proper device, and so to the digital representation of the asset being monitored by the device. If the adapter finds no devices with the supplied code, it can screen the message out as from an unregistered device.

For active cloud adapters, the device code is used in determining the IP address/URL to poll, or sub-topic to which to subscribe, or a parameter in a web request.

Either type of adapter will then normalize the received data into a standard message object, where it is handled by the correct application.

Note: The Device API bypasses the cloud adaptation layer by allowing clients to create these message objects themselves and send them to the application server directly. For many types of devices, the device manufacturer defines a set of messages the device can send or receive, and exactly what information is included within those messages. In these instances, the device manufacturer will usually provide a device messaging/protocol document which defines the messages, their formats, and the fields within. This is known as device-defined messaging, and standard cloud adapters are specifically built to interpret data of these precise formats, then package them into hard-coded message types.

Not all device adapters function this way, however. Abstract adapters, for example, can communicate with any device sending JSON-encoded data over certain communication protocols. Other adapters communicate with physical gateways that package data in a certain way, but that route vastly different types of information from different end sensors; put another way, a cloud adapter can know how to extract a list of key/value pairs from the messages sent by a device type, but may have no idea as to what fields will be included in that list. Applications need to know ahead of time what fields will be included in these messages so users can create routines based on the anticipation of certain fields, so these types of cloud adapters need to know what fields to look for when parsing messages to send to the application server (or even what types of messages to look for).

As a result, an application has a concept of a Device Profile, which is a profile of how the application will use a registered device, which is assigned to the device when it is first registered. It designates the device type — and therefore which cloud adapter the system will use — as well as all the messages that the system can receive from that device.

Depending on the selected adapter, this device profile is configurable to different degrees: some device types allow message profiles to be defined from scratch (in which case the adapter will look for a field identifying the type of message), and others have some message types defined, but allow a user to add fields to them. This allows an administrative user to specify, for example, that a device will send JSON-encoded data to the UDP :: Abstract JSON adapter, and then define within the application which fields the message will contain within the JSON key/value map. This is known as application-defined messaging, where at least some of the details of communication are defined within an application.

For a device type using completely device defined messaging, a device profile is still used, but does little more than instruct the system to use one of the standard adapters for that particular device.