stroblmeandClaude Opus 5
bdad6d7fc2
The site read as a design journal: rationale paragraphs, hedges
("deliberately", "on purpose", "genuinely"), meta-commentary about the docs
themselves, and one em-dash every ten lines carrying an aside.
Roughly twenty rationale blocks are gone or reduced to what a reader needs
in order to use the thing. Em-dashes go from 507 to 135, and what is left is
structural rather than prose: list and definition separators, table cells,
and four inside code blocks that quote what the CLI actually prints.
Also: api.example.com becomes api.fluksio.com (the emails stay, since
bootstrap.py really defaults to admin@example.com and RFC 2606 reserves it);
the mqtt table gains the two settings it had drifted behind on and inject's
wording matches the engine; llms.txt lists the two connector pages that were
in the nav but not in it; and the two device/device_policy notes now agree.
Builds clean under `zensical build --strict`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj
2.5 KiB
Where a node's values come from
A node function is called with one argument per thing it needs, and every one of them is declared somewhere you can see. There are two kinds.
Ports: what the graph carries
A port binds to a message name. Whatever last published that message is the value the node is called with, and the wiring follows from the name rather than from a line somebody drew.
def process(reading, setpoint):
return {"heat": reading < setpoint}
with reading and setpoint as inputs and heat as an output.
Settings: constants of this node
A setting is a value that belongs to this node's code rather than to the graph: how many retries, which unit, how long to wait. It is typed into the node's Settings section, stored with the flow, and arrives as an argument like a port:
def process(reading, unit="C"):
return {"shown": reading if unit == "C" else reading * 1.8 + 32}
Because both arrive by name, a setting cannot share a name with a port. The node reports it rather than picking one.
Settings are part of the flow document, so changing one is an edit that gets published, not something that happens at runtime. A value that should change while the flow runs is a message, not a setting.
There is no global and no flow context. A constant several nodes need is a
node that provides it: one place it is set, an ordinary message out, and every
consumer visibly downstream of it.
Flow inputs: what arrives from outside
Some messages are not computed by any node in the flow, such as a dashboard control writes them, the API publishes them, a batch run passes them in. Declare those as the flow's inputs, with the value they start from:
{"inputs": [{"spec": {"name": "setpoint", "dtype": "float"}, "initial": 21.0}]}
Without that, the node reading setpoint waits for something nothing provides,
and the canvas says so. With it, the flow starts from 21.0 and whatever writes
the message afterwards takes over.
The canvas draws each one as a labelled endpoint feeding the nodes that read it, the same way it draws a dashboard tile or another flow, so a value never appears from nowhere. They are edited in the flow's own panel.
A batch flow's inputs are also its run parameters, and its outputs name what a run reports as its result; see Runs.
See also
- Flows, nodes and messages — how the graph is built from the names
- Keeping state in a flow — a value a node reads and writes
- Writing node code — the practical side