InfluxDB

Collection INFLUXDB and Delivery INFLUXDB_WRITE. A single External Connection serves all three generations of the product — 1.8, 2.x and 3.x — because they are not different protocols: it is the same HTTP API, with endpoints, authentication and query language of its own in each version.

Connection

Test Connection runs in three stages, and each one fails for a different reason: /ping validates URL, TLS and routing (and returns the server version); the bucket listing validates the credential and that the configured bucket exists; the test query, if any, proves reads work.

Collection

The Query runs on the scheduled interval and its result becomes messages, with the same Result Mode as the SQL collections (all rows in one payload, or one message per row).

There is no Key Column + Post-Collection Command pair here: InfluxDB has no “mark row as read”. Incremental sweeping is done through the time window of the query itself — {{ultimaExecucao}} at the start of the window makes each run continue where the previous one stopped, without repeating or skipping samples.

// Flux (2.x) — {{bucket}} resolves to this Collection's bucket, or the connection default
from(bucket: "{{bucket}}")
  |> range(start: {{ultimaExecucao}})
  |> filter(fn: (r) => r._measurement == "producao")
  |> filter(fn: (r) => r._field == "temperatura")

-- InfluxQL (1.8) — same idea, in that version's dialect
SELECT mean("temperatura") FROM "producao"
WHERE time > '{{ultimaExecucao}}' GROUP BY time(5m), "equipamento"

The available placeholders are the same as in the HTTP collection: {{ultimaExecucao}}, {{dataHoraAtual}}, Variables and Input Parameters, plus {{bucket}}. There is no bind variable in any of the three InfluxDB languages — the value is interpolated into the query text, so treat an Input Parameter here as what it is: content that becomes part of the command.

How the result becomes JSON

Each result row becomes an object. In Flux the response is InfluxDB’s own annotated CSV, converted using the types it declares — a number comes back as a number, and the timestamp keeps its nanoseconds (it is ISO text, not a Date, precisely so nothing is truncated). The protocol control columns (result, table) are dropped.

{ "_time": "2026-08-22T12:00:00Z", "_value": 900.5, "_field": "temperatura", "equipamento": "forno-1" }

Delivery

The delivery writes points into a series. In InfluxDB the schema is born from the write: measurement, tags and fields come into existence on the first write — there is no table to create beforehand.

There are two modes:

Mapped

CMS builds the line protocol from the fields of the already transformed payload. For each field you choose whether it is a tag (indexed metadata, always text, what you filter by later) or a field (the measured value), and optionally a different name at the destination.

A payload that is an array of objects writes one point per item — the natural path for a batch coming from a collection that emitted several rows in a single message.

Line Protocol

The Content Template output (or, if it is empty, the transformed payload itself) is written as is. It is the way out for formats the mapping cannot express — and in it, line protocol escaping becomes the responsibility of whoever wrote the template.

producao,equipamento=forno-1,linha=L2 temperatura=900.5,pecas=12i

Timestamp and precision

What CMS blocks in the query

The collection query goes through a guard of its own, on save and again before running. What it blocks depends on the language:

Text inside quotes and comments does not count: a measurement named http_requests or a column delete_count go through normally.

Test environment

The project’s docker-compose.test.yml — the test environment, kept apart from the product stack — ships an InfluxDB 2.7 ready to exercise both sides, with sample data already loaded:

docker compose -f docker-compose.test.yml up -d influxdb

In the External Connection use http://host.docker.internal:8086 — an address that works both with cms-api in a container and running natively on the machine —, org cms, token the INFLUX_TOKEN value from the root .env (generated by ./scripts/instalar.sh), bucket cms_leitura for the collection and cms_escrita for the delivery.