分布式室內(nèi)空氣質(zhì)量監(jiān)測系統(tǒng)設(shè)計

曾愷昀，孫玉國，陳明璽

（上海理工大學(xué)光電信息與計算機(jī)工程學(xué)院，上海 200093）

0 引言

家居環(huán)境空氣質(zhì)量在人們生活中正扮演著越來越重要的角色。多個居室環(huán)境數(shù)據(jù)需要分別監(jiān)測，而傳統(tǒng)的室內(nèi)空氣質(zhì)量監(jiān)測裝置一般是單點(diǎn)式的，只能采集一個地點(diǎn)的空氣質(zhì)量數(shù)據(jù)，不能滿足多點(diǎn)需求。梁濤等應(yīng)用RT-Thread 實(shí)時操作系統(tǒng)設(shè)計了一款家居環(huán)境監(jiān)測系統(tǒng)。該系統(tǒng)整體技術(shù)水平較為先進(jìn)，但只能采集單點(diǎn)溫濕度數(shù)據(jù)，對粉塵、室內(nèi)有毒氣體等全面的空氣質(zhì)量分析不足；任強(qiáng)等利用Cortex-M3 處理器和ENC28J60 模塊及uIP 協(xié)議設(shè)計了一款智能家居平臺控制系統(tǒng)，該系統(tǒng)實(shí)現(xiàn)多個控制節(jié)點(diǎn)的星型網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，能夠?qū)崿F(xiàn)家居設(shè)備的多點(diǎn)分布式控制，但沒有移植操作系統(tǒng)，基于裸機(jī)的軟件設(shè)計架構(gòu)與硬件耦合緊密，當(dāng)面臨日漸增長的智能家居功能需求時，任務(wù)之間的安排變得非常復(fù)雜，不利于日后升級迭代開發(fā)，潛力有限。針對上述問題，本文設(shè)計了一款能夠采集多個居室空氣質(zhì)量數(shù)據(jù)的分布式室內(nèi)空氣質(zhì)量檢測系統(tǒng)，移植了RT-Thread 實(shí)時操作系統(tǒng)和消息隊(duì)列遙測傳輸協(xié)議（Message Queuing Telemetry Transport，MQTT）。

MQTT 協(xié)議由IBM 和Eurotech 公司于1999 年開發(fā)，是一套輕量級基于發(fā)布∕訂閱的消息傳輸協(xié)議。與傳統(tǒng)的TCP∕IP 傳輸協(xié)議相比，MQTT 傳輸協(xié)議代碼及網(wǎng)絡(luò)帶寬占用小，資源消耗低，適合作為“機(jī)器到機(jī)器”（M2M）物聯(lián)網(wǎng)場景下應(yīng)用。本文在多個檢測點(diǎn)同時利用DS18B20數(shù)字溫度傳感器、MQ-7 氣體傳感器和GP2Y1014AU 粉塵傳感器采集室內(nèi)空氣中的各項(xiàng)環(huán)境數(shù)據(jù)，使用STM32F103 RCT6 作為主控芯片對采集到的數(shù)據(jù)進(jìn)行分析處理，并通過NRF24L01 無線傳輸模塊組成的2.4GHz 家庭局域網(wǎng)絡(luò)將數(shù)據(jù)上傳給網(wǎng)關(guān)節(jié)點(diǎn)。網(wǎng)關(guān)節(jié)點(diǎn)使用ESP8266 WiFi 模塊通過MQTT 傳輸協(xié)議與OneNET 云平臺通信，用戶能在云端對該系統(tǒng)進(jìn)行查看和控制。當(dāng)系統(tǒng)監(jiān)測的某項(xiàng)環(huán)境數(shù)據(jù)超過設(shè)定的警戒閾值時，云平臺會向用戶發(fā)送報警郵件進(jìn)行提示，用戶可在云平臺對該系統(tǒng)中的4 路繼電器進(jìn)行遠(yuǎn)程控制，對重要的水、電、煤氣等閥門進(jìn)行開閉操作，及時消除安全隱患。

1 系統(tǒng)架構(gòu)設(shè)計

如圖1 所示，分布式室內(nèi)空氣質(zhì)量監(jiān)測系統(tǒng)由監(jiān)測節(jié)點(diǎn)及網(wǎng)關(guān)節(jié)點(diǎn)兩部分組成，監(jiān)測節(jié)點(diǎn)與網(wǎng)關(guān)節(jié)點(diǎn)間通過nRF24L01 構(gòu)成2.4GHz 家居內(nèi)部無線局域網(wǎng)通信。網(wǎng)關(guān)節(jié)點(diǎn)以STM32F103RCT6 作為主控MCU，通過ESP8266 WiFi模塊，以MQTT 傳輸協(xié)議將數(shù)據(jù)上傳到OneNET 物聯(lián)網(wǎng)云平臺。

Fig.1 Distributed indoor air quality monitoring system architecture圖1 分布式室內(nèi)空氣質(zhì)量監(jiān)測系統(tǒng)架構(gòu)

2 監(jiān)測節(jié)點(diǎn)硬件設(shè)計

監(jiān)測節(jié)點(diǎn)硬件連接如圖2 所示。NRF24L01 是一款由NORDIC 公司推出的單片無線收發(fā)器芯片，工作在2.4～2.5GHz 的全球開放ISM 頻段，可通過調(diào)頻功能實(shí)現(xiàn)多對一通信。DS18B20 數(shù)字溫度傳感器采用“單總線”數(shù)字方式連接到MCU 的PB3 引腳，需接4.7kΩ 的上拉電阻。

CO 傳感器MQ-7 的模擬電壓輸出引腳與MCU 的PC0引腳連接，通過ADC1 完成模數(shù)轉(zhuǎn)換。環(huán)境CO 濃度的變化會引起傳感器金屬氧化物SnO氣體敏感層的電導(dǎo)率變化，進(jìn)而引起電壓變化。要得到使用ppm（百萬分比濃度）表征的CO 濃度，還需要一系列的換算過程。根據(jù)MQ-7 傳感器的廠家技術(shù)手冊，得到R∕R與ppm 之間的函數(shù)關(guān)系如下：

Fig.2 Monitoring node hardware connection圖2 監(jiān)測節(jié)點(diǎn)硬件連接

其中，R表示傳感器在1000ppm 的氫氣中的電阻值，為8.00Ω。R表示傳感器在不同濃度、不同氣體下的電阻值，計算如下：

式（2）中

V

的計算如下：

其 中，

V

是STM32F103RCT6 通 過ADC1 將

V

從 模擬量轉(zhuǎn)換完成的數(shù)字量。為保證精確，需要連續(xù)測量10 次ADC1 采樣值并取其平均值作為采用值。

GP2Y1014AU 粉塵傳感器輸出的模擬電壓與微顆粒物濃度成正比，MCU 通過ADC2（PC2 引腳）將該模擬信號轉(zhuǎn)換為數(shù)字信號，其檢測原理如圖3 所示。傳感器開有兩端貫通的氣室，放置有紅外發(fā)光二極管和光電晶體管，當(dāng)通道中流通空氣夾雜的微顆粒物阻擋紅外線時，光電晶體管收到的紅外線強(qiáng)度發(fā)生變化，使信號輸出引腳的模擬電壓發(fā)生變化。

Fig.3 GP2Y1014AU internal structure圖3 GP2Y1014AU 內(nèi)部結(jié)構(gòu)

3 網(wǎng)關(guān)節(jié)點(diǎn)硬件設(shè)計

如圖4所示，ESP8266與網(wǎng)關(guān)節(jié)點(diǎn)相連，它是工作在802.11n（2.4GHz）頻段的Wi-Fi芯片，通信速度高達(dá)72.2Mbps，具有+19.5dBm 的天線輸出功率，能確保良好的覆蓋范圍；睡眠電流小于20μA，適合低功耗的家居物聯(lián)網(wǎng)應(yīng)用場景。STM32F103RCT6 通過UART 串口發(fā)送AT 指令實(shí)現(xiàn)對ESP8266 的控制與通信。本系統(tǒng)設(shè)計包含4 路繼電器，當(dāng)用戶在云平臺查看室內(nèi)的各項(xiàng)環(huán)境監(jiān)測數(shù)據(jù)發(fā)現(xiàn)異常時，如溫度過高或者CO 濃度超標(biāo)，用戶可以通過這4路繼電器在云平臺遠(yuǎn)程控制家居內(nèi)水、電、煤氣等重要閥門的開閉，有效提升家居安全性。

Fig.4 Gateway node hardware connection圖4 網(wǎng)關(guān)節(jié)點(diǎn)硬件連接

4 系統(tǒng)軟件設(shè)計

4.1 RT-Thread 實(shí)時操作系統(tǒng)相關(guān)程序設(shè)計

RT-Thread 是一款國產(chǎn)RTOS 系統(tǒng)。本文監(jiān)測節(jié)點(diǎn)使用的MCU 是STM32F103RCT6，資源較有限，因此移植的是內(nèi)核NANO 版本，僅需要3KB Flash、1.2KB RAM 內(nèi)存資源。在監(jiān)測節(jié)點(diǎn)采集各項(xiàng)環(huán)境數(shù)據(jù)的同時，將這些數(shù)據(jù)由NRF24L01 上傳給網(wǎng)關(guān)節(jié)點(diǎn)，由此產(chǎn)生操作系統(tǒng)中多線程同步的生產(chǎn)者消費(fèi)者問題（Producer-consumer problem）：傳感器作為生產(chǎn)者產(chǎn)生數(shù)據(jù)并放置在緩沖區(qū)中，NRF24L01作為消費(fèi)者從緩沖區(qū)中消耗數(shù)據(jù)。消費(fèi)者、生產(chǎn)者分別在兩個不同的線程中，因此還涉及線程間通信（IPC，Inter-Process Communication）。RT-Thread 郵箱是一種開銷低、效率高的IPC 方式，每封郵件容量是4byte，恰好容納一個指針，資源消耗小。

監(jiān)測節(jié)點(diǎn)的程序設(shè)計包括數(shù)據(jù)采集線程readData_thread、數(shù)據(jù)發(fā)送線程sendData_thread、LED閃爍線程led_thread以及郵箱控制塊test_mail。其中，readData_thread 的優(yōu)先級高于sendData_thread 的優(yōu)先級，通過郵箱發(fā)送郵件方式完成線程間同步及通信；led_thread 優(yōu)先級最低，通過閃爍LED 燈指示程序正常運(yùn)行。

線程轉(zhuǎn)換過程如圖5 所示。在readData_thread 線程中，DS18B20、GP2Y1014AU 及MQ-7 傳感器每次分別采集3 項(xiàng)環(huán)境數(shù)據(jù)的1個，每個數(shù)據(jù)通過空格符分隔并緩存在tmp_buf 緩沖數(shù)組中，作為待發(fā)送數(shù)據(jù)包；readData_thread發(fā)送一封郵件給sendData_thread，然后通過rt_thread_mdelay（）函數(shù)主動延時將自身掛起；郵件內(nèi)容是指向數(shù)組的指針，即&tmp_buf。readData_thread 以永久等待方式等待，待收到該封郵件后啟動本線程，并通過指針獲取數(shù)組內(nèi)存儲的數(shù)據(jù)包，由NRF24L01 上傳給網(wǎng)關(guān)節(jié)點(diǎn)。sendData_thread執(zhí)行完畢后完成一輪生產(chǎn)者——消費(fèi)者過程，因其優(yōu)先級低于readData_thread，線程調(diào)度器會將線程切換到后者，繼續(xù)開始下一輪過程。led_thread 在readData_thread 的主動延時掛起間隙由線程調(diào)度器切換執(zhí)行。

Fig.5 Thread conversion process圖5 線程轉(zhuǎn)換過程

4.2 MQTT 協(xié)議程序設(shè)計

網(wǎng)關(guān)節(jié)點(diǎn)使用MQTT 協(xié)議接入中國移動的OneNET 物聯(lián)網(wǎng)云平臺。它是一種傳輸層協(xié)議，需要建立在其他可靠的物理層網(wǎng)絡(luò)連接協(xié)議（如TCP∕IP 協(xié)議）之上才能工作。每個MQTT 報文由固定報頭、可變報頭和負(fù)載3 部分組成。本文以網(wǎng)關(guān)節(jié)點(diǎn)的WiFi 模塊ESP8266 為客戶端，OneNET 作為服務(wù)器，使用MQTT 協(xié)議建立QoS 級別連接，流程如圖6 所示，對應(yīng)偽代碼如下：

固定報頭為0x10，是客戶端向服務(wù)器發(fā)送CONNECT報文，發(fā)出連接請求；若固定報頭為0x20，是客戶端收到服務(wù)器返回的CONNACK 報文，表示連接成功；若固定報頭為0x82，是客戶端向服務(wù)器發(fā)送SUBSCRIBE 報文，用于訂閱Topic；若固定報頭為0x90，是客戶端收到服務(wù)器返回的SUBACK 報文，確認(rèn)服務(wù)器已收到SUBSCRIBE 報文；若固定報頭為0x30，是客戶端向服務(wù)器發(fā)送的PUBLISH 報文，用于發(fā)送數(shù)據(jù)流通信；若固定報頭為0xC0，是客戶端向服務(wù)器發(fā)送的PING 報文，用于?；钸B接；若固定報頭為0xD0，是客戶端收到服務(wù)器返回的PINGRESP 報文，確認(rèn)已收到PING 報文。

Fig.6 MQTT protocol connection cloud platform flow圖6 MQTT 協(xié)議連接云平臺流程

其中，OneNET 要求數(shù)據(jù)流遵循JSON 格式。假設(shè)上傳溫度為22.2℃，粉塵濃度為44μg∕m，CO 濃度為ppm，則數(shù)據(jù)格式如下：｛“Temp”：22.2，“PM”：44，“CO”：10｝；服務(wù)器也可以向客戶端發(fā)送報文控制4 路繼電器開閉。

如圖7 所示，客戶端與服務(wù)器間有大量數(shù)據(jù)需要交換通信。為防止兩者間因數(shù)據(jù)處理速度不同造成數(shù)據(jù)丟失，在網(wǎng)關(guān)節(jié)點(diǎn)程序中設(shè)計了兩個數(shù)據(jù)緩沖區(qū)：發(fā)送數(shù)據(jù)緩沖區(qū)MQTT_TxDataBuf［NUM］［BUFF_UNIT］和接收數(shù)據(jù)緩沖區(qū)MQTT_RxDataBuf［R_NUM］［RBUF F_UNIT］。每個緩沖區(qū)是一個二維數(shù)組，數(shù)組元素單位為byte，可存儲一個報文。

根據(jù)緩沖區(qū)每個格子的第2個byte 判斷載入緩沖區(qū)的MQTT 報文的固定報頭。處理發(fā)送緩沖區(qū)MQTT_Tx-DataBuf 時，載入緩沖區(qū)的是客戶端待發(fā)送報文，彈出緩沖區(qū)的是客戶端已發(fā)送報文。若固定報頭是0x10，待發(fā)送的是CONNECT 連接報文；若固定報頭是0x82 且Connect-Pack_flag 已置位，待發(fā)送的是SUBSCRIBE 訂閱報文。對應(yīng)偽代碼如下：

處理接收緩沖區(qū)MQTT_RxDataBuf 時，載入緩沖區(qū)的是客戶端已接收報文，彈出緩沖區(qū)的是客戶端已處理的報文；若固定報頭是0x20，接收的是CONNACK 連接報文。將ConnectPack_flag 置位，表示連接報文成功；若固定報頭是0x90，接受的是SUBACK 報文；若固定報頭是0xD0，表示接收的是PINGRESP 報文；若固定報頭是0x30，接收的是PUBLISH 報文。

Fig.7 Buffer area of sending and receiving data圖7 發(fā)送與接收數(shù)據(jù)緩沖區(qū)

5 實(shí)驗(yàn)結(jié)果與分析

完成硬件設(shè)計與搭建、程序編寫之后，在OneNET 上的“多協(xié)議接入”入口注冊產(chǎn)品及設(shè)備，將生成的產(chǎn)品及設(shè)備ID 寫入程序。待系統(tǒng)正常工作并連接上OneNET 后便可在云平臺的PC 端或手機(jī)端查看部署在家居中的各個監(jiān)測節(jié)點(diǎn)實(shí)時上傳的各項(xiàng)環(huán)境數(shù)據(jù)，也可在云平臺遠(yuǎn)程控制4 路繼電器開合。

OneNET 還提供觸發(fā)器功能。當(dāng)系統(tǒng)采集到的某一項(xiàng)環(huán)境數(shù)據(jù)超過用戶設(shè)定的閾值時，云平臺會自動向用戶發(fā)送報警郵件，提示環(huán)境的變化可能會導(dǎo)致危險情況發(fā)生，有助于提升居室安全性。以微顆粒物濃度為例設(shè)置觸發(fā)器，當(dāng)環(huán)境中的濃度超過設(shè)定閾值200μg∕m時，OneNET自動向用戶發(fā)送報警郵件。上傳成功的所有數(shù)據(jù)流數(shù)據(jù)均實(shí)時保存在OneNET 后臺，保存的歷史數(shù)據(jù)可以按日期篩選，導(dǎo)出為.xlsx 文件，以供后期數(shù)據(jù)分析使用。

6 結(jié)語

本文以STM32F103RCT6 作為主控MCU，在監(jiān)測節(jié)點(diǎn)移植了RT-Thread Nano 實(shí)時操作系統(tǒng)。使用傳感器采集家居內(nèi)溫度、微顆粒物濃度、CO 濃度等室內(nèi)空氣質(zhì)量數(shù)據(jù)。使用2.4GHz 無線傳輸模塊構(gòu)建家庭局域網(wǎng)絡(luò)，多個監(jiān)測節(jié)點(diǎn)的數(shù)據(jù)在網(wǎng)關(guān)節(jié)點(diǎn)處匯總。匯總后的數(shù)據(jù)通過MQTT 傳輸協(xié)議上傳到OneNET 云平臺，讓用戶能在云端對該系統(tǒng)進(jìn)行查看和控制，非常便利。通過云平臺提供的報警郵件發(fā)送服務(wù)，提升了家居環(huán)境安全性。與傳統(tǒng)的單點(diǎn)式室內(nèi)空氣質(zhì)量監(jiān)測系統(tǒng)相比，該系統(tǒng)能準(zhǔn)確監(jiān)測家居內(nèi)多個居室的各項(xiàng)環(huán)境數(shù)據(jù)。應(yīng)用MQTT 傳輸協(xié)議，相比TCP∕IP 協(xié)議降低了資源消耗，更適合M2M 物聯(lián)網(wǎng)場景下應(yīng)用。

但本系統(tǒng)在RT-Thread 使用功能的挖掘深度方面還存在不足。后續(xù)計劃不僅僅將其作為一個實(shí)時內(nèi)核使用，還將移植如文件系統(tǒng)、圖形庫等較為完整的中間件組件，將該系統(tǒng)升級為一個具備低功耗、安全、通信協(xié)議支持和云端連接能力的平臺，以滿足未來不斷增長的智能家居功能需求。