Modbus and GroundWork Integration

Powerful performance with an easy integration, powered by Telegraf, the open source data connector built by InfluxData.

info

This is not the recommended configuration for real-time query at scale. For query and compression optimization, high-speed ingest, and high availability, you may want to consider Modbus and InfluxDB.

5B+

Telegraf downloads

#1

Time series database
Source: DB Engines

1B+

Downloads of InfluxDB

2,800+

Contributors

Table of Contents

Powerful Performance, Limitless Scale

Collect, organize, and act on massive volumes of high-velocity data. Any data is more valuable when you think of it as time series data. with InfluxDB, the #1 time series platform built to scale with Telegraf.

See Ways to Get Started

Input and output integration overview

The Modbus plugin allows you to collect data from Modbus devices using various communication methods, enhancing your ability to monitor and control industrial processes.

This plugin writes to a GroundWork Monitor instance, allowing for effective metrics management and monitoring in a centralized manner.

Integration details

Modbus

The Modbus plugin collects discrete inputs, coils, input registers, and holding registers via Modbus TCP or Modbus RTU/ASCII.

GroundWork

The GroundWork plugin enables Telegraf to send metrics to a GroundWork Monitor instance, specifically supporting GW8 and newer versions. This integration allows users to leverage the robust monitoring capabilities of GroundWork, enabling comprehensive oversight of metrics collected from diverse sources. Users can specify various parameters such as the GroundWork instance URL, agent IDs, and authentication credentials, allowing for a tailored fit within their existing monitoring setups. It also supports secret-store secrets to enhance security for sensitive fields like username and password. Tags used within the plugin provide fine-grained control over how metrics are categorized and displayed within the GroundWork interface, allowing for custom configurations that adapt to different monitoring needs. However, users should be aware that string metrics are currently not supported by GroundWork, impacting how they manage their data.

Configuration

Modbus

[[inputs.modbus]]
  name = "Device"
  slave_id = 1
  timeout = "1s"
  configuration_type = "register"
  discrete_inputs = [
    { name = "start", address = [0]},
    { name = "stop", address = [1]},
    { name = "reset", address = [2]},
    { name = "emergency_stop", address = [3]},
  ]
  coils = [
    { name = "motor1_run", address = [0]},
    { name = "motor1_jog", address = [1]},
    { name = "motor1_stop", address = [2]},
  ]
  holding_registers = [
    { name = "power_factor", byte_order = "AB", data_type = "FIXED", scale=0.01, address = [8]},
    { name = "voltage", byte_order = "AB", data_type = "FIXED", scale=0.1, address = [0]},
    { name = "energy", byte_order = "ABCD", data_type = "FIXED", scale=0.001, address = [5,6]},
    { name = "current", byte_order = "ABCD", data_type = "FIXED", scale=0.001, address = [1,2]},
    { name = "frequency", byte_order = "AB", data_type = "UFIXED", scale=0.1, address = [7]},
    { name = "power", byte_order = "ABCD", data_type = "UFIXED", scale=0.1, address = [3,4]},
    { name = "firmware", byte_order = "AB", data_type = "STRING", address = [5, 6, 7, 8, 9, 10, 11, 12]},
  ]
  input_registers = [
    { name = "tank_level", byte_order = "AB", data_type = "INT16", scale=1.0, address = [0]},
    { name = "tank_ph", byte_order = "AB", data_type = "INT16", scale=1.0, address = [1]},
    { name = "pump1_speed", byte_order = "ABCD", data_type = "INT32", scale=1.0, address = [3,4]},
  ]

GroundWork

[[outputs.groundwork]]
  ## URL of your groundwork instance.
  url = "https://groundwork.example.com"

  ## Agent uuid for GroundWork API Server.
  agent_id = ""

  ## Username and password to access GroundWork API.
  username = ""
  password = ""

  ## Default application type to use in GroundWork client
  # default_app_type = "TELEGRAF"

  ## Default display name for the host with services(metrics).
  # default_host = "telegraf"

  ## Default service state.
  # default_service_state = "SERVICE_OK"

  ## The name of the tag that contains the hostname.
  # resource_tag = "host"

  ## The name of the tag that contains the host group name.
  # group_tag = "group"

Input and output integration examples

Modbus

  1. Basic Usage: To read from a single device, configure it with the device name and IP address, specifying the slave ID and registers of interest.
  2. Multiple Requests: You can define multiple requests to fetch data from different Modbus slave devices in a single configuration by specifying multiple [[inputs.modbus.request]] sections.
  3. Data Processing: Utilize the scaling features to convert raw Modbus readings into useful metrics, adjusting for unit conversions as needed.

GroundWork

  1. Centralized Monitoring Dashboard: Use the GroundWork plugin to aggregate metrics from multiple Telegraf instances into a single GroundWork Monitor dashboard. This configuration offers complete visibility into system health across various components, enabling swift identification of performance bottlenecks and improved incident response times.

  2. Service Health Monitoring with Alerts: Configure this plugin to send critical service metrics to GroundWork, establishing a robust alerting system. Metrics such as CPU usage and service statuses can trigger alerts based on threshold values, informing administrators of potential issues before they escalate, thereby enhancing system reliability.

  3. Historical Data Analysis: Leverage the historical metric capabilities of GroundWork using this plugin to conduct trend analysis over time. This application allows organizations to make data-driven decisions based on comprehensive historical performance metrics, which can assist in capacity planning and optimize resource allocation.

  4. Custom Service Tags for Enhanced Monitoring: Extend the functionality of this plugin by utilizing custom tags for different services and hosts. By customizing these tags, users can filter and categorize metrics more effectively within their monitoring framework, leading to tailored monitoring experiences that align specifically with business objectives.

Feedback

Thank you for being part of our community! If you have any general feedback or found any bugs on these pages, we welcome and encourage your input. Please submit your feedback in the InfluxDB community Slack.

Powerful Performance, Limitless Scale

Collect, organize, and act on massive volumes of high-velocity data. Any data is more valuable when you think of it as time series data. with InfluxDB, the #1 time series platform built to scale with Telegraf.

See Ways to Get Started

Related Integrations

HTTP and InfluxDB Integration

The HTTP plugin collects metrics from one or more HTTP(S) endpoints. It supports various authentication methods and configuration options for data formats.

View Integration

Kafka and InfluxDB Integration

This plugin reads messages from Kafka and allows the creation of metrics based on those messages. It supports various configurations including different Kafka settings and message processing options.

View Integration

Kinesis and InfluxDB Integration

The Kinesis plugin allows for reading metrics from AWS Kinesis streams. It supports multiple input data formats and offers checkpointing features with DynamoDB for reliable message processing.

View Integration