stroblmeandClaude Opus 5
bdad6d7fc2
Docs / docs (push) Successful in 37s
Playwright Tests / test-playwright (1, 2) (push) Failing after 1m35s
Playwright Tests / test-playwright (2, 2) (push) Failing after 17s
pre-commit / pre-commit (push) Failing after 2m8s
Test Backend / test-backend (push) Failing after 2m48s
Compose Smoke Test / test-compose (push) Failing after 13s
Playwright Tests / merge-reports (push) Failing after 2m25s
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
68 lines
2.5 KiB
Markdown
68 lines
2.5 KiB
Markdown
# 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.
|
|
|
|
```python
|
|
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:
|
|
|
|
```python
|
|
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:
|
|
|
|
```json
|
|
{"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](runs.md).
|
|
|
|
## See also
|
|
|
|
- [Flows, nodes and messages](flows.md) — how the graph is built from the names
|
|
- [Keeping state in a flow](state.md) — a value a node reads *and* writes
|
|
- [Writing node code](../code/nodes.md) — the practical side
|