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, model, and name, which show up in the device's status panel.

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, fans, and versions available too.

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.

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.

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, link speed, firmware, model and serial number are available too, off by default. Temperature needs Rev 06 or later sensor hardware.

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.

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.

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 node's model, firmware and each port's DMX frame rate. 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.

Device Settings 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, colour 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.
• Maintenance — Download backup saves every setting and the names to a file; Restore from file… writes one back onto this node or a replacement of the same model. 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. 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. Reset… returns the settings to factory defaults (firmware 4.9 or later). Read recovery record shows the node's bootloader details and lets you Disable USB DMX. 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.

Changes to settings are held until you click Apply to node, and only the fields you changed are sent. Lightpath then reads the node back and shows what it actually reports. If the node didn't accept a change, you'll see an error instead of a value that looks saved. Discard throws away unsaved edits. The recorder commands and everything under Maintenance act on the node straight away, and ask first when they change or delete something.

Network shows the node's address and lets you move it: pick Static and enter an IP address, subnet mask and gateway, or pick DHCP, then click Change network settings. Lightpath waits for the node to come back at its new address and updates the integration to match. If you move a node to a subnet this computer can't reach, Lightpath loses contact with it.

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 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.

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.

---

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, 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 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; 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, 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 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, Modulo Pi, AIDA, Resolume, MQTT, DMXking).
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, 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, Ouster, 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.
• Serial ports are local to the Lightpath server machine. An Optoma (Serial) 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.