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

余閏，王慧

湖北工業(yè)大學，湖北武漢，430068

0 引言

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

表1 國內(nèi)典型藥盒實例

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

1 設計方案

1.1 總體設計

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

圖1 總體系統(tǒng)框圖

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

1.2 硬件設計

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

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

圖2 硬件整體框架圖

1.3 設備端軟件設計

本方案在硬件端的MCU主程序圖如圖3所示，具體包括兩個大的狀態(tài)，即聯(lián)網(wǎng)狀態(tài)和未聯(lián)網(wǎng)狀態(tài)。

圖3 主程序流程圖

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

1.3.1 服務器軟件搭建

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

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

圖4 服務器通信模型

1.3.2 微信小程序

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

圖5 微信小程序功能圖

2 系統(tǒng)測試

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

2.1 實時可靠性

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

表2 數(shù)據(jù)延時和丟包部分示例

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

2.2 設備的功耗

在常溫條件下，對處于不同狀態(tài)下的設備進行功耗測量，具體數(shù)據(jù)見表3。

表3 不同狀態(tài)下設備功耗

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

2.3 鬧鐘功能精準度

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

表4 鬧鐘功能測試表

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

3 結(jié)語

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