IoT Platform Integration

By default, YuDash LYNX is configured to connect to YuDash cloud. This is subject to purchase of YuDash cloud or YuReCon subscription.  In such cases, "Use YuDash Cloud " is check marked. In this case, all custom cloud settings are ignored. LYNX will attempt to connect pre-configured device credentials on YuDash Cloud. For using external cloud (or on-premise) server, the applicable cloud protocol has been selected.

1) Selection of Cloud Protocol

• Uncheck "User YuDash Cloud". This will disable use of YuDash cloud. 

• Select the Cloud protocol:  MQTT or HTTP

• The Offline mode is used when no cloud server is applicable. This is applicable for (a)  LYNX or Yureca is used as on-premise remote display units and  (b) debugging and setup purpose with field instruments for modbus.

HTTP is a defacto TCP/IP protocol for cloud communication. YuDash LYNX supports POST REST API for sending data to HTTP Server. Both HTTP and HTTPS versions are supported. The HTTP headers can be configured to support  various authentication types. 

Following are settings in LYNX to configure connection to MQTT server:

1. HTTP Server : The URL of HTTP server accessible on the network. Alternately, unique IP address can be provided. This may be required for a local deployment.

   • Remove any prefixes (http:// or https://) in the server name.

   • Remove any suffix APIs from server name. They are provided in API below.

2. HTTP API : The API name (similar to subdirectory) which will accept POST request. This will typically start with "/".

3. HTTP Port:  The port on which HTTP server is running. 

4. HTTP SSL Enabled: Check this box for enabling HTTPS using SSL. This is recommended for production applications.

5. HTTP Headers for Authentication:  HTTP supports various authentication options. The authentication header keys and values are filled in section. 

   • These are sent as HTTP headers to server for handshake.

   • The UI supports two headers. In case multiple custom headers are required, it can be configured in JSON configuration. 

Actual usage details are covered in integration guide with popular IoT platforms in subsequent section.

HTTP/MQTT configuration defines the credentials and API to connect to server. Next step is to define the format in which process data will be sent to cloud.

JSON is a popular format for data exchange on cloud. LYNX supports JSON and TEXT formats to send data to cloud servers. LYNX has pre-configured JSON templates to suite popular IoT platforms. In some cases, TEXT payload over MQTT is also popular. For this, we have inbuilt YuDash Text Generator.  

4.1) Payload Components 

In principal, following are main information components that are packaged in payload:

4.1.1) Process Data 

• Process data is key-value pair information collected from the instruments by LYNX. Let's understand this with an example:  LYNX reads a field instrument and receive a numeric value. For example: Voltage read as  volt1 with value 224.45. Or a furnace temperature: variable temp_furnace1 with value 598.0. So, we have volt1=224.45 and and temp_furnace1=598.0.  

• So, the key is the variable name defined in MODBUS (or similar) setting and the value is floating point number read from instrument. These key-value pairs have to pushed to cloud, encapsulated in selected JSON format.

• In many cases, there may be 80-90 such key value pairs read in a given cycle. Depending on server or protocol architecture, we have to be send 8, 16 or even just 1 key-value pair in a single communication. All these variations are handled by LYNX through dpPerPacket. This will be explained later.

• In princical, this is the main  

 4.1.2) Device Headers/Identifiers

• For generic IoT platforms, typically one field gateway is uniquely identified by a credential (Access Token). But in many servers (typically HTTP), there may be a single API and credential handling data for multiple devices. In this case, the device information is passed in the payload to uniquely identify the field asset/machine/instrument.  

• Let's understand this by an example: There is a MES server (on premise or on-cloud) for a manufacturing firm. Manual entries are being done by operators and executived. Now, some of machines are IoT enabled to push machine process data periodically. In such cases, typically a user name is created, which will be shared across all machine. And each machine name (unique identified as per MES) will be added in payload. For example: machine_number has a value  YDPL/FRN/402 for a given machine. So, this key value pair will be sent along (1). And server API will process accordingly.

• In other words, it is kind of meta-data, which is part device (remains fixed for a device) and sent along with real-time process information.

• LYNX supports two device headers (key and value pairs). They will be added in payload similar to process data. 

• The checkbox "Send Device Headers" has to be checked to enable sending of headers. If it is not checked, device headers are not sent to server.

4.1.3) Time Stamp Information

• In most of servers, the time of receipt of a data packet received at server is taken as its time-stamp. 

• LYNX process and send the data packets immediately to cloud. So, delay in packet transmission and multiple register reads may add very small time delay between actual capture of data and time stamp recorded on server. In most of cases, this is very much non-critical and ignored. 

• In most cases, the cloud servers store time-stamp in UTC (universal time) and they are displayed in local time on web browsers. So, there is no concern or error about time zones.

• Most of cloud servers accepts options of accepting time-stamp along with process data. This may be the case when we want to populate a data point from history.

• For RTC enabled LYNX variants, LYNX supports sending of Time Stamps in a flexible matter.

4.1.4) Payload JSON Keys 

• All information in JSON is sent has key-value pairs. In many cases, the key names are defined in JSON format by platforms for categorization.

• For this purpose, LYNX has two user provided input strings (Payload Gen Key#1 and Payload Gen Key#2). These will be used by JSON payload generator engine depending on format.