Node types¶

Built-in nodes cover common integrations, timing, and logic. Configure their settings in the node panel; use a Function node for your own Python.

GET /flows/node-types returns this list with each type's full parameter schema, including any connectors installed on your instance.

MQTT and InfluxDB need their extras: mqtt and influx in the image's EXTRAS, or pip install 'fluksio[mqtt,influx]' on a Python installation. Run the broker and database separately.

Function¶

python — run your own code when its triggering inputs arrive.

The one type with a source file. Its arguments are its input ports and its own settings; its return value is a dict keyed by output ports. See Writing node code.

Settings on a Function node are free-form: you add them by name, and they arrive as keyword arguments.

Integrations¶

MQTT¶

mqtt — listen on topics, or send to them.

The ports pick the direction: outputs only make a listener, inputs a sender. A listener subscribes to its topics, a sender publishes its inputs to them.

A topic may be a filter: + matches one level, # the rest. Everything a filter matches lands on the same port, so use one port per topic where the difference matters.

Set an explicit topic: the default * is a literal topic, not MQTT's match-all filter.

For {"value": 47}, set json_key to value. Without it, an object is unwrapped only if it contains the port's name as a key.

HTTP¶

http — listen on a webhook, or send to a URL and pass the reply on.

The ports pick the direction: outputs only make a listener, inputs a sender. A listener is a webhook: the engine mounts a route at /hooks/{flow}/{url}/{secret} while the flow runs. A sender requests url and publishes a JSON object response on its outputs, one key per output port. Keys no port declares are dropped, and a response that is not an object publishes nothing.

WebSocket¶

websocket — listen on a socket, or send to it, as a client or a server.

The URL picks the role: ws://… or wss://… connects to a server and reconnects when it drops; a path such as /ticker is served at /hooks/{flow}/{url}/{secret} while the flow runs. The ports pick the direction: outputs only make a listener, inputs a sender. A served sender sends to every connected client.

Frames are text. An incoming frame is parsed as JSON: an object feeds the ports it names, and a node with a single output takes any other frame whole. A single input is sent as it stands — a string raw, anything else as JSON — and several go as one object keyed by port.

InfluxDB¶

influxdb — write measurements to a bucket, or read them back.

{
  "writes": {
    "living_temperature": {
      "measurement": "environment",
      "field": "temp_c",
      "tags": {"room": "living"}
    }
  }
}

Query passthrough. An incoming object with a flux key supplies the query. The first output receives an object with rows, each containing ts, value, field, measurement, and tags. Use Function nodes to build queries and shape results for charts.

Notification¶

ntfy — push an incoming value to a phone through ntfy.

For engine failures rather than flow messages, configure Alerts.

Timing¶

Inject¶

inject — emit a value on request, on a timer, or when the flow starts.

Use cron for scheduled emissions, or trigger the node by hand for testing.

Delay & schedule¶

delay — hold messages back, limit their rate, or emit on a schedule.

Order of operations: delay → rate check → forward. A message arriving inside the interval window is held, and when the window ends the latest one held is sent. With a cron and no inputs it emits the current time on each tick; with inputs it emits the last value it received.

Timers wait until their deadline; busy workers can delay execution.

Debounce¶

debounce — send one value now and another once things go quiet. A debounce and hold rather than a scheduler: everything it sends starts from a value arriving. For a cron tick, see inject. Node-RED calls this node trigger.

For example: turn a light on when the door opens, then off after two quiet minutes.

Use wait_port when the delay comes from an input. A wait of zero or less cancels the pending second value and schedules nothing new.

Logic¶

Switch¶

switch — send a value down one branch or another, by rule.

Each rule names an output port; a matching value leaves through that port. Comparisons: eq, ne, gt, gte, lt, lte, contains, between.

Comparing a string to a number is a mistake in the rule, not a reason to take the flow down: the rule simply does not match.

Change¶

change — scale, offset, round or map a value on its way past.

Filter unchanged¶

rbe — pass a value on only when it has actually changed.

The cheapest fix for a sensor that reports every second and changes every hour.

Join¶

join — gather several inputs into one object or list.

System¶

Command¶

exec — run a command where the engine runs and read its output. Adding one or changing its settings requires a superuser.

Outputs the command's stdout, stderr and exit code.

In Docker, the command runs inside the backend container. Mount host files explicitly if the command needs them.

File¶

file — read a file into the flow, or write one out of it.

Paths stay inside the engine's files directory.

Numeric¶

Perceptron¶

mlp — a small neural layer over its numeric inputs.

output = weights @ inputs + biases, with weights drawn from seed so a node reloads identically.

A worked example of numeric logic, not a modelling tool. To train something, use a batch flow and a Function node.

Language¶

Wren¶

wren — turn a typed command into values for the devices wired to it.

Wren is an optional local language model for device commands. Install it in the engine's environment with pip install wren; the node reports a missing dependency if it is absent.

The outputs are actions, a list of records, and any number of targets. A target is an output named <area>_<kind> and bound to the message its device listens on: living_room_setpoint bound to home.setpoint is the living room's heating. The wiring is the allowlist, so the model can write nothing that is not wired to the node.

• area: living_room, kitchen, bathroom, bedroom, office, garden, patio, garage, driveway, balcony
• kind: light, lamp, brightness for a light; setpoint, heating, heat, boost for heating; media, music, tv; shutter, blind, cover; water, watering, sprinkler

A port naming anything else is refused when the flow is built. A port is named after its message unless it is given a name of its own, in the node panel's port name field or as {"name": "setpoint", "port": "living_room_setpoint"} through the flow API.

Targets of one area and kind are one device to the model, and each takes what a call means for its type. A target's current value is the state the model reads.

Each record in actions contains message, value, applied, delay_s, call, and confidence. Unwired calls have an empty message and are not applied. Keep apply=false while checking how the model interprets commands.

A call with a delay ("in 10m") is held by the engine's work queue, like the Debounce node's second value: it survives a restart where the queue is in Redis, and not otherwise.

The node adds default devices to the model's view for missing expected devices. They are reported but cannot receive writes unless wired.

The chat's Control tab sends commands by hand.

Devices¶

Device¶

device — a paired device's own ports: what it publishes, what it follows.

The engine never runs it. Its outputs are the device's in ports, published by the device itself, and its inputs the out ports the device follows, which never wake anything. Each port is named by the device, such as gpio.4 or backlight. See the device's own ports.

The node is degraded, Offline, while the device is not connected: amber on the canvas and a warning on Home, never a fault.

Connectors¶

Installed connector packages add types through the fluksio.node_types entry point group. The editor shows the source package. Incompatible contract versions are skipped; installing or upgrading a connector requires an engine restart.

The contract itself is in The connector contract, and Writing a connector walks through building one.

See also¶

• Payload types — what a port may carry
• Writing node code — the Function node
• The flow editor — placing and configuring them