Everyware Software Framework Developer's Hub

Everyware Software Framework (ESF) is an enterprise-ready IoT Edge Framework distributed and supported by Eurotech. Based on Eclipse Kura, the open source Java/OSGi middleware for IoT gateways, ESF adds provisioning, advanced security, remote access, diagnostics monitoring. It supports ready-to-use field protocols (including Modbus, OPC-UA, S7, FANUC, J1939, J1979, BACnet, IEC 60870-5-101, IEC 60870-5-104, DNP3, M-bus), MQTT connectivity, and a web-based visual data flow programming to acquire data from the field, process it at the edge, and publish it to IoT Cloud Platforms. ESF features full remote device management through its integration with Everyware Cloud, Eurotech’s IoT Integration Platform.

Get Started

MqttData Transport Service Configuration

The MqttDataTransport service provides the ability to connect to a remote broker, publish messages, subscribe to topics, receive messages on the subscribed topics, and disconnect from the remote message broker. To use this service, select the MqttDataTransport option located in the Cloud Services area as shown in the screen captures below.

The MqttDataTransport service provides the following configuration parameters:

  • broker-url - defines the URL of the MQTT broker to connect to. For the Everyware Cloud sandbox, this address is either mqtt://broker-sandbox.everyware-cloud.com:1883/ or mqtts://broker-sandbox.everyware-cloud.com:8883/ for an encrypted connection. (Required field.)

  • topic.context.account-name - defines the name of the account to which the device belongs.

  • username and password - define the username and password that have been assigned to the device by the account administrator (generally username is account-name_broker). (Required field.)

  • client-id - defines the identifier of the MQTT client representing the device when connecting to the MQTT broker. If left empty, it is automatically determined by the client software as the MAC address of the main network interface (in general numbers and uppercase letters without ':'). This identifier has to be unique within your account. (See screen capture below.)

  • keep-alive - defines the "keep alive" interval measured in seconds. It specifies the maximum amount of time that should pass without communication between the client and the server. The client will ensure that at least one message travels across the network within each keep alive period. In the absence of a data-related message during this time period, the client will send a very small MQTT "ping" message that the server will acknowledge. The keep alive interval enables the client to detect when the server is no longer available without having to wait for the long TCP/IP timeout. (Required field.)


Keep-alive and TCP idle timeout

The keep-alive interval may "conflict" with the TCP idle timeout set at the TCP/IP level. As a best practice the TCP idle timeout should be at least 1,5 times the keep-alive time interval. If the TCP idle timeout is less or equal the keep-alive, the MQTT connection may be dropped due to the TCP idle timeout expiration.

  • timeout - sets the timeout used for all interactions with the MQTT broker. (Required field.)

  • clean-session - controls the behavior of both the client and the server at the time of connection and disconnection. When this parameter is set to true, the state information is discarded at connection and disconnection; when set to false, the state information is maintained. (Required field.)

  • lwt parameters - define the MQTT "Last Will and Testament" (LWT) settings for the client. In the event that the client unexpectedly loses its connection to the server, the server publishes the LWT message (lwt.payload) to the LWT topic on behalf of the client. This allows other clients (subscribed to the LWT topic) to be made aware that the client has disconnected. LWT parameters that may be configured include:

    • lwt.topic
    • lwt.payload
    • lwt.qos
    • lwt.retain
  • in-flight.persistence - defines the storage type where in-flight messages are persisted across reconnections. They may be stored in memory, or in a file on the disk. (Required field.)

  • protocol-version - defines the MQTT Protocol version to be used. This value may be 3.1 or 3.1.1 (April 2014).

  • SSL parameters - define the SSL specific settings for the client. SSL parameters that can be configured include:

    • ssl.default.protocol
    • ssl.hostname.verification
    • ssl.default.cipherSuites
    • ssl.certificate.alias

Updated 11 months ago

MqttData Transport Service Configuration

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.