NMOS (Networked Media Open Specifications) lets IP media devices from different vendors describe themselves and expose controllable connections in a consistent way. Instead of learning a proprietary integration for every camera, mixer, or gateway on the network, Buttons can discover NMOS-speaking devices, understand what each one can send or receive, and route between them the same way it routes any other connection.
This page explains only the NMOS concepts you need to configure Buttons correctly. It does not cover the full AMWA specifications.
Node (one NMOS-speaking device or software instance)→ Device (a logical function the node hosts)→ Senders and Receivers (what that device can transmit or accept)
A Node is one thing on the network that speaks NMOS: a camera, a software gateway, a multiviewer. A node advertises itself so it can be found, and exposes an API describing its own resources.
A Device is a logical function hosted by a node. A single node can host more than one device: for example, a multi-channel gateway node might expose a separate device per channel.
A Sender is something a device can transmit onto the network: an output. A Receiver is something a device can accept a stream into: an input. These are the resources you actually route.
Internally, NMOS also models a Source (the raw origin of the content) and a Flow (one formatted version of that source, such as a specific video format). Buttons uses these to resolve compatibility but does not surface them as something you configure directly.
A Registry is a shared directory where nodes can register themselves so they can be found without entering an IP address for every device by hand. Buttons can run its own registry, connect to someone else's, or skip registries entirely and find nodes directly on the local network.
Peer-to-peer (mDNS) discovery: nodes announce themselves directly on the local network, and Buttons finds them without any registry in the middle. This is the simplest path for a small or flat network.
Registry-based discovery: nodes register into a Registry, and Buttons connects to that Registry to see everything it knows about in one place. This scales better across larger or segmented networks, and it's the only practical option when nodes and Buttons aren't on the same local segment for mDNS to reach.
Buttons can also look up registries themselves via DNS-SD instead of mDNS, which matters more on networks that route mDNS traffic differently or not at all.
Being discovered only means Buttons can see that a node exists: its type, label, and address. Adoption is the separate step that turns a discovered node into a real Buttons connection: only an adopted node's Senders and Receivers become available to route.
This distinction matters because visibility never implies control. A node can be fully visible and still need adoption, and once adopted, still need its own resources to be readable, before you can route anything to or from it.
Once a node is adopted, its Senders and Receivers appear the same way any other connection's ports do: under Sources for what you can route from the node, and Destinations for what you can route to it. You don't need to think in NMOS terms (sender, receiver, IS-04, IS-05) to take a route once adoption is done; you work with the same bundles and ports used everywhere else in Buttons.
The one place NMOS's own resource model surfaces directly is a node's own Node detail tab, which lists its raw Devices, Sources, Senders, and Receivers as NMOS describes them: useful when you need to confirm exactly what a device is advertising, separate from how Buttons has organized its routing bundles.
You don't need deep AMWA specification knowledge to use Buttons, but two names appear throughout the NMOS pages:
IS-04 is the discovery and registration layer: it's what lets Buttons find nodes and registries and read their descriptions.
IS-05 is the connection management layer: it's what Buttons uses behind the scenes to stage and activate an actual route once you select Take.
Buttons handles the IS-05 mechanics itself; you don't stage or activate connections manually. Buttons speaks IS-05 versions v1.0 through v1.2 and prefers the newest a device advertises, so devices that only implement the older v1.0 connection API (common on some ST 2110 hardware) still route.
