skip to content
Jason Worden

Offline on Purpose: Designing the Show Network and Telemetry to Survive Failure

/ 6 min read

View more blogs with the tag supervision , View more blogs with the tag offline-first , View more blogs with the tag networking , View more blogs with the tag observability
Table of Contents

Once the engine moved onto a Pi, the network stopped being incidental.

Every control gesture now crosses it. That means the network is not just plumbing. It is part of the product.

I could have treated that as a reason to bolt the rig to venue infrastructure or chase internet connectivity for observability and convenience. Instead I went the other direction: the show network is intentionally local and intentionally self-contained.

That sounds fussy until you think about what failures I am opting out of.

Laser reflections stretching across the room and crowd

Live photo — laser reflections stretching over the crowd during the set, 5/14/2026. Photo by Mariah Tiffany.

The actual rig

The live setup is built around a GL.iNet Slate 7 travel router. The Pi is wired into it and stays authoritative. The iPad is the main control surface. The iPhone joins the same Wi-Fi, but as a narrower companion, not a second full programming station.

Aurora joins the router over Wi-Fi as a client for lighting output. Radiator sits on the wired side when the laser is in the rig. That matters because this is no longer a hypothetical branch in the design. The system supports the laser path for real. It just stays optional at runtime.

flowchart TB
  subgraph clients["Control clients"]
    iPad[iPad primary surface]
    iPhone[iPhone companion]
  end

  subgraph rig["Offline show LAN"]
    Router[Slate 7 router]
    Pi[Pi 5 running Supi]
    Aurora[Aurora Wi-Fi client]
    Radiator[Radiator laser synth]
  end

  Tubes[CRMX fixtures]
  Laser[ILDA laser]

  iPad -->|WebSocket over Wi-Fi| Router
  iPhone -->|WebSocket over Wi-Fi| Router
  Router -->|Ethernet| Pi
  Pi -->|Art-Net UDP| Router
  Router -.->|Wi-Fi| Aurora
  Pi -->|TCP| Radiator
  Aurora -->|CRMX wireless| Tubes
  Radiator -->|ILDA| Laser

That topology matters because it keeps the system legible.

There are really three flows here:

  • Control traffic: iPad and iPhone to Pi over WebSocket
  • Lighting output: Pi to Aurora over Art-Net, then Aurora to fixtures over CRMX
  • Laser output: Pi to Radiator over TCP, then Radiator to the projector over ILDA

Keeping those separate in your head helps a lot when diagnosing the rig. You can lose a controller and still have healthy output. You can break the output path and still have responsive UIs. That is much easier to reason about than a pile of devices all pretending to be one thing.

Why I wanted the LAN offline

The show network does not need the internet to do its job, so I do not let the internet into the control path.

That choice removes a surprising number of problems:

  • No venue Wi-Fi dependency
  • No captive portal weirdness
  • No cloud hop for anything time-sensitive
  • No DNS lookup failures turning into “why is this screen stuck?”
  • No hidden assumption that the room will share my definition of “network available”

For this rig, “offline” is not a fallback mode. It is the intended operating mode.

That also fits the actual traffic profile. A single universe of Art-Net at about 44 Hz is tiny. The interesting problem is not throughput; it is predictability. Short-range local Wi-Fi plus a single wired hop to the Pi is a much friendlier environment than borrowing some unknown upstream network and pretending that is free.

The weirdly important Aurora detail

One detail I liked once I accepted it: the Aurora is not a wired node in this setup. It joins the router over Wi-Fi.

That sounds suspicious until you remember how small the payload is and how the rest of the path behaves. The Pi is still wired to the router. The only wireless hop on the Art-Net side is the last hop to Aurora, which then bridges into CRMX for the fixtures.

In other words, the rig is already embracing wireless at the fixture side. Making the router-to-Aurora link wireless too does not introduce some entirely new category of risk. It just means I should be honest about what matters: signal quality, jitter tolerance, and keeping the topology simple enough that I can troubleshoot it on site.

The laser path reinforces that same design. Radiator is on TCP, not on the Art-Net side, and it does not need to become some peer brain in the system. The Pi still owns scene changes, still decides when lighting and laser presets move together, and still fans commands out over separate transports. That is the part I care about. One authoritative box in the middle beats letting each endpoint invent its own idea of show state.

Offline changed observability too

Once I committed to an offline LAN, I had to stop thinking of telemetry as something I could just fire at the internet in real time.

The interesting failures happen live, under load, in exactly the moments when the rig may have no upstream path at all. So the right question became: how do I keep the evidence until the network conditions change?

The answer in supervision is simple and not very glamorous:

  • The Pi owns telemetry ingestion
  • Events are written to a local SQLite-backed spool
  • A background flusher tries to deliver them later when the outside world is reachable

That is not fancy observability. It is just the same principle as the rest of the rig: if a dependency is unreliable during the part of the experience I care about most, keep the state local, keep the evidence local, and ship it later on your own terms.

The nice side effect is that this model also fits how I inspect the rig during development and setup. The iPad can act as an observability client over a dedicated /observe WebSocket endpoint, and the Pi can stream health and logs locally without needing any external service in the loop. Same story with Radiator presence, Aurora reachability, and controller connections: the useful question during a show is “what does the Pi think is alive right now?” not “did some cloud dashboard eventually hear about it?”

What “trust” means here

I am not claiming this network is unbreakable. RF is RF, and live rooms are hostile little ecosystems full of other people’s devices.

What I am claiming is more practical:

  • The network has a small number of components
  • I control all of them
  • The rig does not need anything outside the bag to keep working
  • Failure modes are easier to isolate because the topology is simple

That is a good trade for a live system.

The next question is what the engine does once the network hands it a command, and how to keep that loop from turning into its own source of drama.