物聯網開發筆記 (十三) 大改

目前的整體完成度應該在 80%,剩下 iOS 的 UI 和部份 api 串接,內容有介紹相關的新增功能與改動地方。

物聯網開發筆記 (十三) 大改
Photo by Mr. Bochelly / Unsplash

自從上一篇文章到現在也將近兩個多月,中間原本將方向改往使用 Supabase 當作後端管理,都已經開始進行資料庫設計之後才發現 Supabase 最重要的第三方登入功能居然被鎖住了,只有他們自家的託管可以使用,果斷放棄回到 Firebase + 自架 Server 的方案。


API Server

使用 Go lang 來開發的 Server,目前狀態都已經穩定運行,搭配 PostgreSQL 目前體驗很良好,也串接好 Firebase Admin 實作 User 相關驗證,目前僅剩 FCM 推播功能還沒有串。

日誌系統

將 Log 串接 Nas 的日誌系統,搭配優先級直接讓 Nas 處理相關層級的錯誤推送通知。

MQTT

之前使用 Firebase functions 是在上面開一個 MQTT connect 來發送發完再關閉,超級耗時這次直接改用 api 發要傳遞的 topic 跟 msg,直接讓 mqtt server 處理。


Edge 邊緣裝置

使用之前購買的 Nvidia 的 jetson nano 平台來開發,之前寫的 python 架構擴充不易,這次直接完全重寫。

Log System

在前一代的架構中,偶爾會發生中間死掉的狀況,由於設備地太遠,Jetson nano 目前也沒有找到可以遠端的軟體,所以很難抓到問題,為了維持設備可以接續使用都是直接斷電重開機,這次翻新 Log System 會將 Log 先寫在 local 端一份 txt 內,每次 python 有啟動時直接打 Api 存進 Nas 內方便抓錯。

Local Data

之前的架構完全是抓取 Firestore 內存的資料來運作,沒有考量到網路斷線這一個問題,通常停電或跳電時,Jetson nano 已經啟用完畢,當網路設備可能還在重新開機中,所以多設計了一個本地資料庫來儲存,遇到啟動沒有網路時可以先抓過往的資料來運作。

Heartbeat

過往的設計要發現 python 掛了或停電等沒有運作,都要等運作時間到但沒收到通知時才會知道,有時候沒看到還會隔好幾天才發現,這次採用 MQTT 方式來定時發送訊息,若設備多次無回應或 Mqtt api 回傳無訂閱時直接銜接 Nas 內的日誌進行警報推送。


MQTT

目前MQTT 也換上使用 SSL 來增加安全性, 當前採用的方案是 EMQX 提供的 Serverless 來運行,在免費方案的限制下應該可以維持免費使用。


iOS App

採用 SwiftUI 進行開發,目前開發進度大約完成 70%,但還有許多的 UI 想要重新設計一下,相關更新資料目前 Edge 端反應非常快速,希望七月底可以完成,由於很多畫面都還在亂做中,目前是先串 api 來驗證 server 跟 edge 端的邏輯是否正常,圖片的部分就之後再分享出來。

Android App

之前只有設計 iOS 版本的 app,但因為我自己使用 Android 手機,我自己有時候要改設定時都需要直接從後台更新,如果有時間也設計一款 Android 版的 app 讓我自己操控。

但這樣 Server 要再開發好友同時控管的相關權限功能😂