● VR headset management · v0.3.8
DeviceHub Pro is a Meta Quest headset management system built for free-roam VR shows. Batch connectivity, per-show OSC routing, a pre-flight check before the doors open, and every headset’s view on one screen while the show runs. When the work tours without you, the rights stay in your hands.
01 The problem
Guests take headsets off. Apps drop to the home menu, Wi-Fi drops, batteries die where you cannot see them. The changeover is three minutes.
Scenario: 12 headsets, a 3-minute changeover
Checking 12 headsets by hand takes about 10 minutes; the changeover is 3.
About 50 s a headset: on, check the scene, off. When the changeover ends you are holding number 4, with eight still unchecked.
A guest hits Home, the app crashes, a battery hits zero. Until someone raises a hand, your desk shows nothing.
Two audiences, two cue sheets, one OSC port. The cue that advances show A advances show B with it.
A new APK lands and you sideload it one cable at a time: twelve headsets, twelve plug-ins, twelve pulls.
02 Show night
Twelve headsets, two shows at once: six in show group A, six in B. In order, this is what DeviceHub does at each point of the night.
T−15:00
Plug a headset in by USB and DeviceHub moves it to Wi-Fi: adb tcpip 5555, read the wlan0 address, connect. Pull the cable and it is already in the list. From then on every headset is read every 3 s, up to 8 at once.
One round of 12 headsets: 1.6 s, against 8.7 s one at a time (measured, noted in the code)
T−10:00
Each headset gets a show group, sub-group and ID. Each group gets a Photon room name, password and region, and Verify room checks them with XRPR; a pass bumps the revision. Headsets pick up the new revision on their next pull and answer /show_assignment_ack.
The room password stays in DeviceHub; headsets receive room name, region and revision. They pull every 3 s until they have a name and sub-group, then every 60 s.
T−05:00
Show status gives each group one card: room · region · verified revision, OSC in → out, headsets / acknowledged / online, and a ✓ or ⚠ per headset. The card reads Ready only once every headset assigned to the group has acknowledged.
⚠ means that headset has not acknowledged rev.3 yet
T−01:00
v0.3.8 moved the batch row to the Monitor page: Refresh list, Launch all, Close all. Launch all sends the command and does not wait for a reply; the status grid shows the result, square by square, over the next few reads.
Green square: ShowApp is in the foreground. Red: it is not.
T 00:00
Each show group listens on its own OSC port. A cue arriving on 9002 goes to group A’s six headsets only; one on 9003 goes to B. DeviceHub forwards first and writes the log line after the packet has left.
A: in 9002 → out 9200 · B: in 9003 → out 9201
T+12:00
Press Start and every online headset goes up on one wall: scrcpy, 480 px tiles at 10 fps, up to 16. V-10 is stuck on a loading screen, yet its status square is still green. Click its tile for a live preview at 15 fps.
View only: scrcpy sends no input and does not wake a sleeping headset
T+18:00
Two reads in a row find V-07 off ShowApp, and a notice appears in the corner. Group B has Auto-relaunch on, so DeviceHub relaunches it, then leaves that headset alone for 30 s.
A guest who glances at the system menu for a single read: no notice, no relaunch
T+45:00
End show and lock ends the authorization session and closes DeviceHub, taking the wall, previews and OSC listeners with it. The next launch has to pass XRPR verification again.
Authorization is checked at launch; nothing locks mid-show
Interface mock-up; all data is sample data.
03 Parallel shows
Each show is a show group with its own OSC port pair. A cue sent to 9002 moves group A’s headsets and nothing else.
Cue software sends to
DeviceHub listens on
DeviceHub Pro
Headsets receive on
Waiting for a cue.
Simulation. Port numbers are the defaults on a fresh install.
| Channel | In: DeviceHub | Out: headsets |
|---|---|---|
| All-call | 9001 | Each headset’s own group port; 9999 for a headset with no group |
| A | 9002 | 9200 |
| B | 9003 | 9201 |
| C | 9004 | 9202 |
| D | 9005 | 9203 |
| A new group E | 9006 | 9204 · takes the next free pair |
04 Pre-flight
The Show status page gives every show group one card: the verified room revision, its OSC ports, and how many headsets have acknowledged their assignment. Each ✓ is sent back by the headset itself, not guessed at the desk.
Checked in order. The card names the first step that fails.
Group enabledOtherwise: Disabled
Room name, password and region set, and verified by XRPROtherwise: the step that is missing
At least one headset assignedOtherwise: Room ready, but no headsets yet
Every headset has acknowledgedOtherwise: Room ready, N not yet acknowledged
Ready
8 headset(s) · 8 acknowledged · 8 online
See the not-ready states
05 Monitor
The Monitor page puts Unity’s output on the left and every headset’s live picture on the right. The headset stuck on a loading screen, back in Home or gone black stands out on the wall; click its tile and its picture opens next to the Unity feed.
Try it: click any tile to preview it, press Capture all, or switch the Unity status line below.
Interface mock-up · sample data
Pick a source and press Connect feed; the Unity output appears here.
Press Start to show every online headset at once.
NDI takes a feed from any machine on the network; Spout only from the same PC, and only in the Windows build. Low bandwidth is on by default, so NDI sends its proxy stream. Defaults are 15 fps and 960 px wide, changed only in config.json. The feed never connects by itself: press Connect feed.
All 11 feeds are green and every headset is on the target app, yet V-07 is stuck on a loading screen. The status grid cannot show that. The picture can.
The wall always uses scrcpy and only runs after you press Start. A tile that drops shows the reason instead of freezing on its last frame.
Asks every online headset for one frame, saves each as captures\date-time\name.jpg and lays the results out in one grid, failures first. Each frame is one eye, 16:9, 1280×720.
scrcpy is view-only: no control channel, it does not wake a sleeping headset, and the headset’s APK needs no update.
Measured · 11 × Quest 3 · Wi-Fi
Capture all, 11 headsets
Single preview Each tick below is one frame, across 6.5 seconds.
06 Connectivity
DeviceHub manages headsets over ADB. A headset plugged in by USB moves itself to Wi-Fi; a total dropout reconnects from IP history; a new IP address keeps its name, ID and show group.
On by default. DeviceHub sends tcpip 5555 to the USB headset, waits 2 s, reads the wlan0 address and connects over Wi-Fi. A headset already on Wi-Fi is skipped.
On the poll where the online count falls from one or more to zero, DeviceHub runs adb connect on every address in its IP history, most recent first. One fall to zero, one attempt; it also runs once at start-up. A single headset dropping does not trigger it.
Identity resolves serial → UUID → IP history. While the serial or UUID can be read, the address plays no part. A new DHCP lease keeps the name, the ID and the show group.
A computer running QuestCenter is identified as HOST-<machine>#<1–8>: up to 8 instances per PC, on ports 7908–7915. It reports every 60 s and is marked offline after 90 s of silence. An IP change leaves its group alone.
After DeviceHub restarts, a host shows offline until its next report, up to about 60 s.
Illustrations; addresses and serials are sample data.
07 Fleet
A headset belongs to exactly one show group at a time. The sub-group is its role in that show. The number is what you call out over comms.
HeadsetsPick a headset, choose its show group and sub-group in Device settings, then Save settings. Leave ID blank and it takes the lowest free number in that sub-group.
AA · Show AOSC 9002 → 9200
Sub-group 1
Sub-group 2
Sub-group 3
Sub-group 4
BB · Show BOSC 9003 → 9201
Sub-group 1
Sub-group 2
Sub-group 3
Sub-group 4
Unassigned
Interface mock-up with sample data. The app has no drag and drop: assignment happens in each headset’s Edit dialog.
01
One running show: one Photon room, one OSC in/out port pair, and the headsets in it. A–D by default; you can add more.
02
A role grouping inside a show. Each show group starts with 4; name and colour are set when you add one, and unused ones can be deleted.
03
The headset’s number within its sub-group, unique there. A newly assigned headset takes the lowest free number: with 1, 2 and 4 taken, the next one is 3.
PC
Since v0.3.4 a PC host can join a show group and receive that group’s show OSC. Volume, APK install, capture and the headset wall apply to headsets only.
08 Fleet ops
The Install page lists online Android headsets only; PC hosts are left off. Everything starts ticked, and an unticked headset is left alone.
DeviceHub runs adb install -r on each ticked headset in turn, not in parallel, allowing up to 120 s per headset. The log shows success, or the failure and its reason, for each one, then the totals.
A headset that appears when the list updates is ticked only if everything was ticked before. Once you have unticked anything, a newcomer never adds itself to the targets.
If the new APK is signed differently from the copy on the headset, DeviceHub runs adb uninstall on the old one and installs again, without asking first. Uninstalling wipes that app’s data on that headset.
192.168.10.101:5555192.168.10.102:5555192.168.10.103:5555192.168.10.104:5555192.168.10.105:5555192.168.10.106:5555192.168.10.107:5555Install complete — 6 succeeded, 1 failed
[20:14:02] ===== Install started ===== [20:14:02] APK: show-build-1.4.2.apk [20:14:02] Selected: 7 / 7 [20:14:02] [20:14:02] [1/7] Installing to V-01... [20:14:09] ✓ V-01 installed [20:14:09] [2/7] Installing to V-02... [20:14:16] ✓ V-02 installed [20:14:16] [3/7] Installing to V-03... [20:14:19] → Signature mismatch; removing old com.example.showapp (this clears that app's local data)... [20:14:21] → Old com.example.showapp removed, reinstalling... [20:14:28] ✓ V-03 installed [20:14:28] [4/7] Installing to V-04... [20:14:35] ✓ V-04 installed [20:14:35] [5/7] Installing to V-05... [20:14:42] ✓ V-05 installed [20:14:42] [6/7] Installing to V-06... [20:14:45] × V-06 install failed: Failure [INSTALL_FAILED_INSUFFICIENT_STORAGE] [20:14:45] [7/7] Installing to V-07... [20:14:52] ✓ V-07 installed [20:14:52] [20:14:52] ===== Install complete ===== [20:14:52] 6 succeeded | 1 failed
Interface mock-up; all data is sample data. Untick a few, then press Start install.
One click sends the launch or close command to every known device. It neither waits for nor confirms the result; the status grid shows it on the next reads. Since v0.3.8 the same row is on the Monitor page too.
Each round reads online state, battery, volume, foreground app, app version, IP, serial and model, up to 8 headsets at once. Read time adds to the 3 s interval, so how fast a round reads decides how current the status grid is.
09 Auto-relaunch
When a headset leaves the show app, DeviceHub can pull it back. The hard part is deciding whether it really left: the Quest system menu or the Guardian boundary warning can hold the foreground for a few seconds while the piece runs on behind it, and sometimes ADB cannot read the foreground at all. Treat any of that as a departure and a guest gets pulled out of the work for nothing.
One column per read: 3 s apart, plus read time
The system menu on read 3, back on ShowApp by read 4. Never two in a row, so nothing happens.
Simulation: scenarios and screens are samples; the decision rules follow devicehub_relaunch.py.
01
When ADB cannot read the foreground app, that is a failed measurement, not a departure. The count neither rises nor resets. A headset going offline resets it: leaving the network is not leaving the piece.
02
By default it takes 2 reads in a row off the show app. Reads are 3 s apart by default, so that is about 6 s plus read time. A blip that comes back inside that window triggers nothing; if your venue needs more slack, raise the count.
03
After a relaunch each headset waits 30 s, so a second launch never lands on one that has not taken effect yet.
With auto-relaunch off, a departure still raises a notice in the bottom-right corner for 6 s, and coming back raises another. You can go by the notices alone and walk over yourself.
Each show group has its own Auto-relaunch switch in Settings, off by default: on for this show, off for the one next door. The two thresholds are set in config.json only, under monitoring_settings:
"monitoring_settings": {
"relaunch_required_misses": 2,
"relaunch_cooldown_seconds": 30
}Software that relaunches on its own is easy. Software that knows when to leave a headset alone is not.
10 Rights
Once a show goes to a curator or an operator abroad, nobody controls how many times it runs, or whether it keeps running after the contract ends. XRPR is our project and licensing platform. DeviceHub verifies with it at every launch, and you are the one who issues the licence and takes it back.
XRPR reads three ways, one per layer. The operator enters one room name and password, and the three layers run in order behind it.
Path: DeviceHubPro / SHOW-A
In date · project matches · pass
Valid until 2027-06-30
Room open · SHOW-A · Jp
Verified. DeviceHub starts ADB, OSC and discovery, and each verified show group sends its room name, region and revision to its headsets.
Simulation; all data is sample data.
The Router reads the passphrase as coordinates and finds the one path it points to, among every project and room.
In DeviceHubThe DH room name and password entered at launch, and each show group’s Photon room name and password, sent with Verify room.
The Relay is the gate. It checks with the database that the passphrase is in date, which project it belongs to, and whether it has been revoked. A request that fails stops here.
In DeviceHubThis is your switch. Revoke or change the dates in XRPR, and their next launch is stopped here. A licence that belongs to another project is refused.
Past the gate, the connection lands in a private room driven by Photon. Signals from outside stay outside.
In DeviceHubEach show group has its own room. The password stays in DeviceHub; headsets receive only the room name, region and revision, and a room name and region are all they need to join.
The operator enters it once. Three layers run in order, and the switch on the middle one is yours.
One booking, start to finish
You open a licence in XRPR for the booking, set its dates to the run, and hand it over with DeviceHub. The operating team launches each day, enters it, and runs the show. When the run ends, the licence expires on its own. If the contract ends early, you revoke it, and their next launch will not open.
Ended early: revoke it, and the next launch will not open
Two sides of one mechanism: you can withdraw the rights at any moment, and they will never be locked out in front of an audience.
11 The interface
The v0.3.8 layout, redrawn in HTML. Click the sidebar to switch pages. All data is sample data.
Mock-up · sample data
| Link | ID | Name | Battery | Volume | IP address | Serial | Running app | App version | Actions |
|---|---|---|---|---|---|---|---|---|---|
| 1 | V-01 | 84% | 60% | 192.168.10.101 | DEMO0000A001 | ShowApp | 1.4.2 | LaunchClose | |
| 2 | V-02 | 77% | 60% | 192.168.10.102 | DEMO0000A002 | ShowApp | 1.4.2 | LaunchClose | |
| 1 | V-03 | 18% | 70% | 192.168.10.103 | DEMO0000A003 | ShowApp | 1.4.2 | LaunchClose | |
| 2 | V-06 | 66% | 40% | 192.168.10.106 | DEMO0000A006 | Meta Home | 1.4.2 | LaunchClose | |
| 2 | V-08 | — | Unknown | 192.168.10.108 | DEMO0000A008 | — | — | LaunchClose |
Unity feedNDIReceiving · 1920x1080 · 15 fps
Headset wallStop7/7 feeds
A A · Main showReady
Room SHOW-A · Jp · Verified rev.3
OSC in 9002 → out 9200
4 headset(s) · 4 acknowledged · 4 online
Sub-group 11. V-01 ✓2. V-02 ✓
Sub-group 21. V-03 ✓2. V-04 ✓
B B · Second showRoom ready, 2 not yet acknowledged
Room SHOW-B · Jp · Verified rev.1
OSC in 9003 → out 9201
4 headset(s) · 2 acknowledged · 3 online
Sub-group 11. V-05 ✓2. V-06 ✓
Sub-group 21. V-07 ⚠2. V-08 ⚠
Install complete — 5 succeeded, 1 failed
[20:14:02] ===== Install started ===== [20:14:02] APK: show-build-1.4.2.apk [20:14:02] Selected: 6 / 7 [20:14:02] [20:14:02] [1/6] Installing to V-01... [20:14:09] ✓ V-01 installed [20:14:09] [2/6] Installing to V-02... [20:14:16] ✓ V-02 installed [20:14:16] [3/6] Installing to V-03... [20:14:23] ✓ V-03 installed [20:14:23] [4/6] Installing to V-05... [20:14:30] ✓ V-05 installed [20:14:30] [5/6] Installing to V-06... [20:14:33] × V-06 install failed: INSTALL_FAILED_INSUFFICIENT_STORAGE [20:14:33] [6/6] Installing to V-07... [20:14:40] ✓ V-07 installed [20:14:40] [20:14:40] ===== Install complete ===== [20:14:40] 5 succeeded | 1 failed
[20:11:40] Discovery server started, listening on port 9065 [20:11:40] OSC listener started: All port 9001 [20:11:40] OSC listener started: Group A port 9002 [20:11:40] OSC listener started: Group B port 9003 [20:11:43] [Device] V-01 (192.168.10.101:5555) online | group: 1 | app: ShowApp | battery: 84% [20:11:43] [Device] V-02 (192.168.10.102:5555) online | group: 1 | app: ShowApp | battery: 77% [20:12:03] OSC bypass[Group A]: received /scene/change (2) -> forwarded to 4 device(s) [20:12:31] [Assignment] V-07 acknowledged its assignment [20:13:55] V-06 left ShowApp for Meta Home [20:15:30] Headset wall started with 7 headset(s)
Package name:com.example.showapp
Display name:ShowApp
Interface language:English
ADB path:C:\platform-tools\adb.exe
Refresh interval (s):3
Anchor path:Anchors/Main
Capture source:scrcpy stream (fastest, recommended)
Send port:9999
Receive port:9001
Enable OSC bypass
AA · Main showEnableAuto-relaunchOSC in: 9002 Out: 92002 sub-group(s) · 4 headset(s) · 4/4 acknowledged
Room name:SHOW-ARoom password:••••••Region:JpVerify roomVerified — ready to push
BB · Second showEnableAuto-relaunchOSC in: 9003 Out: 92012 sub-group(s) · 4 headset(s) · 2/4 acknowledged
Room name:SHOW-BRoom password:••••••Region:JpVerify roomVerified — ready to push
12 Specs
● Book a demo
Tell us your floor size and your run of show, and we will demo it against your actual setup. If you are planning to license a work to a curator or an operating partner abroad, we can walk through the licensing and handover flow as well.
The spec sheet lists the ports, read interval, capture and licensing figures. For the full document on the licensing model and Photon room delivery, say so in the form.
See the spec sheet