InfluxDB 3 Endpoint Properties
Last updated
Was this helpful?
query (string)The SQL (or InfluxQL) query used for reading data. This property is only applicable for read or subscribe endpoints.
Example: "SELECT * FROM exhaust_temperature WHERE time >= now() - INTERVAL '1 hour'"
queryType (string, enum)Query language for this endpoint. Defaults to the connection's configured query type. InfluxDB 3 uses SQL natively; InfluxQL is offered for compatibility.
This element must be one of the following enum values:
sql
influxql
params (object)Optional named parameters merged into the query as bound parameters. Prefer these over string interpolation. Parameters provided in the read request payload (under a 'params' key) are merged on top of these.
interval (integer)Time interval in milliseconds between consecutive queries. Defaults to 1000 milliseconds if not specified.
cronExpression (string)Cron expression that defines the schedule for polling the endpoint. For syntax and examples, see the node-cron documentation.
Example: "*/2 * * * *"
measurement (string)Name of the measurement (table) in InfluxDB where data points will be stored when writing. Can be overridden by specifying the measurement in the message data, but must be set in at least one location.
Example: "exhaust_temperature"
measurementPrefix (string)Optional prefix to prepend to the 'measurement' name. Useful for namespacing or grouping related measurements.
Example: "engine_"
fields (object)An optional object made up of key-value pairs. These constant fields are merged with the fields from the message.
fieldTypes (object)Optional mapping of field names to their explicit InfluxDB data type ('float', 'integer', 'uinteger', 'string' or 'boolean'). By default the number data type is inferred from the payload (whole numbers become 'integer', others become 'float'), but this could result in false positives, e.g. a field that occasionally arrives as a whole number gets written as 'integer' while other messages for the same field carry decimals. Since InfluxDB fixes a field's column type from its first write and rejects later writes of a different type, in that case the expected target data type should be defined here instead of relying on inference.
Example: {"temperature":"float","count":"integer"}
tags (object)An optional object made up of key-value pairs. These constant tags are merged with the tags from the message.
Last updated
Was this helpful?
Was this helpful?

