Meet the Node

A Node is the worker. It's the role that listens, outputs DMX, runs RDM, and reports back to whoever's asking. Moving lights, dimmers, DMX gateways, LED drivers — anything on the rig with a Sig-Net port is, at minimum, a Node.

If the Manager does the talking and the Sender does the broadcasting, the Node does the actual job.

Endpoints: the ports on the box

A Node is described by its endpoints. Every Node has a Root Endpoint (number 0) and zero or more Data Endpoints (numbered 1, 2, 3 and so on).

The Root Endpoint is the admin interface for the whole physical product. It's where you set the device label, change the IP, fire the identify command, reboot the box, and read out global health. Things that affect the whole device live here.

Data Endpoints are the actual ports — physical DMX outputs for example. A moving light typically has one data endpoint (the channels it consumes). A 10-port DMX gateway has ten data endpoints, one per XLR socket.

There's also a special address — Endpoint 65535 — which means "every data port on this device at once". Useful for "set all my outputs to universe 1" type operations.

What a Node knows about itself

A Node is self-describing. It exposes a long list of read/write parameters that any Manager can query:

A device label, a model name, a firmware version, the protocol version it speaks, the complete list of features it supports (so a console can adapt without needing a vendor driver), how many endpoints it has, what roles it plays, its live health bits (hardware fault, locked locally, booted from defaults), whether it's currently in Open Mode, the standard identify-on-the-rig command (with off, subtle, full, and dark-sky-mute states), and whether the network configuration is using default folded multicast or custom routing.

Every endpoint has its own set of parameters too: a label ("FOH wash"), the universe it's patched to, its direction (consumer, supplier, fallback or disabled), what it can physically do (DMX in, DMX out, RDM in, RDM out, virtual), live status bits including merge detection, failover behaviour for stream loss, DMX output timing, and maximum supported refresh rate.

How a Node behaves

Nodes are designed to be quiet on the network until something interesting happens. They listen for poll requests from any Manager and reply with whatever level of detail was asked for. They listen for SET commands aimed at their own TUID (their unique 48-bit identifier) and apply them. They run RDM if they have an RDM-capable port. And they output DMX.

When their configuration changes — whether from a network command, a local front-panel interaction, or a side-effect of an RDM transaction — they bump an internal counter called the change-count and proactively shout the new state to a special "node reply" multicast group. Every Manager listening on that group instantly knows about the change. No central broker required.

Next post: the fourth and most well-behaved role — the Visualiser.

This series is based on v1.0 of the Sig-Net spec - visit Sig-Net.net for any updates.