nautobot-app-broadcast

Broadcast domain models for Nautobot: services, multiplex capacity, and (next) signal chains.

Nautobot models networks extremely well and has no vertical for broadcast or media facilities at all. This fills that gap, and does so medium-agnostically — radio and television, and audio, video, RF and data, are all the same shapes. A new domain should add data, not tables.

Status

Early. Capacity models are in; signal chains are next. Not yet published to PyPI.

Models

Why capacity first

Signal chains have to be elicited from people's heads, one conversation at a time. Multiplex capacity is objective and already known, so it can be populated in an afternoon and answer a question most operators cannot answer today: how much of our allocation are we actually using, and does next quarter's line-up fit?

Design decisions

allocated_capacity, not total. A DAB ensemble is 864 Capacity Units, but most broadcasters are tenants on a multiplex rather than its owner. total_capacity is informational; carriage is validated against the portion you hold.

Planned carriage may overcommit — deliberately. Only Active carriage is enforced against the allocation. "Does next quarter fit?" is the question being asked, not an error to block on. Status therefore does the work that branching would, which matters because Nautobot has none.

capacity_cost is entered, not derived. The DAB bitrate-and-protection to Capacity Unit mapping is defined by ETSI EN 300 401 and varies by profile. It is taken from the standard or from the multiplex operator rather than guessed at in code. Protection level is capacity — the same audio bitrate costs more CUs at stronger protection — so the trade-off should be visible, not silently computed.

Separate from Tenant. Tenant means ownership. A service is a thing delivered. Using Tenant for services spends it on the wrong concept and blocks using tenancy for real ownership later.

Not here yet

• SignalChain — ordered, Device-referencing paths tagged by medium (audio / data / gpio / video / rf), criticality (program vs ancillary), and role (primary / backup). One service has many chains: program audio, RDS, now-playing metadata and GPIO can each take different routes with backups in different directions.
• Diversity validation — the payoff. Walk primary against backup and report every shared device, rack, location, power feed or circuit. Redundancy that isn't diverse is the failure people don't find out about until it happens. Unknown must report as unknown, never as diverse.
• REST API, UI views, tables, filters, navigation.

Development

No local dev environment yet. Migrations are generated against a running Nautobot 3.0.11 by putting the package on PYTHONPATH, adding nautobot_broadcast to PLUGINS in a throwaway config, and running makemigrations — a build-time artifact, not a deployment change.

Installing

pip install nautobot-app-broadcast

then add to PLUGINS in nautobot_config.py:

PLUGINS = ["nautobot_broadcast"]

Nautobot apps are Python packages baked into the image — they cannot be installed at runtime — so containerised deployments need this in their image build.

Licence

Apache-2.0 — see LICENSE. Same as Nautobot itself, so it composes freely with the rest of the ecosystem.