When a tally light or UMD label shows a particular result, Buttons can help you see exactly which relationship produced it: whether it's the port's own direct state, what's currently routed to or from it, a virtual device standing in for several physical ones, or a state that followed a route across routers. Knowing which one you're looking at is what turns "the tally looks wrong" into a specific, checkable claim.
This page interprets tally state you observe; for how Providers and Consumers are configured to produce it, see
Understand the Tally system.
Read the Active view#
Routing → Tally / UMD → Active lists every port currently holding tally state:
- Port: the port the state is on.
- Active Channels: which Channels are currently active there.
- Responsible Providers: which Providers are contributing that state.
This view always shows direct state: the tally actually sitting on that specific port right now, regardless of why it's there or what's watching it from elsewhere.
Direct: the item's own state#
The simplest relationship is no relationship at all. A Consumer's Selected Watch Item lookup, or the Active view itself, reads a port's own tally without following any routing relationship. If Input 2 itself has Program active, that's what a direct read shows: independent of what's currently routed anywhere.
Selected: what a destination or source is currently routed to#
A Consumer watching a destination can follow Active Source to read tally from whatever source is currently routed there, rather than from the destination itself. A Consumer watching a source can follow Active Destination the same way, in reverse. This is what lets one fixed UMD tile keep showing correct tally as the operator changes what's routed to it: the tile's tally follows the routed source, not a fixed port.
Contributing: more than one relationship active at once#
Tally isn't limited to one Provider or one destination at a time:
- Responsible Providers on the Active view can list more than one Provider for the same port: several conditions are contributing tally to it simultaneously, and any one of them stopping doesn't necessarily clear the port if another is still active.
- A single source can contribute to more than one destination at once. A Provider targeting a source with Active Destinations expansion applies its tally to every destination that source currently feeds, not just the source itself.
When tally looks duplicated or shows more than you expected, this contribution model (not a bug) is usually why: check Responsible Providers to see every condition currently in play on that port.
Virtual: tally through a Virtual Bundle#
A Consumer can follow Upstream Virtual Bundle or Downstream Virtual Bundle to resolve tally relative to a Virtual Bundle encountered through the route, rather than the underlying physical port. This matters when a physical device is represented operationally as a logical device: the tally you see reflects the virtual identity, which stays stable even if the physical mapping behind it changes later.
Tieline-aware: tally that follows a route across routers#
Two relationships specifically account for routes that cross routing domains:
- Upstream Related Source and Downstream Related Destination trace the active routing chain outward to either the Next Hop or the Furthest related endpoint: useful when a route passes through intermediate equipment before reaching what an operator actually cares about.
- Route Request Source and Route Request Destination resolve from a retained Route Request instead of the immediate physical link, which is what keeps tally correct across a Tieline: the state follows the request's real endpoints even though the physical signal traveled through Relations and intermediate routers to get there.
If you get stuck#
What you see | What to try |
|---|
A tally looks correct on the port itself, but wrong wherever it's displayed. | Check the Consumer's relation: a Selected Watch Item lookup shows the watched port's own state, not what's routed to or from it. |
More tally appears active than you expected. | Check Responsible Providers on Active for that port: more than one Provider may be contributing simultaneously. |
A UMD tile shows the wrong device's tally after a route change. | Confirm the Consumer follows Active Source or Active Destination rather than a fixed Selected Watch Item. |
Tally for a logical device doesn't match what you expect from the physical port. | Confirm whether the Consumer is reading via Upstream/Downstream Virtual Bundle: that's the virtual identity's tally, not the physical port's. |
Tally doesn't follow a route across routers the way you expect. | Check whether the Consumer uses Route Request Source/Destination or Upstream/Downstream Related Source/Destination, and whether the underlying Route Request is still retained. |
Where to go next#
