A practical Power Core trap setup for broadcast monitoring
Configuring Power Core’s SNMP traps for network management system alerts is an event-driven fault-management task: Power Core sends a notification to a central NMS when a relevant condition changes. Useful events include loss of synchronisation, network status changes, redundancy switching and hardware alarms, allowing a duty engineer to act before audio is affected.
The work starts with the management network rather than the console. Power Core needs a stable identity, the NMS needs a reachable trap receiver, and both ends need matching settings. This separates basic addressing or authentication faults from problems affecting the broadcast path.
Define the events that matter
Begin with an event inventory instead of enabling every available notification. Include device restarts, management-link changes, synchronisation failures, stream or route alarms, redundancy changes, and power, temperature or fan notifications supported by the installed Power Core release. Assign each event an owner, severity and response time to prevent alert duplication.
Australian studios in Sydney, Melbourne and Brisbane often combine direct manufacturer support with specialist systems integration. For a regional rollout, Atomic’s broadcast team can help standardise equipment, documentation and commissioning. Local engineers commonly call a remote maintenance visit a “call-out” and refer to a live broadcast as a “show”, so escalation rules should reflect that working language.
Prepare the management path
Give Power Core a stable hostname and either a static IP address or an appropriately reserved DHCP lease. Place it on a management VLAN with a defined route to the NMS. Confirm that the NMS listens for traps, normally on UDP port 162, and that firewalls permit the traffic without opening the audio network more broadly than necessary.
Settle the SNMP version before entering any credentials. If the firmware supports SNMPv3, configure authentication and encryption through its user-based security settings. For a community-based deployment, use a dedicated community string rather than a default value. Keep community-based SNMP inside a protected management network or VPN, especially where an interstate WAN carries the alerts.
Configure Power Core and the NMS
In the Power Core web interface, use the SNMP or network-services configuration supplied by the installed firmware. Enable the agent, add the NMS as a trap destination, set the receiver’s UDP port and apply the selected SNMP version and credentials. Menu names can differ between software releases, so the matching Lawo documentation remains the authority for supported options and notification groups.
On the management station, load the Power Core MIB supplied for that release before testing. Without the MIB, the NMS may display numeric object identifiers instead of meaningful alarm names. Map each object identifier, source address and device instance to a readable event, severity and site. In a typical installation, Power Core operates alongside Ruby mixing consoles and other studio systems, so its alerts must identify the specific node rather than appear as an anonymous SNMP source.
Compare complementary monitoring methods
Traps provide rapid notification, but they do not present a complete view of device health. A short-lived condition may occur between polls, while an UDP notification can be lost under congestion. Other monitoring sources should therefore support the trap feed.
| Method | Best use | Typical behaviour | Main limitation |
|---|---|---|---|
| SNMP traps | Immediate fault notification | Power Core initiates messages to the NMS | Delivery is not guaranteed |
| Syslog | Detailed operational messages | Devices send timestamped text to a collector | Formats may differ between products |
| Active polling | Current status and counters | The NMS requests values on a schedule | Brief faults may fall between polls |
Use the feeds together rather than treating them as duplicates. Polling can confirm a trap by revealing the current condition, while syslog can provide installation-specific context. Correlation rules should combine repeated messages into one incident, retain separate events for active and standby hardware, and prevent a network outage from generating hundreds of individual pages.
Test alerts under controlled conditions
Begin with the NMS’s test trap function, then trigger a harmless event during an agreed maintenance window. A monitored interface change or planned restart can confirm startup notifications without disconnecting active audio. Check the received source address, destination port, decoded object identifier, severity, timestamp and escalation behaviour.
Packet captures on the management path help distinguish missing traps from malformed or undecoded alerts. Repeat the test after a deliberate reboot to verify startup behaviour and persistence. A received packet proves that the path worked once; it does not prove reliability across congestion or WAN interruption. Monitoring test results over a full operating period can expose packet loss and duplicated notifications before the system carries a critical show.
Maintain the alarm configuration
Save the SNMP configuration so it survives a restart, and include it in the station’s change-control records. Document the NMS address, port, SNMP version, enabled notification groups and responsible operator, while keeping community strings and SNMPv3 secrets in approved credential storage. Restrict configuration access and review unused destinations whenever the management network changes.
Keep time sources synchronised through NTP and store incident timestamps in UTC while presenting local site time. Sydney and Melbourne observe daylight saving, whereas Brisbane remains on AEST, so local clock labels alone can distort an incident timeline. After firmware or hardware changes, compare the supported trap list with the NMS mappings, test each critical event again and retire obsolete alerts.
The wider product ecosystem is explained in the company background, where Power Core forms part of Lawo’s Broadcast 3.0 approach to networked audio, control and studio software. Its monitoring value comes from connecting device events to a clear operational response.
The lasting principle is to make every alert attributable, reachable and actionable. A correctly received trap confirms that monitoring works; disciplined testing confirms that the people and procedures behind it can respond effectively.
