# Configure NMOS connections

> Set an adopted node's endpoints, polling, and Group Mode, and tune the behaviors that decide how Buttons reacts to sender and receiver state.

Once a node is adopted, a few settings decide how its endpoints are reached, how its ports are organized for routing, and how Buttons reacts to the sender and receiver state the node reports. Getting these right is what turns a working connection into one that behaves the way your facility actually needs. Before you begin You need: An adopted NMOS node: see Discover, adopt, and route NMOS resources or Connect Buttons to an NMOS Registry . Access to edit NMOS connections. Review the node's endpoints Open the node in Connection → NMOS and select its Node tab. Api Version selects the IS-04 version Buttons uses when talking to this node: leave it at Auto unless the node needs a specific supported version. This is fixed to the discovered value for a peer-to-peer node under active discovery. Node endpoints lists the addresses Buttons tries to reach this node's API on, in order: the lowest-priority endpoint is tried first, and Buttons moves to the next one if it's unreachable. This mirrors how Registry endpoints work on a Registry connection. Polling makes Buttons check the node's status, SDPs, and active flows itself, at an interval from five seconds up to an hour. It's off by default. Polling isn't the recommended way to work with NMOS: leave it off, and turn it on only as a fallback when mDNS isn't working properly on your network. Ongoing changes on the node A node's senders and receivers aren't fixed at adoption time. If the node later adds or removes a sender/receiver, or a receiver's subscription changes from elsewhere, Buttons picks that up on its own (through the node's mDNS announcements for a peer-to-peer connection, or through the Registry's own update stream for a Registry-adopted one) without needing to re-adopt the node. Ports and Bundles and Active update to match once the change has been processed. Choose how the node's ports become routing bundles Still on the Node tab, Group Mode decides how this node's Senders and Receivers are organized into the bundles you see under Ports and Bundles : All ports as one bundle for this node : every port on the node in a single bundle. All ports on one device as one bundle : one bundle per Device the node hosts. Use group hints as bundles : follow grouping hints the node itself provides. One to one : each port becomes its own bundle. Warning Changing Group Mode adds or removes bundles on this node and resets their tags and labels. Confirm any panels or Presets built from this node's current bundles before changing it. Multi-channel audio senders and receivers An IS-04 audio sender that reports a source.channels list publishes one essence per channel (an 8-channel sender is 8 separate Audio essences), while an IS-04 receiver never reports a channel list, so Buttons treats it as a single flexible essence that can accept any number of channels. This asymmetry is expected and doesn't block routing: a route from a multi-channel sender straight to a receiver is a normal take, and a receiver routed into a fan-in/fan-out mux (an SDI input carrying embedded audio, for example) has its one essence matched against every channel on the other side rather than needing a one-to-one channel count. NMOS Controller Behavior Three behaviors, available system-wide at Settings → NMOS and overridable per Registry connection or per node, shape how Buttons reacts to what a sender or receiver reports: Reconnect on SDP Change (Experimental) : automatically re-route a destination when its connected sender's SDP changes, such as a resolution, framerate, or multicast address change. Applies to destination ports only. Activate Sender when SDP Present : automatically activate a sender once its SDP is successfully fetched, if it isn't already active. Applies to source ports only. Auto-Assign Multicast Address : automatically assign a sender a multicast address from a configured profile. Covered in full in Manage NMOS multicast addresses . Behaviors cascade from system scope down through Registry and connection scope to individual ports. A Registry connection's or a node's own Behaviors tab has an Inherit behaviors switch: leave it on to follow the parent scope's configuration (shown with a badge such as From Registry ), or turn it off to configure different behaviors at this specific level. Verify a route The settings above become visible the moment you actually route through this node. Open Routing → Route . Select the adopted node's connection as both Sources and Destinations , or the appropriate pair of connections if the sender and receiver belong to different nodes. Select the source and destination bundles. Select Take . A successful request reports Routes executed successfully , and the destination's active-source display updates from the state the NMOS receiver reports. If Activate Sender when SDP Present is on, watch for the source activating on its own once its SDP becomes available, rather than needing an explicit action. If Reconnect on SDP Change is on and the sender's transport changes later, the destination should re-route to follow it without a new manual request. If you get stuck What you see What to try Bundles for a node look wrong, or tags and labels disappeared. Check Group Mode : changing it resets bundles, tags, and labels for that node. A sender never becomes active on its own. Confirm Activate Sender when SDP Present is enabled and that the sender's SDP is actually fetchable: see Diagnose NMOS problems . A node keeps losing track of live status. First check that mDNS works on this network. Turn on Polling only as a fallback if it doesn't. Where to go next Manage NMOS multicast addresses , for automatic sender-address assignment. Diagnose NMOS problems , for endpoint, SDP, and route failures.