周世航,林木泉,張 勇
(閩南理工學院電子與電氣工程學院,福建 泉州362700)
日常工作中,在一些沒有使用OA 辦公系統的單位,要拜訪領導簽署相關文件,又不方便提前打電話的情況下,經常出現領導處于忙碌狀態而不方便接待的情況。甚至多次拜訪均如此,無形中耗費了不少的時間和精力。由于雙方的信息不互通,導致了過程變得繁瑣。急需開發顯示領導在崗狀態的系統。雖然大部分公司、單位正在使用的OA 軟件系統可實現類似功能,但需要繳納各種運行費用和投入維護成本,對一些中小企業仍是一筆較大的經費支出。而市場化上專門針對領導在崗狀態指示系統較少,目前只有重慶錦聲科技有限公司公布了一種的在崗狀態指示系統,但需要超聲波傳感器和壓力傳感器的配合,結構相對較復雜,除此之外,還出現了基于人工智能的攝像頭方案的在崗狀態監測系統,但造價較高。為此,本文針對訪客與領導之間信息不互通的問題,面向于中小型企業或者單位需求,提出了一種領導在崗狀態指示系統,該系統電路結構簡單,不需要復雜的軟件運行,只需要一個小型硬件設備,易維護,使用門檻低。當需要拜訪領導時,使用手機或者電腦打開網頁,即刻查看領導是否處于方便接待的情況。
如圖1 所示,該系統由子端系統和終端系統組成,子端設備根據實際情況可擴展多個。所有子端通過Lora 無線方式與終端通信,形成多對一的通信方式。子端系統主要功能為采集開關狀態數據信息并發送給終端系統,且在子端設備電池供電不足時進行燈光提示。終端系統的主要功能為接收子端系統的數據,并將數據通過ESP8266 模塊以HTTP 協議方式上傳至 OneNet 云平臺[1]。
將子端設備擺放于領導辦公桌面,若領導方便接待訪客,則撥動子端設備開關,則所有用戶訪問OneNet 網頁查看的信息即顯示領導目前處于方便待客狀態,此時即可前往。終端設備放置于辦公區中心位置。

圖1 方案結構圖
如圖2 所示,在子端系統中,以STC15W4K32S4作為主控芯片,鋰電池經過TLV1117 低壓差低功耗穩壓芯片給子端系統供電,使用TP4056 芯片對鋰電池進行充電管理。主控芯片P3.4 引腳在不需要采集AD 數據時斷開兩個串聯分壓的電阻以節省能耗。P1.5 引腳為AD 輸入口,用于采集電池電壓數據。撥動開關接入主控芯片的P3.5、P3.2 引腳,主控芯片通過檢測P3.5 引腳的電壓來判斷開關的導通或斷開兩種狀態,以此來對應領導此時處于忙碌還是空閑狀態,開關狀態的改變會產生中斷信號通過P3.2 引腳傳輸給主控芯片,從而喚醒主控芯片,LED 燈通過單片機 P1.0 引腳控制。Lora 模塊 RXD、TXD 引腳接入單片機 P0.1、P0.0 引腳進行 UART 通信,MD0、AUX引腳接單片機P3.3、P3.7 引腳控制模塊運行模式。

圖2 子端系統線圖
如圖3 所示,在終端系統中,Lora 模塊接線方式與子端系統相同。ESP8266 模塊的 RXD、TXD 引腳接入單片機P0.3、P0.2 引腳進行UART 通信,其他控制引腳懸空。

圖3 終端系統線圖
系統的軟件設計分兩部分,一部分功能為實現開關狀態和電量的檢測,另一部分為數據的無線傳輸。
開關狀態的檢測實現過程為:按鍵觸發外部中斷喚醒處于休眠狀態的單片機,然后通過引腳IO 電壓判斷開關狀態。電量的檢測實現過程為:主控芯片開啟定時器,每5 min 進行一次A/D 采集,判斷電池電量是否過低,若過低則開啟LED 燈閃爍提示。
所有子端設備的數據都發往終端設備,使用Lo ra 無線組網方式實現。所有子端設備主動上傳數據,終端設備接收到子端設備數據后回饋一個應答信號,子端設備接收到應答信號進入休眠狀態[2,3]。為避免通信沖突,當子端設備發送數據后,5 s 內接收不到應答信號則隨機延時一個時間段(設置為100 ms~1 000 ms 之間) 后重新發送一次數據,若等待5 s后仍接收不到數據,則判定子端設備掉線。
子端設備和終端設備使用自定義通信協議。協議幀如表1 所示。

表1 通信協議幀
表1 中,第一字節0XFF 為數據幀幀頭,第二字節數據0X01 表示設備地址,地址表示的范圍從0X00 到0XFF,網絡可容納256 個設備。第三字節數據0 為0X11 表示按鍵關閉,0X22 表示按鍵開啟,數據1 和數據2 為預留字節,方便后期功能擴展,目前數據皆為0X00,最后一字節為除幀頭外數據的和。例如,子端設備地址為0X02,開關處于開的狀態,子端設備上傳數據發送的協議幀為0XFF 0X02 0X22 0X00 0X00 0X24。終端主機接收到數據后回復應答數據幀與子端發送的數據一致。
整個系統中的子端系統與終端系統的主控板如圖4 所示。

圖4 主控板圖
通過終端系統的主控芯片的串口發送AT 指令對ESP8266 模塊進行配置后才可接入云平臺[4]。以下使用A 代指終端主控芯片,B 代指ESP8266 模塊。A發送指令AT+CWMODE=3,配置模塊工作模式為STA+AP 模式,隨后重啟模塊,A 發送給B 指令AT+CWJAP="a","b"(a 為無線用戶名 ssid,b 為 wifi 密碼),B 則自動連接名稱為“a”的 WIFI 網絡。連接完成后,A 發送指令 AT+CIPMUX=0,把 B 配置為單鏈接模式,只有在此模式下,才能進行透傳模式,隨后A 發送AT+CIPMODE=1,設置透傳模式,在此模式下B 可以連接云端服務器[5]。A 發送指令 AT+CIPSTART="TCP","183.230.40.33",80 來連接 ONENET 云端服務器,連接成功后A 送AT+CIPSEND 開啟透傳模塊,此時已經可以給云平臺發數據了。此時編輯HTTP 協議的數據,通過HTTP 協議接入ONENET 云平臺的設備[6]。
以下為A 發送的發送http post 請求:

其中“59145xxxx” 為ONENET 云平臺設備ID,api-key 后面的內容為設備所對應的API-KEY,Content-Length:15 中的15 為發送內容整個數據流的長度,{"no.1":"free"} 為發送的內容no.1 為數據流名稱,free 為發送至云端的數據內容,當發送成功時候,B 會返回發送成功的消息,此時登陸網站即可看到發送的數據。在網站上可以用接收到的數據編輯用戶查詢界面,將數據流分別自動對應領導的名字與信息,如“no.1”數據流對應“張三”,狀態數據“free”/“busy”可以簡化為界面的開關on/off,更加直觀顯示狀態。當撥動開關,云平臺接收到數據,界面顯示如圖5 所示。

圖5 ONENET 平臺數據查詢
本文設計了一套低成本、易量產、適合各類人群使用的一套訪客查詢系統,該系統為主動觸發方式,不涉及用戶隱私。該系統實現了人——云端——人的聯網模式。在實物上,系統體積小,基本不占用工作空間,只需要在桌子上面放置一個裝有開關的小盒子即可,簡約美觀,具備一定的實用價值。