Devices

How Lightpath talks to projectors, LED controllers, media servers, lighting consoles, and any other AV gear that speaks HTTP or OSC.

A device is anything Lightpath can send commands to: a projector, an LED controller, a media server, a smart relay, an OSC-speaking console, a camera, an HTTP-controlled audio matrix. Devices are managed under Configure → Devices in the app — each one has a name, one or more network addresses, and a list of named controls you wire up once and then fire from the rest of Lightpath.

Device types

Lightpath ships with eight device types out of the box. Pick the one that matches the protocol your hardware speaks.

HTTP REST

For anything with a REST API. Generic and flexible. You configure the host, port, and authentication on the device's Config tab, then add controls — each control specifies its own endpoint, method, and body.

Use this for: custom hardware, niche AV software, anything with a documented REST API.

OSC

Open Sound Control over UDP. The protocol of lighting consoles, audio gear, and most show-control rigs. Configure one or more addresses (each with its own port) on the General tab — one OSC device can fan out to several listeners.

Use this for: lighting boards (ETC, MA, Hog), audio rigs (QLab, Ableton Link), most show-control hardware.

Industry-standard projector control. Power, shutter, audio-mute, input select. Lightpath speaks PJLink natively — when you add a PJLink device, the controls come pre-wired; you don't write endpoints. The projector also reports lamp hours, errors, model, and name, which show up in the device's status panel.

Use this for: any projector that supports PJLink (most professional projectors do).

Shelly

Shelly smart relays for power control. Generation 1 and Generation 2 both supported. You configure the channels on the device, and Lightpath generates a power toggle per channel automatically. Current draw (watts, volts, amps) and temperature show up as live status.

Use this for: anything you need to switch mains power on — signs, heaters, fixtures with no protocol of their own.

Advatek PixLite

PixLite LED controllers — pixel-mapping, Art-Net / sACN universe management. Lightpath ships with default controls for identify, test patterns, master intensity, live mode, and restart. Status reports temperature, FPS, CPU, voltage, port health, and current.

Advatek devices on the LAN can be discovered automatically via the network discovery panel in the device editor.

There's also a separate Advatek Configurator page in the app for managing port configs, templates, firmware updates, and CSV imports across all Advatek devices on the network. That's a fleet-management tool, not a device instance.

Use this for: Advatek PixLite-series LED controllers.

Modulo Pi

Modulo Player media server. Playlist control, cues, faders, and monitoring via the Spydog port. Default controls cover play, pause, next/previous, jump to cue, master and audio faders, media switch, save, and rescan. Live status includes play state, current cue, timecode, CPU, memory, temperature, and the media list.

Use this for: Modulo Player media servers.

AIDA NDI Cameras

AIDA Imaging IP / NDI cameras over the camera's HTTP JSON protocol. Lightpath logs in once with the camera's credentials, then exposes the full image control surface — mirror, flip, WDR, IR-cut, focus, exposure, white-balance, brightness, contrast, saturation, iris — plus system buttons for reboot, factory reset, and snapshot capture. Status surfaces device name, serial, version, NDI status, and stream state.

Use this for: AIDA NDI cameras.

Resolume

Resolume Arena / Avenue media server. Has its own bidirectional Content Mappings flow distinct from the regular content-binding mechanism — see the Resolume section below.

Two integrations are managed as singletons rather than device instances: Isaac (sensor / tracking) and the Advatek Configurator (Advatek fleet manager). They each have their own top-level page in the app rather than appearing in the Devices list.


Controls

A control is a named operation on a device — what Lightpath actually fires when an action, a content binding, a kiosk button, or an API call targets that device.

Each control is one of four types:

TypeSendsShows up as
ButtonA single commandA button
ToggleSeparate ON / OFF commands; can read state back if the device supports itAn on/off switch
SliderA continuous value within a configured rangeA slider
DropdownA value from a fixed list of optionsA dropdown

You add controls in the device editor. For PJLink, Shelly, Advatek, Modulo Pi, and AIDA, sensible default controls are created automatically when you add the device — for HTTP and OSC, you build the list yourself (the device editor lets you start from a category template to save typing).


Content bindings

Available on HTTP and OSC devices only, and only on button controls. The other device types use their own mechanisms (PJLink and its peers come pre-wired to their protocols; Resolume has Content Mappings — see below).

In the device editor, scroll to any button control on an HTTP or OSC device and you'll see a Content Binding field with a Bind to content... button. Click it, pick a piece of Lightpath content (look, scene, or playlist), and that's it: from then on, whenever that content activates in Lightpath — from the controller, from a schedule, from a logic rule, from the API — the bound control fires automatically.

This is how you make external software follow Lightpath's state. A few examples:

  • Bind an HTTP button that calls your projection mapping software's "Load Scene 3" endpoint to your "Performance" scene. When you activate Performance in Lightpath, the projection software loads Scene 3.
  • Bind an OSC button that sends a cue trigger to your lighting board to your "Open" playlist. When Open starts, the board jumps to its matching cue.
  • Bind an HTTP button to a "Closed" scene to call a webhook that notifies your back-office system.

You can change or clear a binding at any time without disturbing the control's normal behavior — the binding is purely an "also fire this when X activates" hook.


Resolume content mappings

Resolume devices have a separate Content Mappings section in their editor that pairs Lightpath content names with Resolume columns or clips. The relationship is bidirectional: activating the Lightpath content triggers Resolume, and triggering the matching clip in Resolume activates the Lightpath content.

In the Resolume device editor, hit Add Mapping for each pairing. For each mapping:

  • Toggle between Col (column) and Clip (layer + clip)
  • Enter the column number, or the layer / clip pair
  • Pick the Lightpath content (look, scene, or playlist) via the content picker

The bidirectional sync makes Resolume + Lightpath behave like a single coordinated rig — flip a clip in Resolume's matrix and Lightpath reflects it; activate a scene in Lightpath and Resolume matches.

Resolume devices also include a built-in master-opacity slider control.


Status

Many devices can report state back to Lightpath. PJLink projectors surface lamp hours and errors; Shelly relays report current draw and temperature; Advatek controllers expose FPS, CPU, port health; Modulo Pi surfaces play state, current cue, timecode, and resource load; AIDA cameras report stream status.

Status shows up in the device's detail panel and feeds into:

  • The Controller view, where toggle controls show their live ON / OFF state instead of just "fire and forget."
  • The Logic page, where status values can be conditions for rules.
  • The Alerts page, where status thresholds can fire notifications.

For PJLink, Shelly, Advatek, AIDA, and Modulo Pi, status works out of the box. For HTTP, you wire each status field explicitly on the control or interface config (the device editor shows a status section per control where supported). For OSC, status is push-based — configure addresses Lightpath should listen for.


Lightpath as a controller

The whole point of the device system is making Lightpath drive other gear and software in sync with what's playing. The pattern:

  1. Add a device for the target system (HTTP if it has a REST API, OSC if it speaks OSC, PJLink for projectors, etc.).
  2. Configure the controls — endpoints and bodies for HTTP, addresses and arguments for OSC, or accept the protocol defaults for the typed device families.
  3. Bind the right buttons to the right content via Content Binding (or Content Mappings for Resolume).

After that, the external system follows Lightpath's state without anyone having to manually coordinate. Schedule activates "Open" at sunset → projectors come up, media server loads its show file, relays power on, signage starts — all from one trigger.

See Changing content → Device content bindings for the upstream view of the same flow.


Creating a device

Go to Configure → Devices and click + New Device. The creation flow is three steps:

  1. Pick the type (HTTP, OSC, PJLink, Shelly, Advatek, Modulo Pi, AIDA, Resolume).
  2. For HTTP and OSC only — pick a category (projector, media server, audio, lighting, etc.) that gives you a starter control set. You can add, remove, or rename controls afterwards.
  3. Name the device, and if you're on a multi-machine install, pick which machine the device lives on.

After creation, the editor opens with two tabs:

  • General — name, description, network addresses, online/offline monitoring behavior.
  • Config — protocol-specific settings (authentication, ports, default headers, and the control list).

Gotchas

  • Offline devices fail loudly, not silently. Lightpath pings each device on a slow interval. Devices that are offline don't break the app — their controls just fail with an error in the logs. Action steps that target offline devices retry a few times before giving up.
  • HTTP toggles need a status query to show live state. PJLink, Shelly, Advatek, AIDA, and Modulo Pi report toggle state via their protocols automatically. HTTP toggles will show as "unknown" in the UI until you wire a status query — the device editor has a status field per toggle for this.
  • Only HTTP and OSC have per-control content bindings. PJLink, Shelly, Advatek, Modulo Pi, and AIDA fire via their protocol-native behavior; Resolume has its own Content Mappings (see above). If you need a listener somewhere on the network to react to Lightpath content changes generically, the outbound OSC broadcasts cover that without per-device configuration.
  • Multiple addresses fire in parallel by default. If you've added several network addresses to one device, controls fire on all of them. Action steps can scope to a specific address if you need that.
  • Use the Resolume device type for Resolume, not generic OSC. The Resolume type is what surfaces the Content Mappings UI and gives you the bidirectional sync. A generic OSC device pointed at Resolume will work for one-way control but loses the rest.

On this page