Supported Edge Protocols

The Losant Edge Agent gives you the ability to read and write to common edge protocols within a Local Area Network.

Edge Compute Diagram

The Agent supports the following protocols:

How to Use

For each supported protocol, in order to read and write to devices, Edge Workflows are required.

Reading Data Using Local Protocol

In most use cases that leverage a local protocol, you can build an Edge Workflow that reads a local protocol on a timer and reports data to Losant.

Edge Compute Diagram

The following steps detail how to develop a workflow using a timer, Modbus Read Node, and Device State node to report state of a Modbus Enabled PLC to the Losant Cloud:

  1. Drag the Timer Node onto the workflow canvas. This enables you to trigger a read on a recurring basis.
  2. Connect a Modbus: Read Node (or the local protocol node of choice) to the Timer Node. This enables you to read the local protocol.
  3. Connect a Device: State Node to the Modbus: Read Node. This enables you report the data from the local device to the cloud as state.

Writing Data Using Local Protocol

Edge Workflows can be triggered by Device Commands. Using Device Commands, from an Application Workflow or an Experience Workflow, you can trigger a Device Command to perform a write to the local protocol of your choosing.

The following is an example of using a device command to write to Modbus:

Edge Workflow

To build an Edge Workflow that listens for a command to trigger a local Modbus Write, you can perform the following steps:

  1. Drag the Device: Command Trigger onto the workflow canvas. This enables the workflow to listen for device commands.
  2. Connect a Switch Node to the Device: Command Trigger. This enables you to configure different commands for your device.
  3. Define the name of your command as a case of the Switch Node
  4. Connect a Modbus: Write Node (or the local protocol node of choice).

You may find a full step by step example here: How to Trigger a Modbus Write from an Input Control Block.

Exposing Network and Ports

Protocols like MQTT, HTTP, etc. require you to give the Docker Container proper network access to your devices. This generally can be accomplished in two ways:

  • You can use the -p flag to expose the necessary ports. For example, you can use -p 502:502: to map TCP port 502 in the container to port 502 on the Docker host. Example:
docker run -d --restart always \
      -v /var/lib/losant-edge-agent/data:/data \
      -v /var/lib/losant-edge-agent/config.toml:/etc/losant/losant-edge-agent-config.toml \
      -p 502:502 \
      losant/edge-agent
  • You can also use the Docker host network by passing --network host to the run command. This parameter allows the container’s network stack to be not be isolated from the Docker host and networking namespace. For more, see Docker Network documentation.

Supported Protocols

MQTT

The Edge Agent exposes a local MQTT broker to be used for local machine-to-machine (M2M) communication, or to trigger Edge Workflows using the MQTT Trigger to process and forward sensor data to the cloud.

Configuration

To configure the local MQTT broker, you can set the following parameters in your Edge Agent configuration file.

[localBroker]
# If the local broker should be enabled - CLI: --local-broker-enabled, EnvVar: LOCAL_BROKER_ENABLED
# enabled = false

# Port to run the local broker on - CLI: --local-broker-port, EnvVar: LOCAL_BROKER_PORT
# port = 1883

# Address to run the local broker on - CLI: --local-broker-address, EnvVar: LOCAL_BROKER_ADDRESS
# address = '0.0.0.0'

# Username for the local broker - CLI: --local-broker-username, EnvVar: LOCAL_BROKER_USERNAME
# username = ''

# Password for the local broker - CLI: --local-broker-password, EnvVar: LOCAL_BROKER_PASSWORD
# password = ''

[localBroker.ssl]
# NOTE if an SSL key is provided, an SSL certificate is
# also required, and vice versa. An SSL bundle is optional.

# Path to the SSL Key file to use for the local broker
# CLI: --local-broker-ssl-key-path, EnvVar: LOCAL_BROKER_SSL_KEY_PATH
# Key can also be provided directly using the EnvVar LOCAL_BROKER_SSL_KEY
# keyPath = ''

# Path to the SSL Certificate file to use for the local broker
# CLI: --local-broker-ssl-cert-path, EnvVar: LOCAL_BROKER_SSL_CERT_PATH
# Certificate can also be provided directly using the EnvVar LOCAL_BROKER_SSL_CERT
# certificatePath = ''

# Path to the SSL Bundle file to use for the local broker
# CLI: --local-broker-ssl-bundle-path, EnvVar: LOCAL_BROKER_SSL_BUNDLE_PATH
# Bundle can also be provided directly using the EnvVar LOCAL_BROKER_SSL_BUNDLE
# bundlePath = ''

You must use the -p flag to expose the necessary ports. For example, you can use -p 8080:8080 to map UDP port 80 in the container to port 8080 on the Docker host. Example:

docker run -d --restart always \
      -v /var/lib/losant-edge-agent/data:/data \
      -v /var/lib/losant-edge-agent/config.toml:/etc/losant/losant-edge-agent-config.toml \
      -p 8080:8080 \
      losant/edge-agent

MQTT Resources:

HTTP

The Edge Agent exposes a local HTTP Web Server to be used for local machine-to-machine (M2M) communication, or to trigger Edge Workflows using the HTTP Request Trigger Node to process and forward sensor data to the cloud.

[webserver]
# If webserver should be enabled - CLI: --webserver-enabled, EnvVar: WEBSERVER_ENABLED
# enabled = true

# Port to run webserver on - CLI: --webserver-port, EnvVar: WEBSERVER_PORT
# port = 8080

# Address to run webserver on - CLI: --webserver-address, EnvVar: WEBSERVER_ADDRESS
# address = '0.0.0.0'

# Basic auth username for webserver - CLI: --webserver-username, EnvVar: WEBSERVER_USERNAME
# username = ''

# Basic auth password for webserver - CLI: --webserver-password, EnvVar: WEBSERVER_PASSWORD
# password = ''

[webserver.ssl]
# NOTE if an SSL key is provided, an SSL certificate is
# also required, and vice versa. An SSL bundle is optional.

# Path to the SSL Key file to use for the webserver
# CLI: --webserver-ssl-key-path, EnvVar: WEBSERVER_SSL_KEY_PATH
# Key can also be provided directly using the EnvVar WEBSERVER_SSL_KEY
# keyPath = ''

# Path to the SSL Certificate file to use for the webserver
# CLI: --webserver-ssl-cert-path, EnvVar: WEBSERVER_SSL_CERT_PATH
# Certificate can also be provided directly using the EnvVar WEBSERVER_SSL_CERT
# certificatePath = ''

# Path to the SSL Bundle file to use for the webserver
# CLI: --webserver-ssl-bundle-path, EnvVar: WEBSERVER_SSL_BUNDLE_PATH
# Bundle can also be provided directly using the EnvVar WEBSERVER_SSL_BUNDLE
# bundlePath = ''

To implement “Routing” using the Switch Node to branch the workflow on data.path, which is the value of the URL Path.

HTTP Resources:

Serial

Serial is a popular southbound communication option for many IoT sensors and peripherals.

Serial Configuration

Gaining access to serial devices across the Edge Agent’s Docker boundary involves navigating some of the more complex areas of Linux and Docker permissions. To help, see: How to Access Serial Devices in Docker.

Serial Resources

UDP

UDP (User Datagram Protocol) is a communications protocol that is primarily used for establishing low-latency and loss-tolerating connections between applications and devices on the internet.

UDP Configuration

[udp]
# Address for UDP server - CLI: --udp-address, EnvVar: UDP_ADDRESS
# address = '0.0.0.0'

You must use the -p flag to expose the necessary ports. For example, you can use -p 8080:80/udp to map UDP port 80 in the container to port 8080 on the Docker host. Example:

docker run -d --restart always \
    -v /var/lib/losant-edge-agent/data:/data \
    -v /var/lib/losant-edge-agent/config.toml:/etc/losant/losant-edge-agent-config.toml \
    -p 8080:80/udp \
    losant/edge-agent

UDP Resources

Modbus

The agent allows you to read and write multiple registers from Modbus-enabled devices via TCP or Serial RTU. For more information on the Modbus Protocol, refer to the Modbus documentation.

Modbus Configuration

Modbus Resources

OPC UA

OPC Unified Architecture (OPC UA) is a machine to machine communication protocol for industrial automation. Losant OPC UA Trigger, Browse, Read, and Write nodes are designed to enable the data that exists in the PLC to be sent to the cloud.

To configure, see Exposing Network and Ports.

OPC UA Resources

Allen-Bradley

Allen-Bradley is the brand name of a line of factory automation equipment, today owned by Rockwell Automation. The Allen-Bradley Read and Write nodes are designed to enable the data that exists in the PLC to be sent to the cloud.

To configure, see Exposing Network and Ports.

Allen-Bradley Resources

BACnet

BACnet is a standard protocol for interacting with a number of building management systems, including HVAC systems, elevators and escalators, security systems, etc. The BACnet: Read and BACnet: Write Nodes give you the ability to record and command building control systems.

To configure, see Exposing Network and Ports.