所沢四拼接 · 左下那台的處理說明
這頁是給你的工作頁。讀完之後,你可以自己跟 Oricom 說明我們要做什麼、以及風險在哪裡。
🔴目前尚不可送出給客戶
我們打算做的動作(讓左下那台機器重新啟動一次),還有一個技術前提沒有跟研發確認完。在確認之前,本頁最下方的日文稿請先不要送出去。
- 要確認什麼:左下那台目前每小時才跟伺服器連線一次。研發要回答的是「我們下的重新啟動指令,機器在那一次連線時收得到、而且真的會去執行嗎?」
- 誰能回答:研發(Karote/Daniel Yu)
⚠️ 研發的回答有兩種,結果完全不一樣
本頁繼續使用。但不是把鎖打開就好——解鎖前還有三個地方必須先修,清單在下面。
這一頁整份作廢。第 3 段的做法、第 5 段的日文稿、下面的確認清單全部不能用了——因為那時候要改走「請人到現場用手機設定」,那是另一套說法、另一份稿子。
🔒 這種情況下請不要自己動這一頁,我會另外給你一份全新的頁面。把鎖打開不等於可以送。
✅ 只有在研發回答「可以」時,解鎖前必須先修這三處
- 第 3 段技術細節裡「62 次試驗每一次都成立」→ 要改成正確的次數(62 輪裡有 7 輪失敗,實際驗證到的是 54 次,另有 1 次待研發確認)
- 第 3 段技術細節裡「21 次都是指令沒送到、版本沒變」→ 這句只適用於第三條測試的那 7 次,不是全部 21 次
- 日文稿第三段裡對應的那句「62回の試験で毎回成立」→ 同第 1 項一起改
📌 這三處現在不先改,是因為研發若回答「不行」它們會整段消失,改了是白工。但沒改就送出去,等於對客戶講了不實的數字。
📌 本頁是內部工作頁,請勿整頁轉傳或截圖給客戶,也請勿把這個檔案本身寄給客戶或第三方。要給客戶的內容只有第 5 段的日文稿。
現在的狀況
四台機器裡,上排兩台完全正常,這次一根手指都不會碰到。要處理的是左下那台;右下那台已經連不上,是另一件事。
| 機台 | 位置 | 目前狀態 | 最後一次連線台灣時間 GMT+8 | 這次要動它嗎 |
|---|---|---|---|---|
| 0005 | 左上 | 正常 | 09-17 10:00:49 | 不動 |
| 0006 | 右上 | 正常 | 09-17 10:00:40 | 不動 |
| 0007 | 左下 | 連得上,但設定跑掉了 | 09-17 10:01:13 | ✅ 這次處理這一台 |
| 0008 | 右下 | 連不上 | 08-30 00:01:03 | 指令送不到,另案處理 |
你要記住的一句話
左下那台機器本身是好的、電也夠、訊號在還連得上的三台裡最好。壞掉的不是硬體,是一組設定沒有寫進去。
技術細節:我們怎麼知道設定跑掉了
每台機器上有兩個東西會回報給伺服器:主程式(研發稱 APP)和通訊模組(研發稱 DA)。正常情況下通訊模組每 10 分鐘回報一次。
2026-09-02 到 09-17 這 14 天的實際回報次數:
| 機台 | 主程式回報 | 通訊模組回報 |
|---|---|---|
| 0005 左上 | 382 次 | 1,696 次 |
| 0006 右上 | 402 次 | 1,637 次 |
| 0007 左下 | 376 次 | 0 次 |
左下的主程式回報次數和另外兩台一樣正常(376 對 382、402),但通訊模組 14 天一次都沒有回報。這就是「每 10 分鐘回報一次」這組設定沒有被寫進通訊模組的直接證據。
其他健康指標:電壓 4.002V(另兩台 3.996V/4.007V,一樣)、訊號強度 −46(另兩台 −51/−54,左下最好)。
左下那台是怎麼變成這樣的
它不是慢慢壞掉的。是在 8 月 21 日開機的那幾秒鐘裡,兩組設定沒來得及寫進去,然後一直維持到現在。
所以重點是什麼
既然問題是「開機那次沒寫進去」,而且「平常醒來不會重寫」——那讓它完整重新開機一次,設定就會重新寫一遍。
這就是第 3 段要做的事。
技術細節:為什麼設定會被跳過
研發的分析(2026-09-01《Tokozawa 開機競態分析》)指出:省電休眠流程帶有「優先行為」標記——當系統準備進入休眠時,先前還沒執行完的動作會被直接取消,優先執行休眠。
所以只要休眠在「時區/連線頻率送達通訊模組」之前被觸發,這兩個設定動作就會被取消。
之後每小時的休眠喚醒只是 onPause → onResume,不會重跑開機設定流程,因此錯誤狀態會一路持續。
⚠️ 這個缺陷曾在 2025-07-18(commit c09a00e)修正過一次,且該修正已收錄在客戶現在跑的版本裡——但客戶還是中了。代表它仍有機率發生。
我們要做什麼(以及為什麼改了做法)
我們原本評估的是更新軟體版本。但 9 月 16–17 日新做的測試顯示:不用換版本,只要讓機器重新開機一次,設定就會正確寫進去。
既然不換版本就能解決,就沒有理由讓客戶承擔「換版本」的風險。所以做法改了。
讓它重新開機一次
少數情況會失聯(見下)
請人到現場用手機設定
更新軟體版本
這一格就是你說服客戶的關鍵
客戶不會問「你們成功率多少」,客戶會問「萬一失敗怎麼辦」。
重新開機這條路,失敗的絕大多數情況是機器沒有被改變——版本沒變、設定沒變,等於這次指令沒送到而已,可以隔一段時間再試一次。這跟「可能要拆牆」是完全不同量級的事。
⚠️ 但要誠實講一件事:有一種情況例外——機器重開之後、Wi-Fi 還沒連上就先進入省電休眠,那它會連不上(就是右下 0008 現在的樣子)。這個風險重新開機和更新版本都有,不是換做法就能消掉,所以我們才要挑日本當地白天、現場找得到人的時段執行。
技術細節:62 輪測試的實際數據
測試版本與現場完全相同:主程式 1.5.5/通訊模組 0.1.0.17/系統 3.3.5。這點很重要——測試機跟客戶機是同一組版本,數據才適用。
測試區間:2026-09-16 17:47 → 09-17 09:58(16 小時 11 分,台灣時間),共 62 輪。
成功率 88.7%(55 成功/7 失敗)。
重開機之後的設定寫入命中率:
| 設定項 | 送出 | 模組收到 | 寫入成功 | 命中率 |
|---|---|---|---|---|
連線頻率(SVRINTRVL) | 54/54 | 54/54 | 54/54 | 100% |
時區(TZONE) | 54/54 | 54/54 | 54/54 | 100% |
喚醒時間(BSPWAKETIME) | 54/54 | 54/54 | 54/54 | 100% |
報告原文:「七次失敗是同一個病因:裝置端 HTTP 請求拿不到資料。沒有任何一次是重開機本身失敗、重開後版本不對、或 config 內容改變。」
必須誠實告訴客戶的三件事
這三句話一定要講,而且要在動作之前講。日文稿裡都已經寫進去了,這裡是讓你先讀懂,客戶追問時你答得出來。
① 風險不是零
我們沒有辦法保證一定不會出狀況。所沢那三台碰不到電源鍵、reset 鍵、SD 卡槽,萬一遠端處理不了,我們手上的辦法是有限的。
② 指令可能送不到,而且要等 1 到 2 小時才看得出來
左下那台每小時才跟伺服器連線一次,指令要等它下一次連線才會被取走。所以下完指令後前一個小時沒動靜是正常的,不是失敗。
③ 一旦機器開始執行,我們無法從遠端取消
我們能停的是自己後續的動作(不再下第二次指令、轉為現場處置),不是機器上正在跑的程序。
⚠️ 不要說「一有異常我們立刻停止」——我們做不到,這是假承諾。
🚫 四件你絕對不能做的事
①不要講任何金額或費用歸屬(拆牆費用誰負擔,不在這裡談)
②不要講任何安撫性保證(「請放心」「應該沒問題」「不會有事」)
③不要承諾任何完成時程(日期由你跟客戶另行協調,本頁不預設)
④不要延伸到本頁沒寫的設備話題 —— 如果客戶主動問起現場要怎麼處理,請先帶回內部討論再回覆,不要當場承接下來。
技術細節:那 21 次「沒完成」到底發生了什麼
三條測試線合計啟動 179 輪、納入統計 170 輪,其中 21 次作業沒有走完。
重點在失敗的性質,不是次數:這些失敗幾乎都是同一個原因——指令沒有送達機器。這種情況下機器本身沒有任何變化,版本沒變、設定沒變,等於這次指令沒送到而已。
研發也指出:失敗會成簇出現(7 次失敗中有 5 次擠在同一個 95 分鐘內,之後連續 27 輪全數乾淨)。所以失敗後不要立刻重推,至少隔 30 分鐘再試——立刻重試很可能還在同一個故障時段裡。
給客戶的說明稿
左邊是中文對照(給你讀懂用),右邊是日文正式稿(給客戶的)。兩邊段落一一對應,你可以逐段核對。
日文稿按「複製」會得到純文字,直接貼進 LINE 不會出現多餘符號。
在那之前請不要送出,避免我們承諾一個還沒驗證過的做法。
技術細節:這份稿子的措辭為什麼這樣寫
①「バージョンを変更しなくても解決できるのであれば、更新に伴うリスクを貴社に負っていただく理由はない」
這句把「我們改方案」框成「我們主動替你降低風險」,而不是「原方案有問題」。主詞是敝司的判斷,不暴露內部評估過程。
②「指示が機器まで届かなかった」+「機器そのものには何の変化も起きておりません」
21 次失敗必須誠實講,但要同時說清失敗的性質。只說「21 次失敗」會讓客戶以為機器壞了 21 次。
③「この待ち時間は正常なものです」
主動預防客戶在 30 分鐘後追問「是不是失敗了」。每小時才回報一次是現況事實,不是我方拖延。
④ 全篇沒有時程承諾。作業日期由你跟客戶另行協調,稿子不預設。
送出前確認清單
六項全部打勾,下面才會亮綠燈。第 1 項在研發確認前是鎖住的,勾不了。