MQTT 是發佈-訂閱（Pub/Sub）模式，傳送器不需要知道誰在聽，只管發出數據。REST 是請求-回應（Request/Response），每次都要建立連接，開銷大。對於每 5 秒發一次數據的傳送器，MQTT 可節省 60% 頻寬。此外，MQTT 支持 QoS，確保訊息不丟失；REST 無此機制。

取決於 QoS 設定。QoS 0（至多一次）：不保證，可能遺失。QoS 1（至少一次）：AWS IoT Broker 會暫存，等待 ACK，建議用此。QoS 2（恰好一次）：最高可靠性但開銷最大。對於壓力數據，QoS 1 + 30 秒發佈週期是最佳平衡。

4-20mA 是模擬訊號，需要 ADC 轉換才能進 Raspberry Pi，簡單便宜。HART 是數位協議，直接傳送結構化數據（壓力、溫度、診斷代碼），可在一條 4-20mA 訊號線上疊加。如果要預測維保和遠程診斷，建議選 HART（支持自診斷）。如果只是單純監控，4-20mA 就夠。

AWS IoT Core 使用 TLS 1.2 端到端加密，每個設備有獨立的 X.509 憑證和私鑰。即使有人竊聽網路流量，也看不懂內容。此外，IAM 政策限制每個設備只能發佈到特定 topic，無法跨界存取。唯一風險是私鑰洩露，所以保護好 Raspberry Pi 上的 .key 檔案很重要（建議放在只讀分區）。

DynamoDB 是鍵值資料庫，適合查詢特定時間段。Timestream 專為時間序列優化，查詢速度快 10 倍，但只支持時間排序。建議：即時監控用 Timestream（秒級查詢），長期歷史分析用 DynamoDB（便宜）。Amazon S3 則用於存檔（7 年合規要求）。

單個 Raspberry Pi 4（4GB RAM）理論上可連接 100+ 個 ADC/I2C 設備，但實務上受 MQTT 發佈速率限制。如果每個傳送器每 5 秒發一次，300+ 設備會導致 Pi CPU 跑滿。建議：1-50 個傳送器用單 Pi；51-300 個用多個 Pi + AWS IoT Greengrass 聚合；300+ 個則需要工業物聯網網關。

AWS IoT Core 按發送和接收的訊息數計費，每 10 萬訊息 USD 1。例如 50 個傳送器，每 5 秒發一次，月 864 萬訊息 = USD 86/月。DynamoDB 隨需模式約 USD 200-300/月。Timestream 約 USD 600/月（1TB 儲存）。合計約 USD 900/月，遠低於建置自用 server 的成本。

高精度意味著數據噪音少，ML 模型訓練更準。±0.5% 精度的傳送器會產生大量虛假告警（譬如預測維保模型給出的警示不可信）；而 ±0.1% 精度的 ATLANTIS，能幫你的 ML 模型精度從 78% 提升到 92%。這直接轉化為更少的虛假告警、更早的故障預警。

依序執行：1) ssh 進 Pi，ping 8.8.8.8（檢查網路）；2) openssl s_client -connect iot-endpoint:8883（檢查 TLS 連接）；3) tail /var/log/syslog 看系統日誌；4) 檢查憑證檔案（ls -la *.pem）；5) 檢查時間同步（date 應與伺服器一致）。最常見是時間差超 5 分鐘導致憑證驗証失敗。

使用 AWS IoT Device Shadow。Raspberry Pi 訂閱 $aws/things/pressure-sensor-factory-A/shadow/update/delta，當你在 AWS 主控台改變 shadow 的「desired」狀態時，Pi 端會收到訊號並執行對應動作（重啟程式、改發佈週期等）。這樣就不需要 SSH 進機器。

可以，但需評估業務影響。食品冷鏈、半導體需要 5-10 秒週期（快速偵測故障）。一般製造業 30 秒夠了。如果改為 30 秒，成本從 USD 86/月降到 USD 18/月，但故障反應時間延長 25 秒。建議做成動態的：正常時 30 秒，偵測到異常時自動改成 5 秒。

WIKA 是德國老牌，精度高（±0.1%）但價格是 ATLANTIS 的 2.5 倍。Ashcroft 美國製，重工業用途。ATLANTIS 是台灣在地品牌，成立 1992 年，精度 ±0.1% 但價格便宜 40%，且售後服務響應快（24 小時內到廠）。如果要性價比，ATLANTIS；如果要國際認證和超長使用壽命，選 WIKA。對 AWS IoT 應用，精度相同，選便宜的就好。

304：一般環境，成本低，壽命 3-5 年。316L：含氯離子（食品鹽醃、海邊）、有機酸（製藥），壽命 5-8 年。Hastelloy：強酸強鹼（化工廠）、高溫 > 100°C，壽命 8-10 年。AWS IoT 應用一般用 304 就夠，除非是製藥/食品才升級到 316L。

最小可行架構：傳送器（0-10 bar）→ Raspberry Pi（采集 + 發佈 MQTT）→ AWS IoT Core（Broker）→ DynamoDB（存儲）→ CloudWatch（監控）→ SNS（告警）。進階架構加 IoT Greengrass（邊緣運算）做預過濾、加 SageMaker（預測維保）、加 QuickSight（實時儀表板）、加 S3（長期存檔）。最好繪成流程圖，清楚標示各元件和資料流向。

可能是 Raspberry Pi 性能不足（CPU > 80% 使用率）、網路封包遺失導致 retransmit、或 AWS 那端处理缓慢。排查：1) top 看 Pi 的 CPU；2) mtr -r 20 iot-endpoint 量測延遲和掉包率；3) 在 Pi 上 tcpdump 看 MQTT 發出的時間點；4) 改用 MQTT 5.0 的 Request Response 能更精確測延遲。

不需要。有三種方式：1) AWS Amplify + React Native 快速開發原生 App；2) 使用 AWS IoT console 內建的 MQTT 測試用戶端（簡單但功能有限）；3) 用 Grafana 或 QuickSight 開放 Web 版儀表板（推薦）。Grafana 可連接 DynamoDB/Timestream，繪製即時圖表，支持行動裝置自適應。

正常使用下，ATLANTIS 傳送器壽命 5-10 年，取決於環境（溫度、腐蝕性）。保固 2 年，涵蓋製造缺陷。故障通常是隔膜腐蝕穿孔或應變片斷線（罕見）。昶特在台北北投設有倉儲，常用型號有現貨，可 24 小時內出貨，故障更換不會中斷生產。

技術上支持（MQTT 允許 UTF-8），但不推薦。因為編碼轉換容易出錯，跨平台相容性差。建議用英文 snake_case：sensor/pressure/factory-a/zone-01，而不是 傳感器/壓力/工廠-A。這樣代碼維護更容易，也符合工業標準。

有三個方案：1) 直接連 AWS：PLC 本身支持 MQTT（西門子 S7-1200+、施耐德 M241），可直接發 IoT Core；2) 橋接模式：用 Raspberry Pi 或工業網關作 OPC-UA to MQTT 轉換器；3) 雲端聚合：PLC 走傳統 Modbus/Ethernet，AWS IoT Greengrass 從 PLC 拉數據再轉 MQTT 發到 IoT Core。推薦方案 2（最靈活）。

IoT Core 故障罕見（AWS SLA 99.9%），但若發生，Raspberry Pi 會自動重連。關鍵是啟用「離線發佈佇列」（Offline Publish Queue）：當 IoT Core 無法連接時，Pi 會將訊息暫存在本地（預設 100 MB），待連接恢復自動同步。此外，建議在 Pi 上部署本地監控邏輯（例：壓力 > 9 bar 立刻切緊急洩壓閥），不依賴雲端。