基于ESP32的智能藥盒輕量級方案設計

余閏，王慧

湖北工業大學，湖北武漢，430068

0 引言

我國老人占全國人口的比重在不斷加大，截至2018年我國老年人口高達2.5億人，其中獨居老和空巢老人增加到了1.18億人[1]。并且老年人的慢性病患病情況由2015年的44.81%上升到2021年的54.52%[2]，空巢老人獨自服藥的問題變得十分突出。根據調查，老年人平均用藥品種有五六種[3]，但我國市場上銷售的智能藥盒產品種類卻十分有限，現有產品普遍都不能滿足消費者的需求。國內典型藥盒的功能設計分析如表1所示，總體表現為功能十分單一，不具有實時監測等聯網功能[4]。

表1 國內典型藥盒實例

在國內市面上的常見藥盒都沒有實時監控以及提醒的功能，成本相對也較高。如今伴隨著通信技術的普及和物聯網的快速發展，針對老年人經常忘記吃藥的問題，本文設計出一種居家智能藥盒解決方案，其可以聯網使用，通過MQTT協議將吃藥信息傳輸到服務器并保存到數據庫中。其支持微信小程序顯示設備狀態、查詢數據庫內容、刪除已設鬧鐘、設定時間、精準設定語音和燈光提醒。其支持OLED面板顯示當前城市時間與天氣、室內溫濕度、吃藥記錄以及接收服務器信息。

1 設計方案

1.1 總體設計

整個系統框圖如圖1所示。該系統包括三個大的方面：硬件設備端（如ESP32為主控的設備端），服務器后端，軟件應用前端。

圖1 總體系統框圖

硬件設備端通過WiFi與路由器相連接入互聯網之后，便可基于TCP協議的應用協議MQTT與云服務器進行通信，主要用于傳輸ESP32采集到的數據，以及來自應用前端的指令。首先，移動應用端是通過蜂窩網絡或者路由器連接上互聯網之后與云服務器進行通信，然后通過服務器介質獲取硬件設備端的狀態，隨后傳輸指令和訪問服務器中的數據庫。

1.2 硬件設計

本文介紹的硬件方案主要采用的是ESP32芯片作為主控芯片，滿足標準的TCP/UDP Client要求[5]，藍牙與WiFi集成其中，功耗小、成本低。最高主頻可達到240MHz，內置雙核處理器，滿足實時處理數據信息以及OLED實時顯示動畫的要求。

硬件整體框架圖如圖2所示，此方案主要由四大部分組成，其中復制電路中的電源轉換電路采用的是典型的Buck電路設計，LM2596能將8～24V的電壓穩定到5V輸出，最大輸出電流能達到3A，具有完善的保護電路[6]。由于自身是開關電源設計，因此其損耗只有肖特基二極管以及MOS在開關時的損耗，損耗小，并且可以達到額定15W的輸出，滿足系統整體供電需求。在音放電路中，由于老年人的聽力衰減比較嚴重，因此就需要大的音量來提醒老年人按時服用藥物。本方案采用的功率放大電路則是采用D類功放芯片LTK5128D來驅動喇叭，此芯片效率高，最高可輸出5W功率，滿足大音量的設置要求。

圖2 硬件整體框架圖

1.3 設備端軟件設計

本方案在硬件端的MCU主程序圖如圖3所示，具體包括兩個大的狀態，即聯網狀態和未聯網狀態。

圖3 主程序流程圖

ESP32上電之后會對所有傳感器和OLED屏幕進行初始化操作。如果設備當前處于未連接上網絡狀態，首先ESP32會讀取內存中儲存的上一次保存的WiFi名稱以及密碼，并進行聯網操作。若超時未成功，設備則會重新配網，然后設備打開WiFi熱點。當手機連接到當前的WiFi熱點，ESP32會將寫進程序的網頁發送到手機端，此網頁包括附近WiFi熱點信息以及提交WiFi密碼和名稱的輸入框。當用戶通過手機輸完目標WiFi名稱和密碼時，ESP32會將得到的數據儲存到內存中，并進行復位，程序重新運行。當設備處于聯網的狀態時，ESP32會通過MQTT協議與服務器進行通信，訂閱主題、監聽端口信息；若服務器有消息輸入，則處理對應事務，例如時間、消息留言板信息、數據庫回傳信息事務等。若藥盒蓋打開則發送消息到服務器，服務器則記錄數據到數據庫。由于ESP32本身是雙核處理器，因此可以多開線程。另一個線程則主要處理OLED顯示屏的動態顯示，以及每隔一段時間發送當前采集到的溫度與濕度數據到服務器[7]。

1.3.1 服務器軟件搭建

本文采用搭載了EMQ環境和MySQL數據庫的服務器來搭建一個MQTT服務端的方案。由于本文主要介紹的方案是輕量級的，所以數據量不會特別龐大，因此采用了MySQL數據庫來管理吃藥的次數與時間等相關數據。在Python腳本程序的控制下，服務器可以動態化管理數據庫。當接收到設備端或者移動端發來的指令時，對MySQL數據庫中的數據進行增刪查改等操作。

搭載物聯網環境與數據庫的服務器通信模型如圖4所示，其主要是在服務器內部由python程序來進行數據管理。在服務器外部，設備端通過MQTT協議與1883端口進行數據通信，管理端則是通過連接服務器的18083端口來對后臺物聯網平臺進行管理；在服務器外部另外一側的微信小程序部分，由于騰訊公司規定小程序只能用WSS協議與認證的443端口進行通信，因此我們還需用Nginx將其數據轉發到8084端口，連接上物聯網環境平臺。

圖4 服務器通信模型

1.3.2 微信小程序

微信小程序的前端設計主要采用綠色為主色調。小程序主要包括兩個界面，功能如圖5所示。主頁主要是接收設備端的濕度溫度數據、在線狀態、所在城市氣溫狀態的數據，也可以輸入要發送至設備端留言板的內容；數據庫查詢頁主要是對數據庫里的內容進行增刪查改操作的界面，不僅能夠直接對硬件設備端進行控制，也可對數據庫直接控制。此設計具有輕型化、實用性、實時性、系統完整性的特點[8]，非常符合輕型化物聯網開發方案的要求。

圖5 微信小程序功能圖

2 系統測試

整個系統的成本在于硬件端，其個體成本不超過40元。租用輕量級服務器的價格在一年70塊，但是隨著設備的增多，其服務器成本就微乎其微，因此成本較低。在其他方面，本節主要對上述系統進行測試，測試分別從實時可靠性、低功耗、精準性這三個方面進行。

2.1 實時可靠性

本項在整個系統程序的功能不變的情況下，通過設備端向服務器方發送一個指令并用串口打印發送完成，觀察服務器端是否接收到指令，是否存在丟包現象，以及在未丟包的情況下傳輸延遲情況。具體情況如表2所示。

表2 數據延時和丟包部分示例

本次測量是從2022年4月16日19:36開始的，采樣次數百次，設備端與服務器通信的時間延時大約1秒鐘，未出現丟數據情況。時間差是通過記錄設備端的串口打印時間與服務器接收數據的時間的差值得來，由于設備串口打印時間也需要耗費時間，因此實際傳輸延時時間少于1秒[9]。本實驗結果證明該系統傳輸穩定可靠，能夠滿足實時監測并記錄數據的要求。

2.2 設備的功耗

在常溫條件下，對處于不同狀態下的設備進行功耗測量，具體數據見表3。

表3 不同狀態下設備功耗

本次分別測量了硬件設備處于3種工作狀態下的功耗。當處于未聯網的狀態時，由于ESP32處于STA情況下，需要向外發射WiFi信號，因此功耗會比聯網情況下高許多。當處于聯網并且語音播報工作的情況下時，由于喇叭需要消耗能量，因此會有5W左右的能量損耗，符合設計要求。總的來說，硬件系統的各個工作狀態都符合低功耗的要求。

2.3 鬧鐘功能精準度

本項是通過移動應用前端設置鬧鐘時間，然后指定時間到達后，設備端串口打印數據。根據串口打印時間戳與指定時間的插值來評判鬧鐘功能是否精準，見表4。

表4 鬧鐘功能測試表

此表采樣收集數據5次，平均誤差2.74s，最大誤差不超過4s。此誤差產生的原因是由于服務器要一直讀取動態數據庫的數據，因此不能精準到只有1秒鐘的誤差。但是此誤差范圍還是符合實用性標準的，因此具有實用性。

3 結語

本方案對市面上的智能藥盒存在的功能單一、不能實時聯網的問題進行了解決，提供了一個成本低、功耗小、實用性高、實時聯網的輕量級解決設計。但目前本設計只是解決了智能藥盒實時監控的設計，相信在不遠的未來，智能藥盒一定能夠實現智能配藥的功能，從此老年人不用再擔心吃錯藥或者要吃多少的問題了。