InfluxDB Nodes

InfluxDB is a time-series database built for sensor readings, metrics and events. MaestroHub provides four dedicated nodes for running Flux queries, writing points, and listing the buckets and measurements of an organization within your pipelines.

Configuration Quick Reference

Field	What you choose	Details
Parameters	Connection, Function, Function Parameters, Timeout Override	Select the connection profile, function, configure function parameters with expression support, and optionally override timeout.
Settings	Description, Timeout (seconds), Retry on Timeout, Retry on Fail, On Error	Node description, maximum execution time, retry behavior on timeout or failure, and error handling strategy. All execution settings default to pipeline-level values.

InfluxDB Query Node

Run a Flux query against the connection's organization.

Function Name	Purpose	Common Use Cases
Query	Execute a Flux query (query) and deliver its rows	Dashboard data, windowed aggregates, last-value lookups

InfluxDB Write Node

Write points to a bucket. Every item in data becomes one point of the given measurement: a flat object ({"celsius": 21.5}) makes every key a field; a structured object ({"fields": {...}, "tags": {...}, "timestamp": "..."}) sets each part explicitly. tags on the function apply to every point. Flat items carry no timestamp and share the event time, so two flat items with the same tags land on the same instant and InfluxDB keeps only the last — give such items their own timestamp in the structured form.

data is an array of those items, held either as an array or as the same array written out as JSON text: the function form's Data editor stores text, and a ((data)) parameter that a node fills from an expression such as {{ $node["Build Rows"].result }} arrives as text too. Both are read the same way. A data that is not an array of objects — text that is not valid JSON, a single object, an empty array — fails the write, saying which. Such a payload cannot succeed on any retry, so the failure is classified permanent: a store-and-forward write sends it to the dead-letter queue on its first delivery attempt instead of retrying it.

timestamp accepts either an RFC 3339 string (2026-09-07T08:00:00Z, fractional seconds and offsets included) or unix nanoseconds as a positive number or numeric string. RFC 3339 is the form every timestamp in MaestroHub takes, so {{ $trigger._metadata.timestamp }} and any upstream node's timestamp can be wired straight in. A bare number is always nanoseconds — seconds and milliseconds are indistinguishable from it, so the unit is fixed rather than guessed.

An unreadable timestamp fails the write

Omit timestamp to stamp a point with the event time — that is the supported way to say "now", and on a store-and-forward replay it keeps the produce time rather than drifting to the drain moment. A timestamp that is present but is neither of the two accepted forms fails the write, naming the item (data[0]: timestamp …). It used to be silently replaced by the event time, which collapsed a whole batch onto one instant: InfluxDB keeps the last write per series and instant, so the node reported every point as written and the bucket held one (#5031).

Function Name	Purpose	Common Use Cases
Write	Write the data items as points into bucket under measurement	Sensor ingestion, KPI recording, event archival

InfluxDB List Buckets Node

Function Name	Purpose	Common Use Cases
List Buckets	List the buckets of the connection's organization — its own _monitoring and _tasks system buckets included, another organization's never	Discovery, dynamic routing of writes

InfluxDB List Measurements Node

Function Name	Purpose	Common Use Cases
List Measurements	List the measurements stored in bucket	Discovery, schema checks before a query

---

Output

Every InfluxDB node delivers its data under result, and execution facts (success, functionId, durationMs, timestamp) under _metadata:

Node	Expression	Description
Query	$node["Name"].result.records	One object per Flux row — _time, _value, _measurement, _field, every tag column, plus result and table as Flux emits them. $node["Name"].result.records[0]._value reads a value
	$node["Name"].result.recordCount	How many rows were delivered
Write	$node["Name"].result.pointsWritten	Points written — one per data item that carried at least one field
List Buckets	$node["Name"].result.buckets	One object per bucket — name and id always; orgID and retentionSeconds when the server reports them
	$node["Name"].result.bucketCount	How many buckets were listed
List Measurements	$node["Name"].result.measurements	The measurement names in the bucket
	$node["Name"].result.measurementCount	How many measurements were listed

The call's own facts ride along under _metadata next to the four every connected node carries: $node["Name"]._metadata.organization on every node, $node["Name"]._metadata.bucket after a Write or List Measurements, and $node["Name"]._metadata.measurement after a Write.