Devices

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 on the Integrations page (System → Integrations) 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 a device type for each common AV protocol. 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.

PJLink

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 and its name as status, and its manufacturer, model, software version and serial number in the Info section of its Device tab.

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

Optoma (Serial)

Optoma projectors that don't do network control but have an RS-232 port — the D51i family (ML1050STi, ML750i) and relatives. Instead of a network address, each target is a serial port on the machine running Lightpath (e.g. COM3, or /dev/ttyUSB0), plus the projector's ID (00–99, set in the projector's own menu; 00 is fine in most cases — see below). To control several projectors together, add them as multiple targets on one device (not one device each) — but give each target its own serial adapter and COM port. These projectors can't share a single RS-232 bus: a shared bus was tried and the non-addressed units answer instead of staying silent, so their replies collide on the wire. Because every projector is on its own port, the ID can stay 00 on all of them. Add Target adds a blank target — pick the new projector's COM port from the list. Controls come pre-wired — power, AV-mute, audio-mute, source — and you can enable more (freeze, brightness, contrast, aspect ratio, orientation, auto keystone, OSD language, and an on-screen-menu Remote pad) from the Config tab. Status covers power, input, light-source hours, and temperature by default, with signal / resolution / refresh rate and fans available too. The projector's DDP and Android versions are in the Info section of its Device tab, and its MAC address is recorded with its connection.

Wiring: use the projector's Mini-USB → DB9 cable on the projector end and a USB-serial → DB9 adapter on the Lightpath machine. Both ends are DB9 male, so you'll need a female-female null-modem (crossover) adapter to join them: both the USB-serial adapter and the projector are wired as DTE (TX on pin 3), so a plain straight-through gender changer wires TX→TX and the projector never hears the host — you'll get no response at all. A null-modem adapter swaps TX/RX so the two can talk. Before it responds you must enable RS-232 on the projector: on the remote press Power → Down → Right → Menu, turn RS-232 control On, and set the baud rate to match Lightpath (9600 by default, or 19200).

Use this for: Optoma ML1050STi / ML750i and other D51i-series projectors controlled over RS-232 — including remotely, by running the serial link over a USB extender / KVM alongside the video.

NovaStar Sending Card

A NovaStar LED sending card — the MCTRL300 and similar MCTRL models — connected to the Lightpath machine by its USB cable. The address is the card's serial port (e.g. COM3, or /dev/ttyUSB0); pick it from the list when you add the device. One sending card per port.

Every control applies to all the receiving cards behind the sending card, and reads its current value back from the wall:

• Brightness — 0–100%.
• Blackout — shows black without changing the brightness setting.
• Freeze — holds the current frame.
• Test Pattern — red, green, blue, white, horizontal, vertical or diagonal lines, a gray ramp, or the aging pattern. Off returns to the input.
• Gamma, and Red, Green and Blue levels — under Show advanced.

Status:

• Input Signal — whether the card sees a video signal. A health check is set up for it automatically: no signal is unhealthy.
• Input Refresh Rate and Input Resolution.
• Brightness.
• Receiving Cards — how many receiving cards answer, across every output port. Set a minimum in the device's health settings to be told when a card drops off the chain.
• Hottest Card and Lowest Card Voltage — the highest receiving card temperature and the lowest supply voltage on the wall.

The card's model, serial number and firmware, and the receiving cards' model and firmware, are shown in the device's info rather than as status: they don't change while it runs.

The card's own setup — screen layout, receiving-card parameters — stays in NovaStar's NovaLCT. Lightpath opens the serial port only while it is talking to the card and lets go after a few seconds, so NovaLCT can use the same port in between. If the device reads as offline and the port is reported as in use, close NovaLCT and stop its MarsServerProvider service, which keeps the port open even when NovaLCT is closed.

Use this for: brightness schedules, blacking out or freezing an LED wall from actions and the kiosk, test patterns during setup, and watching receiving-card temperature and dropouts.

Shelly

Shelly smart relays and plugs for power control. Generation 1 and Generation 2 and later are supported. Lightpath reads how many outputs the device has and makes a power toggle for each. Current draw (watts, volts, amps) and temperature show up as live status on devices that measure them.

The Device tab (Generation 2 and later) shows every setting the device reports about itself, grouped the way the device groups them: Device, each Switch and Input, and Network open, with System, MQTT, Bluetooth, Shelly Cloud and the rest collapsed. Because the list comes from the device, a plug shows its LED and power limit settings and a Pro relay shows its inputs and Ethernet. Passwords are never shown. Device password sets the login the device itself asks for.

A Shelly backup holds the device's whole configuration, its scripts, schedules, actions (webhooks) and stored values. A restore lets you pick the parts: Switches, Inputs, Other components, Network (Ethernet and Wi-Fi), System, Scripts, Schedules, Actions (webhooks) and Stored values (KVS). Network and System are off by default. Restoring a backup from another model skips what the device doesn't have and lists it.

Maintenance has Reboot, Update firmware (shows the running version and the one Shelly offers) and Factory reset.

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

Ouster LiDAR

Ouster OS-series LiDAR sensors (OS0, OS1, OS2, OSDome) on sensor firmware 2.x or 3.x. Firmware 2.4 or later is recommended. The sensors need no login. Put every sensor that should switch together — say, all the sensors on one path — into one device, one network address each.

Controls:

• Power — on runs the sensor; off puts it in standby, which stops the motor and laser (about 5 W) while it stays reachable on the network. Turning on a sensor that is already running does nothing, so a scheduled "sensors on" action never interrupts a running sensor. After a cold start a sensor takes several minutes to warm up — about 8 minutes for OS0 / OS1 and 15 for OS2 — before it produces data.
• Reinitialize — restarts the sensor's software without a power cycle. This clears most alerts.
• Restart Sensor — a full reboot, sensor firmware 3.1 and later. Lightpath asks you to confirm before it fires.

Status, per sensor: sensor status (running, standby, warming up, error…), temperature, power draw, the worst active alert and its message, the number of active alerts, and the address the point cloud is being sent to. Operating mode, phase lock, input voltage and current, lidar mode, uptime and link speed are available too, off by default. Temperature needs Rev 06 or later sensor hardware. The sensor's model, serial number and firmware are in the Info section of its Device tab.

UDP Destination is the quickest check when a sensor looks healthy but TouchDesigner receives nothing — it shows exactly which machine the sensor is sending to.

Sensor status and alert level make the most useful health checks: healthy when sensor status is running or standby, and when the alert level is anything but ERROR. Give the sensor-status check a long enough delay to cover warm-up — 20 minutes is safe for every model.

Sensors are discovered automatically in the device editor, by their network announcement and by scanning the local network, so a sensor on a network that blocks announcements is still found.

Use this for: turning LiDAR sensors off outside show hours, and watching sensor health and alerts. The point cloud itself is read by TouchDesigner, not by this device.

Network Switch

Managed network switches and routers, read over SNMP: the standard monitoring protocol nearly every managed switch speaks. Unmanaged switches have nothing to read. Lightpath only reads; port, VLAN and firmware settings stay in the switch's own web admin, which Open native UI opens.

Turn SNMP on in the switch's web admin first. On the Config tab, choose the SNMP version and give the read community (most switches ship with v2c and the community "public") or the v3 username and keys. Read access is enough. A switch that has no name in Lightpath takes the name set on the switch itself.

Switches and routers are discovered automatically when you add a device: Lightpath asks every address on the local network with the factory community "public", and with every community already set on a network switch in the project, and lists the ones that answer as a switch or router. So after you change the community on your switches, add one of them by address with the new community, and the scan finds the rest and adds them with it.

Status, per switch: uptime, ports with a link, port errors per minute, and the busiest port as a percentage of its link speed, with which port that is. Port errors and the busiest port are measured between two readings, so they show Unknown for the first 15 seconds. The name set on the switch is available too, off by default. A drop in uptime means the switch restarted. Its model (its system description), location and contact are in the Info section of its Device tab.

The health checks start with sensible defaults: a warning above 60 port errors a minute and a problem above 600, and a warning when the busiest port passes 80% and a problem at 95%. A steady stream of errors usually means a bad cable, a failing SFP module or a duplex mismatch.

The Monitor tab also lists the switch's ports: link and speed, the errors since the switch started, and which Lightpath device is on each port. Lightpath matches devices by their hardware address, using the address a device recorded or looking it up from its IP. Add the router as a network switch too, and every device it has talked to can be matched. A port that leads to another switch is marked as an uplink; the devices behind it appear on that other switch's ports instead. Click the refresh button to read the ports again.

The Network page (under Configure) looks across every switch at once. Its Overview lists what is wrong right now, worst first: a switch that stopped answering or restarted, a link that is nearly full, a port collecting damaged frames (usually a bad cable or termination), oversized frames (jumbo frames on a computer but not on the switch), a duplex mismatch, a link that keeps dropping, and a gigabit port that fell back to 100M. Lightpath checks every switch every 30 seconds and judges what changed in the last hour, so old errors that have stopped are not listed. A note about a 100M link has an Expected button for a device that only does 100M; that port is not noted again.

Each switch also reports its findings as statuses: Open Problems, Open Warnings and Top Finding. Health alerts on them like any other status: an open problem raises an alert, an open warning shows as a warning without paging. Each device's Monitor tab says which switch and port it is plugged into, once a network switch has seen it. Below the findings, Not monitored lists switches on the network that do not answer SNMP yet, with the steps to turn it on for that brand, a link to the switch's web page, and Check again; once one answers, Add as network switch adds it. The Map tab draws how the network is wired, worked out from what each switch has learned, with nothing to set up: the gateway at the top, each managed switch under the one it is plugged into, and each link with its ports, speed and how busy it is. Faster links are drawn thicker; a link turns amber or red when something is wrong at either end or it is nearly full. Where several devices share one switch port, the map shows the unmanaged switch or Wi-Fi access point they must be behind, named after it when it is a known switch brand. Show devices adds every device under the box it is plugged into, with a small picture of what it is and its port; it starts off on a network with more than 60 devices, and the map remembers your choice. Other Lightpath computers on the network show with the Lightpath logo and what they are to this project: this computer, a secondary and its outputs, one free to claim, or one running another project. Move around the map as you would a map app: drag to move, scroll or pinch to zoom, and double-click to zoom in. The buttons in its corner zoom, fit the whole network back on screen, and open the map full screen; the legend says what each line means. Point at a box to light up its way to the gateway, and click it to list what is plugged into it.

Hosts are named by what they call themselves on the network, so a Windows PC, a NAS or a WLED shows its own name rather than only its address. The Switches tab shows each switch as a grid of its ports: green with a link, amber or red when something is wrong, with a bar for how busy the link is. Click a port for its every error counter, in the last hour and since the switch started, with what each usually means, and a chart of its last 24 hours: the average traffic in and out as lines, the busiest moments shaded above them, errors as bars, and a mark wherever the link dropped or fell to a lower speed. The Hosts tab lists every device on the network with the switch port it is on, and Export CSV saves the list.

Use this for: alerts when a switch restarts, a link saturates or a cable goes bad, and finding which port a device is plugged into.

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.

The Device tab has the controller's identity, network, pixel type and color, aux port, and one row per output (universe, channel, pixel count, group, intensity, color order). Assign universes lays the outputs out in order from a start universe: with one controller it fills the form, ready to Apply; with several selected it applies to each in turn and lists how each went. The controller's own Apply runs settings without writing them to its memory, so a power cycle drops them until an admin clicks Save, which also writes them to the controller's flash. A backup is the controller's own full export. Maintenance has Update firmware (controllers of one model at a time) and Factory reset.

Older PixLite controllers (Mk2). PixLite 4 MkII, 16 MkII, 16 MkII ECO and 16 MkII Long Range controllers are supported too. A network scan finds them alongside newer controllers and tells the two apart for you, and so does adding one by its address: Lightpath asks the network whether a Mk2 answers there. Its Device tab shows which Generation it is. If a controller was added while Advatek Assistant was open and shows as a Mk3, click Check device on it once Assistant is closed. On a Mk2, Lightpath can identify the controller, run test patterns (on every output or one at a time) and return it to live, and it reports test mode, temperature and supply voltage.

The first time a Mk2 answers, Lightpath records the settings it reports, and they appear on its Device tab. From there you can change its network address, data source (sACN or Art-Net), DMX output, and for each output its pixel count, universe, channel, grouping, brightness, color order, null pixels, zig-zag and reverse. Apply sends them to the controller and waits for it to report the new values back; if anything didn't take, it says which settings. A Mk2 stores every change it takes, so on a Mk2 Apply and Save both write to the controller's memory. Check device shows whether the controller still matches what Lightpath has. Export JSON saves everything the controller reports to a file. A Mk2 has no backup export of its own, and its firmware and factory reset are done in Advatek Assistant.

A few settings can only be changed in Advatek Assistant: the pixel chip, RGB or RGBW, and expanded mode, because they change how many outputs the controller has. Change them there, then click Check device. A controller in Simple configuration mode has to be switched to Advanced in Advatek Assistant before Lightpath can write its settings.

Only one program on a computer can talk to Mk2 controllers at a time. While Advatek Assistant is open on the same computer as Lightpath, Lightpath can't reach the Mk2s, and a scan tells you so. Quit Advatek Assistant and scan again.

To use Advatek Assistant without quitting Lightpath, switch the Advatek integration off (or switch off every Mk2 in it). Lightpath lets go of the Mk2 connection straight away, and Assistant can reach the controllers. Switch it back on when you're done, after closing Assistant.

Universes from Pixel Studio. A PixLite laid out in Pixel Studio gets 170 RGB or 128 RGBW pixels to a universe, the way a Pixel Map output sends them. The controller's Universe Addressing has to match the output's Universe Packing:

• Continuous pairs with Sequential: each output carries on in the universe where the one before it stopped.
• Per-Port pairs with Split per Fixture: each output starts a new universe. Set Channels per Fixture to one output's channels, so this only lines up when every output carries the same number of pixels.

Use this for: Advatek PixLite-series LED controllers.

WLED

WLED LED controllers. Controls cover power, brightness, presets and effects; status shows the controller's state and health.

The Device tab has the controller's firmware, chip, LED count and MAC address under Info, then its LED layout (one row per output), At power-up (on or off, brightness and preset), Light (brightness scaling and transition time), its Presets (read-only), UDP sync (send, follow and sync group), E1.31 / Art-Net receive (start universe, DMX mode, start address and multicast), DMX output, Sound and Network. LED layout from Pixel Studio fills the outputs from a Pixel Studio controller; nothing is written until you click Apply. A backup holds the controller's configuration and its presets, and a restore can pick either.

DMX output is only there on firmware built with a DMX port, such as Athom's DMX build. It sends one of two things:

• Pass-through universe: everything Lightpath sends on that universe goes out of the DMX port unchanged, the way a PixLite's aux port works. Pick a universe the LEDs don't use; Lightpath refuses one they do.
• Follow the LEDs: the first LEDs drive DMX fixtures, set by the first fixture address, the channels between fixtures, the first LED and the fixture channels (R, G, B, W, S for the master brightness, 0 or 255 for a fixed value).

Sound settings only appear on sound-reactive firmware.

Maintenance has Update firmware and Restart. With several controllers selected there are also Set up sync (one leads and the rest follow, all follow each other, or sync off) and Copy presets.

Athom (IoTorero) Ethernet controllers run Athom's own WLED builds, and Device Settings shows which one under Firmware build. There are two: the DMX build has the DMX output port, the sound-reactive build has a microphone, and no build has both. Update firmware suggests the build the controller already runs and offers the other one, saying what it gives up. Athom boards come in two revisions with different pins, and Lightpath refuses to flash a build for the other revision, because the controller would not start again until it was reflashed over USB. In Pixel Studio, use the Athom Ethernet WLED Controller model so an uploaded layout uses the board's own data pins.

In Pixel Studio, a WLED controller's universes run on from one output to the next: 170 RGB or 128 RGBW pixels to a universe, starting at the controller's first universe. That is how WLED reads them, so the per-port addressing option doesn't apply to WLED. Drive a WLED controller from a Pixel Map output with Universe Packing set to Sequential, or to Split per Fixture with 510 channels per fixture (512 for RGBW): any other split starts fixtures on universes WLED doesn't expect. Uploading a layout also sets the controller's E1.31 / Art-Net receive to match (that first universe, Multi RGB or Multi RGBW, start address 1).

Use this for: WLED-based LED strips and fixtures, and Athom Ethernet controllers as a pixel controller with one DMX port.

BrightSign

BrightSign media players. The Device tab's Info has the player's model, serial number, firmware, family and boot version. Below its settings, Device info reads what changes while it runs (uptime, power, network, storage) and the main settings stored on it, with Read again to refresh it. Lightpath doesn't change a player's settings yet. Maintenance has Reboot, which asks first and works on one player or a selection. Backups record the player's information and settings, without its cloud access tokens or passwords; they can't be restored onto a player yet.

The Players page lists every BrightSign player with whether Lightpath can reach it; open one there to use its controls.

Use this for: BrightSign players.

NovaStar

NovaStar media players (such as the T20Plus) that drive LED walls. The Device tab has Brightness and Output resolution, which lists the resolutions the player offers. Changing the resolution asks first. Its Info has the player's model, serial number, firmware and screen size. The Monitor tab shows the player's alias and free storage, its receiving cards and their temperatures, a screenshot and a live preview. The player's login is on the Config tab.

The wall's brightness is part of its saved settings: dimming it with the Brightness control during a show acts at once and shows the settings as not saved, changed by that control, until someone saves or reverts. A backup holds the brightness, resolution, name and the receiving-card layout; a restore can write back the brightness, resolution and name.

The content a player plays is on the Players page: open the player there to see its solutions, play or delete one, push new media, or Add as output. Select several NovaStar players to push the same media to all of them, started together.

Use this for: NovaStar LED wall players.

DMXking eDMX

DMXking eDMX Art-Net / sACN to DMX nodes — eDMX1, eDMX2, eDMX4 and eDMX8 (MAX and PRO series), ultraDMX, and LeDMX pixel controllers. Lightpath finds them on the network, monitors them, and configures them, so you don't need DMXking's own configuration utility for day-to-day work.

Adding nodes. Choose DMXking eDMX in System → Integrations and add nodes. Lightpath scans the network and lists every DMXking node that answers, by name and address. Tick the ones you want.

Monitor shows each port's DMX frame rate. The node's model, firmware, port counts and settings layout are in the Info section of its Device tab. Status comes from the node's own report, so a node that stops answering shows as offline.

Control has Play show, which starts a show or scene stored on the node, and Stop show. On a group they go to every node at once, so a whole rig can start a show together.

The Device tab reads the node's current setup live. At the top are its Short name and Long name (the short name is also its sACN source name); click Rename to save them. Below them, the settings are grouped into sections:

• DMX ports — one row per port (A, B, C, …).
  • Mode is DMX out, DMX in → Art-Net or DMX in → sACN. A port in DMX out accepts Art-Net and sACN at the same time.
  • Universe is the sACN universe (1–63999). The Art-Net address shown next to it follows DMXking's mapping, where universe 1 is Art-Net 00:0:0.
  • Merge (HTP or LTP) sets how two sources on the same universe combine.
  • On signal loss sets what a DMX out port does when every source stops: hold the last frame, or after 3 seconds stop output, go to zero, go to full, or play the stored snapshot.
  • Capture snapshot… stores what the chosen output ports are sending right now as their snapshot, for signal loss and power-up.
• Port details — each port's output rate, channel offset, full-frame padding, snapshot at power-up and slow DMX; RDM and its discovery timing; and for DMX in ports the sACN priority, unicast destination and USB forwarding.
• Art-Net and DMX timing — the node's Art-Net port and priority, broadcast threshold, IGMP report interval, DMX break and mark-after-break times, USB priority, and the RDM controller it accepts.
• Pixel ports (LeDMX only) — pixel rate and master level, and for each port the pixel type, pixel count, null pixels, color order and its mapping: start universe and channel, grouping, direction and zig-zag. Each port also has an Alternate mapping used when the incoming sACN priority is at or below Alternate below priority.
• Recorder and shows — the node's own show recorder. The options decide whether it may play and record, how playback merges with live input, what happens when a show ends, and which triggers start shows (contact closures, Up / Down / Go, a trigger universe). Below them, pick a Show slot and click Read to see what it holds. From there you can Play, Stop, Record show, Record scene or Delete it, and edit its description, the show that follows it, and a scene's duration and fades. Scenes fit slots 1–51 and 255 (the blackout show).
• Clock — time zone, NTP server and interval, US date format, and daylight saving. Read clock and storage shows the node's clock, hardware and SD card; Set clock from this computer and Update from NTP now set its clock. Settings changes go through Apply, Save and Revert like every device's (see Device tab). Only the fields you changed are sent, and Lightpath then reads the node back, so a change the node didn't accept shows as an error rather than a value that looks set. The node's names, the recorder commands, Capture snapshot and the clock buttons act on the node straight away, and ask first when they change or delete something.

Network shows the node's address. To move it, pick Static and enter an IP address, subnet mask and gateway, or pick DHCP, then click Apply; Lightpath asks you to Keep the new settings (see Device tab). If you move a node to a subnet this computer can't reach, Lightpath loses contact with it.

Maintenance has Update firmware (installs a DMXking firmware file for this model and shows its progress; it takes about a minute, during which the node stops outputting), Factory reset (firmware 4.9 or later; choose whether the node keeps its address, switches to DHCP or returns to its factory address), Recovery channel (the node's bootloader details, and Disable USB DMX) and Delete conf.yml (removes the start-up configuration file from the node's SD card, which would otherwise replace your settings every time the node starts). Firmware files are named like 0126-500-4.11.enc, where the first number is the model's part number; DMXking's configuration utility installs the current ones in its program folder.

A node's backup holds every setting and its names. A backup file downloaded from an older Lightpath can be added with Upload… in Backups and restored onto this node or a replacement of the same model.

Lightpath talks to the nodes on UDP port 16454, so it can run beside TouchDesigner or a console that is sending Art-Net on 6454. Close DMXking's configuration utility if it has locked itself to port 16454.

Use this for: DMXking eDMX nodes driving DMX fixtures from Lightpath's Art-Net or sACN output.

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 the device name, NDI status, and stream state. The camera's serial number and its system, app and hardware versions are in the Info section of its Device tab.

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.

MQTT

MQTT is different from every other type in one respect: before you can add an MQTT device, someone has to connect Lightpath to a broker. That connection is configured once per install, and it lives on the MQTT page itself — go to System → Integrations → MQTT and select All Devices at the top of the list. It is the first thing on the Config tab there. You'll only see it on All Devices — pick a single device and you get that device's own settings instead, because the broker connection belongs to the whole install rather than to any one device.

That panel connects Lightpath to a broker and publishes a retained state feed — the active content, brightness, and enabled state for every output — so any MQTT-aware panel or automation system can read this install and, if you allow it, drive it. Turn on Enabled and fill in a Broker URL (e.g. mqtt://broker.local:1883, or mqtts://broker.example.com:8883 for a TLS connection), a Protocol Version (5.0 by default; switch to 3.1.1 if the broker doesn't support 5.0 — common on an existing building broker), and a Topic Prefix, the base every published and command topic sits under.

Show advanced connection settings reveals fields most installs never need: Client ID (leave blank to let the broker assign one — two installs sharing an id will disconnect each other), Keep-Alive (seconds), and TLS material for a broker that needs it — CA Certificate Path for a private certificate authority, and Client Certificate Path plus Client Key Path together for mutual TLS (a certificate that proves Lightpath's own identity to the broker; supply both or neither). All three are paths to files on the machine running Lightpath, read each time it connects — Lightpath doesn't store certificate or key contents itself, and saving checks that each path actually exists and that a certificate isn't set without its key. Trust Any Certificate skips verifying the broker's certificate entirely; use it only for a self-signed broker you have no CA file for, since it also means anyone able to intercept the connection can impersonate the broker undetected.

Under Authentication, set a Username and Password if the broker requires one — once a password is saved, the field just confirms one is on file rather than showing it, so leave it blank on your next save to keep it, or press Clear to remove it. Accept Retained Commands under Inbound Commands is off by default and should usually stay that way: a retained command re-fires every time Lightpath reconnects to the broker, which can make a scene or look mysteriously re-activate long after anyone touched anything.

Above all of that, Broker Mode picks where the broker itself runs. Connect To A Broker — the default, and everything described above — points Lightpath at a broker that's already running somewhere else, such as a building broker or your own Mosquitto. Host A Broker switches Lightpath to running the broker itself, inside the app, so there's nothing separate to install.

In Host A Broker mode, set a Port (1883 by default). Lightpath shows you that port next to a reminder to find this machine's LAN IP address yourself, in your OS's network settings — Lightpath doesn't display the address itself. Point every MQTT device at that address and port instead of a separate broker. Authentication defaults to required: anything able to reach the port can otherwise publish the commands that change looks and scenes, so a Username and Password are needed unless you turn on Allow Devices To Connect Without A Password, which is off by default and meant only for a trusted, closed network.

The MQTT connection is per-machine, not part of the project. On a multi-machine install, or whenever more than one computer opens the same project, each machine has its own broker connection, certificates, and password — none of it travels with the project between machines, even though the MQTT devices themselves do.

If you're updating an existing install that had MQTT configured before this change reached you, only the first machine you update keeps its connection automatically — it's carried forward with nothing to redo. Any other machine on the same project, once it has that update too, shows MQTT as disabled and needs its broker connection entered again under its own All Devices → Config — it does not inherit the first machine's settings. If you have several machines on one project, expect to enter the connection once on each of them after updating.

If you're looking for this under Settings → MQTT, that's where it used to be; the old link still works and sends you to the new place.

Adding an MQTT device works like any other type: go to System → Integrations, click + New Device, and pick MQTT. Unlike a host address, an MQTT device's address is a topic prefix — everything the device listens to and reports on sits underneath it. A new MQTT device starts with one Power control already set up as a toggle, publishing to <prefix>/cmd/power and reading its state back from <prefix>/stat/power — a convention several off-the-shelf MQTT devices already use. Add, edit, or remove controls on the device's Config tab: each has a Control Type (Button, Toggle, Slider, or Dropdown), a Topic Suffix appended to the device's prefix, an Encoding (Raw publishes the value as typed; JSON publishes a template with {value} substituted in, the shape firmware like Tasmota and Zigbee2MQTT expect), per-control QoS and Retain (falling back to the device's own defaults when not set), and, for reading a control's state back, a Status Topic Suffix and Status JSON Path. A slider control works but always covers the standard 0–100 range — there's no field yet to set a different one. A dropdown's choices are entered as one line of text per option rather than through a per-row list.

The device's own MQTT settings group holds Default QoS and Retain by default (applied to any control that doesn't set its own), Availability topic (a retained topic the device itself publishes to prove it's alive), and Use a different broker — for gear on its own network segment or behind a vendor gateway, pointing just this one device at a broker other than the shared one. Turning it on reveals its own Broker URL, Username, Password, Protocol Version, and TLS fields, entered the same way as the shared connection and, like it, never leaving the machine you enter them on.

---

Device tab

Select a device on the Integrations page and open its Device tab to see what the device reports about itself and to change what it stores. It has the same sections, in the same order, for every kind of device; a section a device doesn't have isn't shown:

• Info — what the device reports about itself, described below.
• Settings — the device's own settings, with the bar described below.
• Device password — the login the device asks for, where Lightpath can set it.
• Firmware — the version the device runs, beside Update firmware, for devices Lightpath can update.
• Maintenance — restarts, factory resets and the device's own housekeeping.
• Backups — the device's backups, described below.

A device that reports info but stores no settings (a PJLink projector, a NovaStar sending card) has a Device tab with Info alone. A device with neither, such as an MQTT device, has no Device tab.

The device's own web page, where it has one, opens from Open native UI at the top of the panel.

Info

Info lists what the device says about itself: its model, firmware, serial number and anything else its kind reports, plus its MAC address. Advatek, AIDA, BrightSign, DMXking, NovaStar (players and sending cards), Optoma, Ouster, PJLink, WLED and network switch devices report it. These are facts that don't change while the device runs, so they are not status: Lightpath reads them the first time the device answers after Lightpath starts, and Recorded shows when these values were first seen: it only changes when one of them does. Read again asks the device now and says Unchanged when nothing differs, for example to check a firmware update took. The buttons beside the serial number, MAC address and firmware copy them.

With a group or several devices selected, each line shows the value they share, or Mixed with each value and how many devices have it, such as "Mixed: 3.14.2 (3), 3.12.0 (1)". The same values can be shown as columns in the device table: choose them under Info in the column picker.

Health can watch them too. A device's Values list offers its Info alongside its status, so "firmware is 4.11" can be a healthy range, and a rule's Device value can read an Info field, for example to flag a controller that is not on the firmware the show was tested with.

Lightpath's own settings for the device — its name, address and the login Lightpath uses — are on the Config tab.

Saved and running settings

Lightpath keeps two copies of a device's settings: the saved settings, which are the known-good ones, and what the device is running now. The bar at the top of the settings compares them:

• Saved — the device runs its saved settings.
• Not saved, applied by … — someone applied a change in Lightpath that hasn't been saved. The differences are listed.
• Not saved, changed by the … control — a control that changes a stored setting (a wall's brightness, for example) was used.
• Not saved, changed outside Lightpath — the device runs something Lightpath didn't set, from its own web page or another tool.
• Nothing saved yet — Lightpath has no saved settings for the device. The first time Lightpath reads a device, it saves what the device runs.

Edit the form, then:

• Apply writes your changes to the device. The saved settings don't change, so the bar shows Not saved. Some devices (Advatek) also drop an applied change when they lose power.
• Save makes what the device runs its saved, known-good settings and takes a backup. Only admins can save.
• Revert puts the saved settings back on the device.
• Discard edits throws away changes you haven't applied.
• Check device reads the device again.

Lightpath never puts settings back on its own: a device that differs from its saved settings keeps running what it runs until someone saves or reverts. Controls are never held back by any of this — they act at once, for anyone allowed to use them.

Network changes

Applying a change to a device's address, DHCP, subnet or gateway can take it off the network. Lightpath looks for the device at its new address, then asks Keep these network settings? with a countdown. Keep leaves them applied; Undo, or nobody keeping them within a minute, puts the saved network settings back. A device that never answers at its new address gets its saved network settings back at its old one.

Backups

Lightpath backs a device up before every Apply, Revert and Restore, and with every Save, and keeps the newest 10. Back up now takes one straight away. Name a backup to keep it for good; named backups are listed first and never cleared out. Download saves one to your computer, and Upload… adds a backup file from your computer to the list. Restore writes a backup to the device, or to the replacement now at its address; for devices whose backups have parts, you pick which. A restore doesn't change the saved settings until an admin saves. Deleting a backup is for admins only.

Some backups are the device's own full export (Advatek, WLED, DMXking, Shelly); others hold only what Lightpath can read from the device (BrightSign, NovaStar), and the Backups section says which.

Several devices at once

Select several devices in the list (or a group) and open Device Settings to act on all of them:

• Back up all.
• Apply a setting… — set one setting on every device. Each device keeps its other settings.
• Make them match… — apply one device's settings to the others. Each keeps its own network settings and addressing (such as the universes its outputs start on), and Lightpath shows what will change on each device before you apply. Devices of different models can't be matched.
• Maintenance that works on several devices, such as firmware updates and restarts.

Each device is listed with how it went. Changes made this way are applied, not saved, like any other Apply.

---

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:

You add controls in the device editor. For PJLink, Shelly, Ouster, Advatek, Modulo Pi, AIDA, and NovaStar sending cards, 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 with a Resolume column or clip. Each mapping fires outbound by default: when the content activates in Lightpath, the mapped column or clip fires in Resolume.

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
• Optionally set a Deck — the Resolume deck (bank) this mapping lives on. Leave it empty to fire on whatever deck is currently active.
• Pick one or more pieces of Lightpath content (looks, scenes, sequences, or playlists) via the content picker
• Optionally turn on Bidirectional
• Hit Test to fire the mapping to Resolume right now and confirm the wiring, without having to activate the content

Multiple content per mapping. A mapping can list several contents. When any of them activates, the mapped column or clip fires. This expresses "if any of these looks is showing, trigger this clip" with a single mapping.

Bidirectional (opt-in). Turn on Bidirectional to also run the reverse direction: firing that clip inside Resolume activates the mapped content in Lightpath, so the two behave like a single coordinated rig. Because the reverse has to name one specific content, Bidirectional is only available when a mapping has exactly one content selected — a many-to-one mapping is outbound-only. New mappings start outbound-only; turn Bidirectional on where you want the round trip.

Decks (banks). A column or clip position means something different on each deck, so a mapping can pin itself to a deck. When it does, activating the Lightpath content switches Resolume to that deck first, then fires the trigger (with a brief pause so the deck can load). In the reverse direction, the same column on deck 1 and deck 2 can map to different content: Lightpath follows Resolume's active deck to pick the right one. For the reverse direction to track deck changes, enable OSC output for deck selection in Resolume. Leave Deck empty on a mapping to keep the original deck-agnostic behavior.

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; Ouster LiDAR sensors report sensor status, temperature, power draw and alerts; NovaStar sending cards report the input signal and receiving-card health; 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, Ouster, Advatek, AIDA, Modulo Pi, and NovaStar sending cards, 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 System → Integrations and click + New Device. The creation flow is three steps:

1. Pick the type (HTTP, OSC, PJLink, Optoma Serial, Shelly, Ouster LiDAR, Advatek, WLED, DMXking, BrightSign, NovaStar, Modulo Pi, AIDA, Resolume, MQTT, NovaStar Sending Card).
2. For HTTP and OSC — pick a category (projector, media server, audio, lighting, etc.) that gives you a starter control set. You can add, remove, or rename controls afterwards. MQTT also asks for a category, for grouping only — every new MQTT device starts with the same single Power control regardless of which one you pick.
3. Name the device, and if you're on a multi-machine install, pick which machine the device lives on.

After creation, select the device to see its tabs:

• Config — Lightpath's settings for the device: name, network addresses, login, protocol settings (ports, default headers) and the control list.
• Control — the device's controls.
• Monitor — live status and health.
• Device — what the device reports about itself and what it stores (see Device tab).

The ⋯ menu, on the device's row in the table and at the top of its panel, has the same items in both places: Rename, Duplicate, Copy settings from…, Copy address, Find on network and Delete. Copy settings from… copies another device's settings and control list, but never what a device reports about its own hardware (an Advatek controller's model, a Shelly relay's outputs).

Find on network looks for the device by its hardware identity, for when its address changed or the hardware was swapped. It is in the ⋯ menu and beside Address on the Config tab, for kinds of device Lightpath can scan for, whether the device is answering or not.

---

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, Ouster, Advatek, AIDA, Modulo Pi, and NovaStar sending cards 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.
• Serial ports are local to the Lightpath server machine. An Optoma (Serial) or NovaStar Sending Card device talks to a COM port on whichever machine runs the Lightpath server. To control a projector in another room, run the serial link there over a USB extender / KVM back to the server machine — not a second Lightpath install. Use Detect ports in the device editor to pick from the ports the server can actually see, and close any other program (TouchDesigner, a serial terminal) holding the port, or the projector will read as offline. The reverse is also true: while a projector is responding, Lightpath holds its COM port open, so other programs can't use it. To lend the port out without disabling the device, use Release Port on the device's Overview tab, then Reconnect when you're done.
• You can't see the projector's on-screen menu remotely. RS-232 carries commands, not video, and there's no command to read the OSD back. Status can tell you the projector's values (power, input, and — via the Signal / Resolution / Refresh Rate indicators — whether it's receiving a valid image), but not what the menu shows. Prefer the direct controls (which set a value outright) over the Remote pad's menu navigation, which is effectively blind unless someone is watching the screen.
• A few Optoma controls are marked "verify on hardware." Manual V/H keystone and image shift aren't in Optoma's published command table for this model, so they may or may not work on your unit. Use the Raw Command Console on the Config tab to test any command and see the projector's reply before relying on it. Auto keystone (on/off) is supported; per-degree keystone and auto-focus generally are not.
• Display Mode and Color Temperature controls are not offered — the commands crash the projector. On the ML1050STi (verified on hardware, controlled A/B testing), sending either set command — even though both are in Optoma's own command table — silently crashes the projector's RS-232 service, and after a Display Mode crash the entire projector goes down the moment the serial port is closed, requiring a power cycle mid-show. Lightpath therefore doesn't expose either control; their read-only status indicators remain available, and the Raw Command Console still exists if you want to test whether your unit's firmware is affected (send ~0020 1 — no reply means it just crashed; expect the full crash when you disconnect). Every other control is hardware-verified safe: power, source, audio mute, freeze, brightness, aspect ratio, projection, and the remote keys all acknowledge properly. AV mute may reply with a polite failure (F) on some inputs rather than acting — that's the projector declining, not a fault.
• Temperature and fan alerts come from Logic, not the device. Turn on the System Temp / Fan status indicators, then add a Logic rule with a device status condition (e.g. System Temp > 80) to fire an alert — handy for an unattended remote projector.
• "Test" on an MQTT device only confirms Lightpath's connection to the broker, not that the device itself is there. MQTT has no way to ask a specific device "are you there?" — a broker accepts a publish whether or not anything is listening on the other end. Set an Availability topic on the device (in its MQTT settings group) for a device that publishes one, and Test also checks that a value is actually retained there.
• An MQTT device's broker connection doesn't reconnect on its own if it drops. This only applies to a device using Use a different broker — the shared connection under All Devices already reconnects automatically. If the device's own broker restarts or a network blip drops the connection, Lightpath notices and reconnects the next time that device is sent a command, rather than on a fixed schedule in the background.