Audiovisual control · Practical guide
Node-RED: a conceptual flow for AV content coordination
Before linking an application to a player, agree on what a request means. An opening message expresses intent; it does not confirm that the audience can already see the content.
- Inject: manual fictional request
- Change: example label
- Switch: classify intent
- Debug: observe message without equipment output
A small, readable message
The example proposes cue_id C010, session_id DEMO01, and an opening intent. These identifiers are fictional. Keep them separate from file names and any future playback command so rundown changes do not confuse a request with a result.
Switch classifies messages according to rules. Its documentation allows multiple matching outputs or stopping at the first match; choose that behavior explicitly. Unintended branching can multiply requests.
What each block represents
| Block | Proposed use | What it does not establish |
|---|---|---|
| Inject | Create a fictional manual request | Not a visitor input or an approved GO |
| Change | Add an example label and separate fields | Does not validate a device |
| Switch | Classify opening or another intent | Does not independently prevent repeating a cue |
| Debug | Read the output message | Does not confirm playback or signal |
Keep this first path free of device, account, and service nodes. For a future integration, document commands, responses, freshness, and a manual alternative for the actual model and version.
Repetition and a new session
For a repeated show, the same cue can be valid in a different session. Agree on an identity containing session and cue, plus an operator decision to re-enable it. A value filter or standalone timer does not define that policy.
State storage, called context, uses memory by default and is cleared on restart. State retained elsewhere still does not confirm current physical conditions. Design startup as an attended review before accepting another opening.
What to observe when information is missing
Catch only receives errors nodes report to the runtime in the documented way; it does not cover every failure. Status can provide node information, interpreted according to that node. Leave the decision to continue with the operator when a response is missing.
The proposed local test should cover a valid request, an unknown request, a repeated request, and a new session. Record the expected and observed messages with the example revision. Keep that record separate from later equipment playback tests.
When to consider an alternative
- A single action may be handled through a documented manual operation.
- If the show requires clock references or specified timing, compare show-control platforms and their specific interfaces.
- To scope the project, tell us what triggers content, which player would be used, and what the operator needs to see before authorizing it.