所沢四拼接 · 左下那台的處理說明

這頁是給你的工作頁。讀完之後,你可以自己跟 Oricom 說明我們要做什麼、以及風險在哪裡。

對象 Oricom(まさふみ 先生) 機台狀態查詢時間 2026-09-17 10:03台灣時間 GMT+8 本頁更新 2026-09-17

🔴目前尚不可送出給客戶

我們打算做的動作(讓左下那台機器重新啟動一次),還有一個技術前提沒有跟研發確認完。在確認之前,本頁最下方的日文稿請先不要送出去。

  • 要確認什麼:左下那台目前每小時才跟伺服器連線一次。研發要回答的是「我們下的重新啟動指令,機器在那一次連線時收得到、而且真的會去執行嗎?」
  • 誰能回答:研發(Karote/Daniel Yu)

⚠️ 研發的回答有兩種,結果完全不一樣

回答「可以」

本頁繼續使用。但不是把鎖打開就好——解鎖前還有三個地方必須先修,清單在下面。

回答「不行」

這一頁整份作廢。第 3 段的做法、第 5 段的日文稿、下面的確認清單全部不能用了——因為那時候要改走「請人到現場用手機設定」,那是另一套說法、另一份稿子。

🔒 這種情況下請不要自己動這一頁,我會另外給你一份全新的頁面。把鎖打開不等於可以送。

✅ 只有在研發回答「可以」時,解鎖前必須先修這三處

  1. 第 3 段技術細節裡「62 次試驗每一次都成立」→ 要改成正確的次數(62 輪裡有 7 輪失敗,實際驗證到的是 54 次,另有 1 次待研發確認)
  2. 第 3 段技術細節裡「21 次都是指令沒送到、版本沒變」→ 這句只適用於第三條測試的那 7 次,不是全部 21 次
  3. 日文稿第三段裡對應的那句「62回の試験で毎回成立」→ 同第 1 項一起改

📌 這三處現在不先改,是因為研發若回答「不行」它們會整段消失,改了是白工。但沒改就送出去,等於對客戶講了不實的數字

📌 本頁是內部工作頁,請勿整頁轉傳或截圖給客戶,也請勿把這個檔案本身寄給客戶或第三方。要給客戶的內容只有第 5 段的日文稿。

✅ 技術前提已確認。請先完成上方三處修正,再把下面六項確認清單全部打勾,才可以送出。
1

現在的狀況

四台機器裡,上排兩台完全正常,這次一根手指都不會碰到。要處理的是左下那台;右下那台已經連不上,是另一件事。

機台位置目前狀態最後一次連線台灣時間 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,左下最好)。

2

左下那台是怎麼變成這樣的

它不是慢慢壞掉的。是在 8 月 21 日開機的那幾秒鐘裡,兩組設定沒來得及寫進去,然後一直維持到現在。

2026-08-21(當天,時刻無紀錄)
機器開機
開機時要做很多事。其中「寫入時區」和「寫入連線頻率」這兩件,還沒做完就被後面的省電流程插隊跳過了。
8 月 21 日之後
每小時醒來換圖,但設定一直沒補上
機器平常是睡著的,時間到才醒來換一張圖。這種醒來不會重跑開機流程,所以那兩組設定沒有機會被補寫進去。
2026-08-30 01:01日本時間
右下那台在同樣的狀況下失聯
失聯當下電池 4.296V、訊號 −49,都是健康的。它不是沒電,是睡下去之後沒有再醒來。
2026-09-17(今天)
左下還在線上,但設定仍然沒補上
已經維持這個狀態 27 天。機器活著、看得到、指令也還送得到,但那兩組設定始終是空的。

所以重點是什麼

既然問題是「開機那次沒寫進去」,而且「平常醒來不會重寫」——那讓它完整重新開機一次,設定就會重新寫一遍。

這就是第 3 段要做的事。

技術細節:為什麼設定會被跳過

研發的分析(2026-09-01《Tokozawa 開機競態分析》)指出:省電休眠流程帶有「優先行為」標記——當系統準備進入休眠時,先前還沒執行完的動作會被直接取消,優先執行休眠。

所以只要休眠在「時區/連線頻率送達通訊模組」之前被觸發,這兩個設定動作就會被取消。

之後每小時的休眠喚醒只是 onPause → onResume不會重跑開機設定流程,因此錯誤狀態會一路持續。

⚠️ 這個缺陷曾在 2025-07-18(commit c09a00e)修正過一次,且該修正已收錄在客戶現在跑的版本裡——但客戶還是中了。代表它仍有機率發生。

3

我們要做什麼(以及為什麼改了做法)

我們原本評估的是更新軟體版本。但 9 月 16–17 日新做的測試顯示:不用換版本,只要讓機器重新開機一次,設定就會正確寫進去。

既然不換版本就能解決,就沒有理由讓客戶承擔「換版本」的風險。所以做法改了。

我們要做這個

讓它重新開機一次

需不需要人去所沢不用
會不會換軟體版本不會,完全不動
同版本測過幾輪62 輪
🔑 失敗了機器會怎樣多數情況沒變,可再試;
少數情況會失聯(見下)
備案

請人到現場用手機設定

需不需要人去所沢要(需 iPhone)
會不會換軟體版本不會
同版本測過幾輪1 次
🔑 失敗了機器會怎樣白跑一趟
暫時不做

更新軟體版本

需不需要人去所沢不用
會不會換軟體版本會,而且換了回不去
同版本測過幾輪108 輪,但版本會被改變
🔑 失敗了機器會怎樣可能需要拆牆處理

這一格就是你說服客戶的關鍵

客戶不會問「你們成功率多少」,客戶會問「萬一失敗怎麼辦」。

重新開機這條路,失敗的絕大多數情況是機器沒有被改變——版本沒變、設定沒變,等於這次指令沒送到而已,可以隔一段時間再試一次。這跟「可能要拆牆」是完全不同量級的事。

⚠️ 但要誠實講一件事:有一種情況例外——機器重開之後、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 失敗)。

重開機之後的設定寫入命中率:

設定項送出模組收到寫入成功命中率
連線頻率(SVRINTRVL54/5454/5454/54100%
時區(TZONE54/5454/5454/54100%
喚醒時間(BSPWAKETIME54/5454/5454/54100%

報告原文:「七次失敗是同一個病因:裝置端 HTTP 請求拿不到資料。沒有任何一次是重開機本身失敗、重開後版本不對、或 config 內容改變。

4

必須誠實告訴客戶的三件事

這三句話一定要講,而且要在動作之前講。日文稿裡都已經寫進去了,這裡是讓你先讀懂,客戶追問時你答得出來。

① 風險不是零

我們沒有辦法保證一定不會出狀況。所沢那三台碰不到電源鍵、reset 鍵、SD 卡槽,萬一遠端處理不了,我們手上的辦法是有限的

客戶追問時你可以這樣講:「我們能做的是選擇萬一失敗時對機器改變最小的做法,並且全程監看。但我們不會跟您說絕對不會出事。」

② 指令可能送不到,而且要等 1 到 2 小時才看得出來

左下那台每小時才跟伺服器連線一次,指令要等它下一次連線才會被取走。所以下完指令後前一個小時沒動靜是正常的,不是失敗。

客戶追問時你可以這樣講:「請在作業開始後約 1 到 2 小時再看連線間隔。這段等待是正常的。超過 2 小時還沒變化,我們會另行說明。」

③ 一旦機器開始執行,我們無法從遠端取消

我們能停的是自己後續的動作(不再下第二次指令、轉為現場處置),不是機器上正在跑的程序

客戶追問時你可以這樣講:「若出現異常,我方會停止後續操作並轉為現場處置。」
⚠️ 不要說「一有異常我們立刻停止」——我們做不到,這是假承諾。

🚫 四件你絕對不能做的事

①不要講任何金額或費用歸屬(拆牆費用誰負擔,不在這裡談)
②不要講任何安撫性保證(「請放心」「應該沒問題」「不會有事」)
③不要承諾任何完成時程(日期由你跟客戶另行協調,本頁不預設)
④不要延伸到本頁沒寫的設備話題 —— 如果客戶主動問起現場要怎麼處理,請先帶回內部討論再回覆,不要當場承接下來。

技術細節:那 21 次「沒完成」到底發生了什麼

三條測試線合計啟動 179 輪、納入統計 170 輪,其中 21 次作業沒有走完

重點在失敗的性質,不是次數:這些失敗幾乎都是同一個原因——指令沒有送達機器。這種情況下機器本身沒有任何變化,版本沒變、設定沒變,等於這次指令沒送到而已。

研發也指出:失敗會成簇出現(7 次失敗中有 5 次擠在同一個 95 分鐘內,之後連續 27 輪全數乾淨)。所以失敗後不要立刻重推,至少隔 30 分鐘再試——立刻重試很可能還在同一個故障時段裡。

5

給客戶的說明稿

左邊是中文對照(給你讀懂用),右邊是日文正式稿(給客戶的)。兩邊段落一一對應,你可以逐段核對。

日文稿按「複製」會得到純文字,直接貼進 LINE 不會出現多餘符號。

此版本僅供你理解內容,不要送給客戶
まさふみ 先生 承蒙關照。關於所沢左下 0007,向您報告目前的驗證狀況與這次的提案。 【至今的驗證內容】 自 9 月 7 日起,我們在公司內部進行了三條自動化測試。 前兩條測試的是「遠端更新軟體版本」(應用程式 1.5.5 至 1.6.4,以及通訊韌體)的流程。第三條是 9 月 16 至 17 日新增的,測試的是不更動任何版本、只讓機器重新啟動一次,設定能否正確寫入。 三條測試線使用不同機體與運作模式,合計啟動 179 次,其中 170 次納入統計。其餘因測試工具本身的判定問題而不採計。各工序的時間與結果全部自動記錄。 驗證的重點是:8 月 21 日在所沢發生的狀況,也就是重新啟動時時區與通訊間隔的設定未能完整寫入通訊模組,用哪一種方法可以最安全地解決。 【目前的結論】 驗證過程中找到了更安全的方法,因此這次的提案與當初的設想不同。 當初我們評估的是更新左下 0007 的軟體。但第三條測試顯示,在與所沢完全相同的軟體版本下,只要讓機器重新啟動一次,設定就會正確寫入。62 次試驗中,這一項每一次都成立。既然不變更版本就能解決,我們認為沒有理由讓貴司承擔更新所帶來的風險。 因此,這次的提案是:讓左下 0007 重新啟動一次,軟體版本完全不變更。 接下來是必須誠實告知的部分。 納入統計的 170 次中,有 21 次作業未能走到最後。原因幾乎相同,都是指令未能送達機器。這些情況下機器本身沒有發生任何變化,版本與設定都維持原樣,只是指令沒有送到。 不過,所沢的機器與測試環境條件不同。敝司能夠遠端進行的處置有限,作業中若發生異常,無法向您保證一定能夠遠端復原。這一點我們認為應該在作業前明確告知。 因此,對於「風險是否為零」這個問題,敝司的回答是:不是零。我們無法保證絕對不會發生問題。敝司能做的,是選擇萬一失敗時對機器變動最小的方法,將可能受影響的範圍縮到最小,作業中全程監看,若有異常則停止後續操作並轉為現場處置。 再補充一點。指令一旦在機器端開始執行,敝司無法從遠端將其取消。能夠停止的是敝司這邊的後續動作,而不是機器上正在進行的處理。 【這次的作業範圍】 左上 0005 與右上 0006 目前運作正常,這次完全不會碰觸。要作業的只有左下 0007 一台。右下 0008 目前與伺服器沒有通訊,遠端指令無法送達,不在這次的範圍內。 只針對左下一台的理由是:這台正是目前出現設定異常的機器,即使在這裡作業不順利,也不會影響正常運作中的上排兩台。 這次的作業不會下載任何檔案,也沒有版本變更。機器重新啟動後,會將時區與通訊間隔重新寫入通訊模組。這正是 8 月 21 日沒有完成的動作。作業前後左下 0007 的軟體版本應該維持相同,敝司也會將此列為確認項目之一。 作業中會全程確認通訊記錄。若指令長時間未被機器取得,或狀態未如預期變化,屆時將中止本次作業。是否再次實施,會在確認機器狀態、間隔一段時間後判斷,並事先與貴司聯繫。 實施日期方面,為了萬一時能立即與貴司聯繫,會配合所沢當地時間的日間時段調整。 【貴司可以自行確認的指標】 作業若順利進行,最快也最確實的判斷方式,是 CMS 上左下 0007 的通訊間隔。 目前是每小時一次。成功的話會回到每 10 分鐘一次。左下 0007 目前每小時才與伺服器通訊一次,因此指令要等到這台機器下一次通訊時才會被取得。請在作業開始後約 1 至 2 小時再確認,這段等待時間是正常的。畫面切換綁定在每個整點,因此看通訊間隔會比看畫面更快也更正確。 若作業開始後超過 2 小時仍維持每小時一次,代表這次作業未達預期。屆時會再向您說明。 還有一點可以確認:作業前後左下 0007 的軟體版本應該不會改變。若發現版本有變化,請立即通知敝司。 【關於右下 0008 想先說明的事】 右下 0008 自 8 月 30 日 1 時 01 分(日本時間)之後,與伺服器沒有通訊。 由於電子紙的特性,畫面會維持在最後更新的內容。因此外觀上看起來像是仍在顯示,實際上內容的更新已經停止。 這裡有一個容易產生誤解的現象。某些時段右下的畫面會剛好與上排相同,看起來像是恢復了。但到了下一個整點,只有上排會切換,右下不會,於是又變成不一致。這兩種樣子會每小時交替出現。 因此,請不要以「右下畫面看起來與上排相同」來判斷它已經恢復。0008 的實際狀態,請以 CMS 上是否有新的通訊記錄來確認。 0008 的處置與這次左下的作業是兩件事,會再另行與貴司討論。 再麻煩您了。
日文正式稿 · 可直接貼入 LINE(複製出來是純文字,不含任何格式符號)
まさふみ様 お世話になっております。所沢の左下0007について、現在の検証状況と今回のご提案をご報告いたします。 これまでの検証内容 9月7日から、社内で3系統の自動化テストを実施しております。 前の2系統は、ソフトウェアのバージョン更新(アプリ1.5.5から1.6.4、および通信ファームウェア)を遠隔で行う流れを検証したものです。3系統目は9月16日から17日にかけて追加したもので、バージョンを一切変更せず、機器を1回再起動するだけで設定が正しく書き込まれるかを検証しております。 3系統で異なる機体と動作モードを使い、合計179回開始し、うち170回を統計の対象としております。残りはテストツール側の判定に起因して不採用としたものです。各工程の時刻と結果はすべて自動で記録しております。 検証の主眼は、8月21日に所沢で発生した事象、つまり再起動時にタイムゾーンと通信間隔の設定が通信モジュールへ完全に書き込まれない問題を、どの方法で最も安全に解消できるかという点です。 現時点の結論 検証の過程で、より安全な方法が見つかりました。そのため今回のご提案は当初の想定と異なります。 当初は左下0007のソフトウェアを更新する方法を検討しておりました。しかし3系統目の検証で、所沢と全く同じソフトウェアバージョンのまま機器を1回再起動するだけで設定が正しく書き込まれることが分かりました。62回の試験で、この項目は毎回成立しております。バージョンを変更しなくても解決できるのであれば、更新に伴うリスクを貴社に負っていただく理由はないと弊社は考えます。 したがいまして、今回のご提案は、左下0007を1回再起動する、ソフトウェアのバージョンは一切変更しない、というものです。 次に、正直にお伝えしなければならない点です。 統計対象の170回のうち、作業が最後まで完了しなかったケースが21回ございました。原因はほぼ同一で、指示が機器まで届かなかったというものです。これらの場合、機器そのものには何の変化も起きておりません。バージョンも設定もそのままで、指示が届かなかっただけという状態です。 ただ、所沢の機器はテスト環境とは条件が異なります。弊社が遠隔で行える対処には限りがあり、作業中に異常が発生した場合、必ず遠隔で復旧できるとお約束することはできません。この点は作業の前に明確にお伝えしておくべきと考えました。 したがいまして、「リスクはゼロか」というご質問に対する弊社の回答は、ゼロではございません。絶対に問題が起きないと保証することはできません。弊社にできるのは、万一失敗した際に機器への変化が最も小さい方法を選び、影響が及びうる範囲を最小限に絞り、作業中は常時監視して、異常があれば後続の操作を停止し現地対応へ切り替えることです。 もう一点、正直に補足いたします。指示がいったん機器側で実行され始めますと、弊社から遠隔でそれを取り消すことはできません。止められるのは弊社側の次の動作であって、機器上で進行中の処理ではございません。 今回の作業範囲 左上0005と右上0006は現在正常に動作しておりますので、今回は一切触れません。作業を行うのは左下0007の1台のみです。右下0008は現在サーバーとの通信がないため、遠隔からの指示が届きません。今回の対象外となります。 左下1台に絞る理由は、この機体が現在まさに設定異常の出ている台であり、ここで仮にうまくいかなくても、正常稼働中の上段2台には影響が及ばないためです。 今回の作業では、ファイルのダウンロードは一切行いません。バージョンの変更もございません。機器が再起動した後、タイムゾーンと通信間隔を通信モジュールへ書き込み直します。これはまさに8月21日に完了しなかった動作です。作業の前後で左下0007のソフトウェアバージョンは同一のままとなるはずで、弊社もこれを確認項目のひとつといたします。 作業中は通信記録を常時確認いたします。指示が長時間機器に取得されない場合、または状態が想定どおりに変化しない場合は、その時点で今回の作業を打ち切ります。再度実施するかどうかは、機器の状態を確認し、一定の時間を空けたうえで判断し、事前に貴社へご連絡いたします。 実施日につきましては、万一の際に貴社とすぐご連絡が取れるよう、所沢の現地時間で日中の時間帯に合わせて調整いたします。 貴社側でご確認いただける目安 作業が順調に進んだ場合、最も早く確実に判断できるのはCMS上の左下0007の通信間隔です。 現在は1時間に1回です。成功すれば10分に1回へ戻ります。左下0007は現在1時間に1回しかサーバーと通信しておりませんので、指示は次にこの機体が通信するタイミングまで取得されません。そのため作業開始からおよそ1時間から2時間後を目安にご確認ください。この待ち時間は正常なものです。画像の切り替わりは毎正時に紐づいているため、画面でご判断いただくより通信間隔のほうが早く、かつ正確です。 作業開始から2時間を過ぎても1時間に1回のままであれば、今回の作業は期待どおりに至らなかったということになります。その場合は改めてご説明いたします。 もう一点ご確認いただける点がございます。作業の前後で左下0007のソフトウェアバージョンは変わらないはずです。もしバージョンに変化が見られた場合は、すぐに弊社までお知らせください。 右下0008について先にお伝えしたいこと 右下0008は8月30日1時01分(日本時間)以降、サーバーとの通信がございません。 電子ペーパーの特性上、画面は最後に更新された内容のまま残ります。そのため外見上は表示が続いているように見えますが、実際には内容の更新が止まっております。 ここで誤解が生じやすい現象がございます。時間帯によっては、右下の画像がたまたま上段と同じになることがあり、復旧したように見えます。ただし次の正時になると上段だけが切り替わり、右下は変わりませんので、再び不一致になります。この2つの見え方が1時間ごとに交互に現れます。 そのため、右下の画面が上段と同じに見えることをもって復旧したとご判断なさらないようお願いいたします。0008の実際の状態は、CMS上に新しい通信記録があるかどうかでご確認ください。 0008への対応と今回の左下の作業は別件として、改めて貴社とご相談させていただきます。 よろしくお願いいたします。
🔒 日文稿目前鎖定中 研發確認技術前提之後就會解鎖。
在那之前請不要送出,避免我們承諾一個還沒驗證過的做法。
技術細節:這份稿子的措辭為什麼這樣寫

①「バージョンを変更しなくても解決できるのであれば、更新に伴うリスクを貴社に負っていただく理由はない」
這句把「我們改方案」框成「我們主動替你降低風險」,而不是「原方案有問題」。主詞是敝司的判斷,不暴露內部評估過程。

②「指示が機器まで届かなかった」+「機器そのものには何の変化も起きておりません」
21 次失敗必須誠實講,但要同時說清失敗的性質。只說「21 次失敗」會讓客戶以為機器壞了 21 次。

③「この待ち時間は正常なものです」
主動預防客戶在 30 分鐘後追問「是不是失敗了」。每小時才回報一次是現況事實,不是我方拖延。

④ 全篇沒有時程承諾。作業日期由你跟客戶另行協調,稿子不預設。

6

送出前確認清單

六項全部打勾,下面才會亮綠燈。第 1 項在研發確認前是鎖住的,勾不了。

還有項目未完成

資料來源與時效 機台狀態:CMS 實查 2026-09-17 10:03|重新啟動測試:2026-09-16 17:47 → 09-17 09:58(62 輪)|開機時序問題分析(內部文件《Tokozawa 開機競態分析》):2026-09-01

對應內部文件 Oricom_CMS_OTA風險評估_內部版_260916.md(不得對客提供或節錄)/..._業務轉述版_260916.md

本頁為內部工作頁,請勿整頁轉傳或截圖給客戶。