DeviceHub Pro逐台確認吃掉整個換場
十二台頭顯，一台一台戴上去看有沒有進對場景，一輪就是十分鐘。而你只有三分鐘。
現場沒有「等一下再修」
頭顯不是桌機。它會被觀眾摘下、會退回主選單、會掉 Wi-Fi、會在你看不到的地方沒電。而你只有換場的三分鐘。
演出中沒有人知道哪一台掉了
觀眾按到 Home 鍵、應用當掉、電量歸零——在有人舉手之前，控台上沒有任何跡象。
兩場同時開，訊號互相打架
同一個場地兩組觀眾、兩套流程，OSC 訊號走同一個埠——A 場的換場指令把 B 場一起換掉。
換一版就要重來一遍
新版本 APK 進來，一台一台接線側載，接一次線就是一次拔插的風險。
全場一眼看完
電量、目前執行的應用、應用版本、IP、連線狀態，全部在同一列。低於 20% 自己轉紅，跑錯應用自己轉紅。
每場演出自己一條線路
大群 A、B、C、D 各自持有房間、埠與頭顯。訊號按埠分流，同時同地的兩場演出互不串訊號。
開演前只看一頁
房間驗證了沒、埠對不對、頭顯回報了沒——一頁裡逐項顯示，全綠才叫「可開演」。
同一個場地，兩場演出，訊號不會走錯。
DeviceHub 把每一場演出當成一個「大群」。每個大群有自己的 OSC 輸入埠與輸出埠——控制軟體打進哪個埠，就只有那一群的頭顯會動。
點任一埠送出訊號
控制軟體
DeviceHub 路由
頭顯
A
B
C
D
等待訊號。
訊號互串。這正是共用單一埠的樣子——A 場的換場指令把 B 場一起換掉。
| 進 | 出 | |
|---|---|---|
| 全體 | 9001 | 9000 |
| A | 9002 | 9200 |
| B | 9003 | 9201 |
| C | 9004 | 9202 |
| D | 9005 | 9203 |
每台頭顯只監聽自己大群的那一個埠，不需要在頭顯端做任何切換。全體通道保留 9001／9000，一次送達所有頭顯。
「應該都好了」不是一個狀態。
演出狀態頁把每一場的三件事攤開：房間過了沒、埠有沒有撞、頭顯收到編制了沒。頭顯自己回報確認，不是控台猜的。
A · 主場演出
檢查中
房間驗證中…
埠檢查中…
小群 11. V-012. V-023. V-034. V-04
小群 21. V-052. V-063. V-074. V-08
⚠ 是還沒回報的那一台，不是「可能有問題的某一台」。你知道要去找誰。
接一次線，之後就不必再接。
USB 插上就轉無線
頭顯用 USB 接上，DeviceHub 自動把它轉成 Wi-Fi 連線，然後你可以把線拔掉。之後開機就直接在列表上。
全體斷線會自己爬回來
Wi-Fi 掉了、AP 重開了、整場一起消失——DeviceHub 偵測到全體離線就從歷史 IP 重新連回，不需要有人跑去插線。
換了 IP 也還是同一台
設備身分用序號認，不是用 IP。DHCP 重新配發、換場地、換網段，名字、編號與分組都跟著走。
識別順序為序號 → UUID → IP 歷史；三層都比對不到才視為新設備。
大群、小群、編號——現場講得出口的那套。
一台頭顯同時只屬於一個大群。小群是它在這場演出裡的角色，編號是你在對講機裡喊的那個號碼。
把頭顯拖進小群，編號自己補上
未分組
A · 小群 1
A · 小群 2
B · 小群 1
大群 Show group
一場正在跑的演出。持有 Photon 房間、OSC 埠與這場的所有頭顯。
小群 Sub-group
這場演出裡的角色分組，可自訂名稱與顏色。
編號 ID
頭顯在小群裡的號碼，自動補上最小的空號。
編號在小群內唯一。把 3 號移走，下一台進來就是 3 號。
十二台的工作量，和一台一樣。
批次側載 APK
選一個 APK，一次推給所有在線頭顯。逐台顯示成功或失敗與原因，最後給你成功幾台、失敗幾台。
全體啟動、全體關閉
一鍵拉起或關掉目標應用，不必逐台點。
按下去，畫面立刻跟上
平時每 10 秒輪詢一次；任何一次啟動或關閉之後自動切換成 3 秒快掃並維持 10 秒，讓你當場看到結果，不必盯著畫面等下一輪。
安裝使用 adb install -r（覆蓋安裝，保留資料），單台逾時 120 秒。
它不會因為觀眾抬個頭就重啟。
頭顯離開了指定的應用，DeviceHub 可以把它拉回來。但真正難的不是拉回，是判斷「它真的離開了嗎」。Quest 的系統選單、Guardian 邊界警告會佔住前景幾秒鐘，而作品其實還在背後跑；有時候 ADB 根本讀不到前景是什麼。把這些都當成離開而重啟，等於無緣無故把一位觀眾拽出作品。
輪詢
計數
選一個情境，看 DeviceHub 怎麼判斷。
讀不到，不算證據
ADB 讀不到前景應用時，那是一次量測失敗，不是頭顯離開了。DeviceHub 把它當成沒有資訊：計數不增加，也不歸零。
要連續確認才算
預設連續兩輪（約 20 秒）都確認不在指定應用，才判定為離開。系統選單撐不過兩輪。
拉回之後先等一等
每台拉回後有 30 秒冷卻，不會在前一次啟動還沒生效時又疊一次上去。
通知與拉回是分開的
就算你沒有開自動拉回，有人離開時你一樣會在右下角收到提示——知道這件事本身就有用，即使你決定親自走過去處理。回到作品時也會通知一次。
預設與範圍
自動拉回預設關閉，而且以大群為單位個別開啟——這一場要，隔壁那場可以不要。兩個門檻（幾輪確認、冷卻多久）都能在設定檔裡調整；每個場地的頭顯有多容易跳出去，程式無從得知。
能自動拉回的軟體不稀奇；知道什麼時候不該動的才難寫。
你的作品，你決定誰能開、開到什麼時候。
作品做完了，接下來要交到策展人、國外營運團隊手上。而 APK 一離手，就沒有人知道它會被跑幾場、也沒有人知道合約結束之後它還會不會繼續跑。XRPR 是我們的專案與授權管理平台：作品的每一次啟動都要先向它取得許可，而許可握在你手上。
XRPR 是三個步驟疊成的同一個縮寫。工作人員只做一件事——輸入一組通關密語；三層在背後依序跑完。
- XR Passphrase Router通關密語路由
-
XR Permission Relay權限中繼
有效至 2026-09-05
-
XR Private Room私密領域
未連線
等待送出。
正在進行的演出 · 大群 A · 8 台
演出中
這場不受影響 — 授權在啟動時就已驗證過
一切始於一組密語。Router 不只比對密碼，它把這組密語讀成一組座標——在系統裡所有專案與房間之中，定位出這組密語唯一對應的那一條路徑。
在 DeviceHub 裡：你在啟動畫面輸入的授權房間名稱與密碼，以及每個大群各自持有的 Photon 房間名稱與密碼。
路徑定位之後，請求進入中繼站。這是資安閘門：與資料庫即時握手，確認這組密語現在在不在有效期間內、屬於哪一個專案、有沒有被撤銷。只有通過的請求會被放行。
在 DeviceHub 裡：這一層就是你的開關。撤銷、改期都發生在這裡，而且立刻生效——對方下一次啟動就過不了。
閘門開啟，連線抵達終點：一個由 Photon 驅動的獨立房間。外部訊號進不來，房內成員以低延遲即時互動。
在 DeviceHub 裡：每個大群持有自己的房間。房間密碼留在控台，頭顯只拿到房間名稱與區碼——Photon 加入房間需要的就這些。
工作人員只輸入一次密語，三層在背後跑完。而中間那一層，永遠是你在控制。
你在 XRPR 為這檔展覽開一組授權，把有效期間設成展期，連同 DeviceHub 一起交付。營運團隊每天開機、輸入授權、照常演出。展期結束，授權自己失效；若提前解約，你在後台按一下撤銷——他們下一次啟動就進不去了。
你握著的控制權
- 授權有起訖時間
- 每一組授權都設定生效與結束時間，對齊你的合約。展期結束，授權跟著結束，不需要有人記得去關掉。
- 隨時可以收回
- 提前解約、違約、作品下架——在 XRPR 後台撤銷，對方下一次啟動 DeviceHub 就進不去。不需要跟對方要回任何東西。
- 一個專案，多組授權
- 同一個作品可以同時授權給多個客戶，每一組各自有自己的名稱、密碼與有效期，個別到期、個別撤銷，互不影響。
- 交出去的不只是檔案
- 對方拿到的是作品加上一組有期限的鑰匙。APK 被複製、被轉手，沒有有效授權一樣打不開。
對方拿到的保障
- 不會演到一半被鎖
- 驗證只在啟動時做一次。之後就算授權到期、被撤銷、或整條網路斷掉，正在進行的這場演出都不會被中斷。
- 沒有離線解鎖
- 記住的授權只負責預先填入欄位；每次啟動仍必須真的連上 XRPR 並通過驗證。
- 房間密碼不離開控台
- Photon 房間密碼只存在 DeviceHub。頭顯拿到的是房間名稱、區碼與版本號——Photon 加入房間需要的就這些。
- 授權前什麼都不給
- 通過驗證之前，裝置控制、OSC 路由與設定派發全部關閉；探索服務只回一個 locked。
同一個機制的兩面：你隨時能收回權利，而對方永遠不會在觀眾面前被鎖住。
六個頁面，沒有一頁是裝飾。
DEVICE HUB PRO
Version 0.2.1
- 開始頁面
- 頭顯管理
- 演出狀態
- 安裝軟體
- 系統紀錄
- 系統設定
頭顯連接總數8/8
OSC ByPass開啟
DH 授權有效至 09-05
SHOW-A
V-0184%ShowApp
V-0277%ShowApp
V-0318%ShowApp
V-04—離線
| 連線 | ID | 名稱 | 電量 | IP | 序號 | 啟用的程序 | 程序版本 |
|---|---|---|---|---|---|---|---|
| 1 | V-01 | 84% | 192.168.10.101 | DEMO0000A001 | ShowApp | 1.4.2 | |
| 2 | V-02 | 77% | 192.168.10.102 | DEMO0000A002 | ShowApp | 1.4.2 | |
| 3 | V-03 | 18% | 192.168.10.103 | DEMO0000A003 | ShowApp | 1.4.2 | |
| 4 | V-04 | — | 192.168.10.104 | DEMO0000A004 | — | — |
A · 主場演出可開演
房間 SHOW-A · Jp · 已驗證 rev.3
OSC 9002 → 9200
8 · 8 · 8
小群 11. V-01 ✓2. V-02 ✓3. V-03 ✓4. V-04 ✓
B · 次場演出房間就緒，2 台尚未確認
房間 SHOW-B · Jp · 已驗證 rev.1
OSC 9003 → 9201
小群 11. V-05 ✓2. V-06 ✓3. V-07 ⚠4. V-08 ⚠
[20:14:02] ===== 開始批次安裝 ===== [20:14:02] APK: show-build-1.4.2.apk [20:14:03] [1/8] V-01… [20:14:09] ✓ V-01 [20:14:16] ✓ V-02 [20:14:41] ✗ V-06 — INSTALL_FAILED_INSUFFICIENT_STORAGE [20:15:02] ===== 安裝完成 ===== 7 / 1
[20:11:40] Discovery Server 啟動，監聽端口: 9065 [20:11:41] 轉換並發現設備: 192.168.10.101:5555 [20:12:03] OSC Bypass[A]: /scene/change (2) → 4 [20:13:55] V-07 離開了 ShowApp [20:14:15] 已拉回 V-07
套件名稱
com.example.showapp更新間隔（秒）
10OSC
9001 / 9000A啟用自動拉回
9002 → 9200SHOW-A · JpB啟用自動拉回
9003 → 9201SHOW-B · Jp演出封面。上台前那一眼，看到的是這場的名字，不是一堆數字。
以下為介面示意，資料皆為示範值。
演出封面。上台前那一眼，看到的是這場的名字，不是一堆數字。監控卡在上、明細列在下。連線、編號、名稱、電量、IP、序號、執行中的應用、應用版本、操作，一列到底。每場一張卡：房間、埠、頭顯回報。全綠才是可開演。選 APK、開始安裝，逐台進度即時滾動。即時日誌與關鍵字過濾，自動輪替不會塞爆硬碟。目標應用、ADB 路徑、更新間隔、OSC 埠、大群與小群，全部在這裡。規格
| 支援設備 | Meta Quest 系列 |
|---|---|
| 作業系統 | Windows 10 / 11（主要）；macOS 建置版本 |
| 連線方式 | ADB over USB／Wi-Fi (TCP 5555) |
| 控制協定 | OSC over UDP |
| 全體 OSC 埠 | 進 9001 / 出 9000 |
| 大群 OSC 埠 | 進 9002 起 / 出 9200 起，逐群遞增 |
| 探索服務 | UDP 9065（設備廣播）／ 7908 起（回覆） |
| 預設輪詢間隔 | 10 秒（操作後 10 秒內加速為 3 秒） |
| 自動拉回 | 預設關閉，以大群為單位開啟；連續 2 輪（約 20 秒）確認才動作，冷卻 30 秒，門檻可調 |
| 大群數量 | 預設 A–D，可新增 |
| 實測規模 | 單機同時管理 50 台以上（實測） |
| 授權 | XRPR 授權碼，每次啟動驗證一次，可設定有效期與隨時撤銷 |
| 日誌 | 5 MB × 5 輪替 |
| 目前版本 | v0.2.1 |
下一場演出，把不確定性留在外面。
告訴我們你的場地規模與演出流程，我們用你的實際配置走一次 Demo。如果你正在規劃把作品授權給策展人或國外營運團隊，也可以一起看授權與交付的流程。
先看技術規格
授權模型、OSC 埠配置、Photon 房間交付流程的完整文件。