畢業(yè)論文——基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)的設(shè)計與研究

畢業(yè)設(shè)計說明書 基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)的設(shè)計與研究院 、 部： 計算機與信息科學學院 學生姓名： 指導教師： 職稱 專 業(yè)： 計算機科學與技術(shù) 班 級： 完成時間： 摘 要采用物聯(lián)網(wǎng)技術(shù)對農(nóng)業(yè)生產(chǎn)環(huán)節(jié)中農(nóng)作物的生長環(huán)境監(jiān)控，實現(xiàn)一個輕量級別的輔助管理系統(tǒng)?；趥鞲芯W(wǎng)絡(luò)采集的溫度、濕度、光照等相關(guān)數(shù)據(jù)達到對當前實時環(huán)境的遠程監(jiān)控并做出實際的機械操作。整個系統(tǒng)是通過傳感器將基本的監(jiān)控數(shù)據(jù)利用ZigBee技術(shù)傳送到局域網(wǎng)路由器，基于C/S模式，服務(wù)器對傳感網(wǎng)絡(luò)收集的數(shù)據(jù)進行容錯篩選，再存儲。管理者通過移動終端向服務(wù)器發(fā)出請求命令，服務(wù)器收到請求解析并做出相應的反應，從而達到對系統(tǒng)環(huán)境狀況的實時監(jiān)察調(diào)度。論文是以當前的物聯(lián)網(wǎng)技術(shù)作為發(fā)力點，結(jié)合農(nóng)業(yè)溫室作物培植技術(shù)，論述并實現(xiàn)了物聯(lián)網(wǎng)農(nóng)田環(huán)境監(jiān)控系統(tǒng)，為種植戶實現(xiàn)一個實時農(nóng)田作物生長數(shù)據(jù)監(jiān)控并提供相關(guān)技術(shù)與數(shù)據(jù)上的支持，真正實現(xiàn)了農(nóng)業(yè)管理的智能化，符合現(xiàn)代農(nóng)業(yè)的發(fā)展。關(guān)鍵詞 物聯(lián)網(wǎng)；傳感網(wǎng)絡(luò)；現(xiàn)代農(nóng)業(yè)；生產(chǎn)決策ABSTRACTUsing Internet technology to agricultural production in crop growth environment monitor to Implement a lightweight auxiliary management system. Based on data of temperature, humidity, light and other sensor networks to achieve the current collection of real-time remote monitoring of the environment and make the actual mechanical operation.The whole system is monitored by basic sensor data utilizing ZigBee technology transfer to the LAN router, based on C / S mode, the sensor network server data collected fault tolerance screening, and then store. Managers issued through the mobile terminal requests to the server command, the server receives the request parsing and react accordingly, so as to achieve real-time monitoring system scheduling environment. This article from the current of things, combined with agronomic techniques, made things overall framework of police dispatch system structure of agriculture.The user real-time monitoring of farmland and production data to support decision-making, truly intelligent management of agriculture, in line with the development of modern agriculture.Key words epc network; sensor network; modern agriculture; production decision目 錄第一章引 言41.1課題背景和意義41.2國內(nèi)外研究現(xiàn)狀41.3篇章組織5第二章基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)的設(shè)計框架71.1智能家居系統(tǒng)中的環(huán)境監(jiān)控解決思路71.2基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)9第三章硬件環(huán)境的搭建112.1硬件環(huán)境組成框圖112.2服務(wù)器端環(huán)境搭建122.2.1開發(fā)與調(diào)試工具包安裝122.2.2開發(fā)板開發(fā)與調(diào)試環(huán)境配置132.3 數(shù)據(jù)采集端環(huán)境配置172.3.1硬件資源概覽172.3.2 模塊芯片的選擇182.3.3開發(fā)與調(diào)試工具包安裝19第四章軟件設(shè)計213.1 服務(wù)器端的軟件設(shè)計223.1.1 Linux內(nèi)核移植223.1.2 SQLite數(shù)據(jù)庫223.1.3 Json文件的格式實現(xiàn)233.1.4 服務(wù)器端的通信協(xié)議的設(shè)置233.2 數(shù)據(jù)采集端軟件設(shè)計263.2.1總體設(shè)計概述263.2.2 數(shù)據(jù)采集端M0與服務(wù)器端A9通信協(xié)議設(shè)置273.3 Android客戶端軟件設(shè)計29第五章系統(tǒng)實驗與調(diào)試304.1 服務(wù)器A9模塊的數(shù)據(jù)接/發(fā)調(diào)試的相關(guān)過程展示304.2 數(shù)據(jù)采集M0模塊的調(diào)試374.3客戶端測試展示39第六章總結(jié)反思41參考文獻42致 謝43第一章 引 言1.1 課題背景和意義物聯(lián)網(wǎng)是當今新一代信息技術(shù)的核心，作為后互聯(lián)網(wǎng)時代具有產(chǎn)業(yè)性潛力的技術(shù)，它的定義也是隨著技術(shù)的不斷深入發(fā)展而被一次次定義。物聯(lián)網(wǎng)是個泛概念，它是多學科、多領(lǐng)域的集合體，它集中體現(xiàn)了后互聯(lián)網(wǎng)時代的技術(shù)方向，同樣是人類更高層次發(fā)展的切入口。從單純的知識概念上講，這是一個入門很高的學科領(lǐng)域，它所體現(xiàn)的就是當今互聯(lián)網(wǎng)理念思想發(fā)展的更高層次的分化與融合。從市場與技術(shù)的縱向上看，物聯(lián)網(wǎng)實現(xiàn)的是更高生活品質(zhì)的宜人化的服務(wù)層次，它所蘊含的產(chǎn)業(yè)價值也定不會遜色于電商時代。物聯(lián)網(wǎng)概念的提出其實是很早的，但是受制于現(xiàn)實技術(shù)等因素，它的發(fā)展也總是很緩慢，物聯(lián)網(wǎng)展現(xiàn)的是多領(lǐng)域的融合。從這個角度講，它的的發(fā)展同樣是一個面的概念，反而是單個因素成為磕絆發(fā)展的短板！物聯(lián)網(wǎng)不是中國首次提出的，卻是在當前背景下發(fā)展最為全面的，而從實際的角度上講，先驅(qū)意味著前行，意味著時間與金錢上無限的投入。但是，從長遠角度上講，這些投入都是必須的也是值得的！2009年美國白宮，肯定了在基于物聯(lián)網(wǎng)基礎(chǔ)提出的“智慧地球”概念，并在全球經(jīng)濟下行壓力極大的情況下，大手筆的投入智慧地球。對于高科技美國人歷來是唯快不破，并牢牢把握科技的上游，這也體現(xiàn)了物聯(lián)網(wǎng)背后的政治與科技的角逐！1.2 國內(nèi)外研究現(xiàn)狀物聯(lián)網(wǎng)從本世紀出的首次提出到今天，它的應用已經(jīng)滲入了我們生活的方方面面。從飯不離手的智能手機到瘋狂驚叫的VR設(shè)備，再到強大的“大狗”機器人，無不體現(xiàn)嵌入式在現(xiàn)代生活元素中的身影。從國內(nèi)外更廣的視角來看，在農(nóng)業(yè)上物聯(lián)網(wǎng)技術(shù)的應用也在不斷的深入。就農(nóng)業(yè)生態(tài)環(huán)境監(jiān)測領(lǐng)域來講，法國、美國和日本等一些國家運用監(jiān)控衛(wèi)星網(wǎng)絡(luò)加地面監(jiān)控站來構(gòu)建全國性或者全區(qū)域性的先進農(nóng)業(yè)生態(tài)環(huán)境監(jiān)測網(wǎng)絡(luò)，憑借先進的傳感器感知技術(shù)、信息融合傳輸技術(shù)以及互聯(lián)網(wǎng)技術(shù)建立區(qū)域性的農(nóng)業(yè)信息化平臺，實現(xiàn)對農(nóng)業(yè)生態(tài)環(huán)境的自動監(jiān)測，從宏觀上保證農(nóng)業(yè)生態(tài)環(huán)境的可持續(xù)發(fā)展，并指導農(nóng)業(yè)現(xiàn)代化種植與發(fā)展。在農(nóng)業(yè)生產(chǎn)精細管理領(lǐng)域，美國、澳大利亞、法國等傳統(tǒng)的農(nóng)畜牧業(yè)比較強大的西方國家建立了完善的指導機制平臺，并形成了廣泛的實用性極強的控制系統(tǒng)。在物聯(lián)網(wǎng)農(nóng)業(yè)的發(fā)展我國其實也是奮起直追，在相關(guān)領(lǐng)域也有著不錯的成績，現(xiàn)階段我們在北京、上海、江蘇等地方建立起了很多農(nóng)業(yè)示范園，同時各地也在 積極推進物聯(lián)網(wǎng)農(nóng)業(yè)的優(yōu)質(zhì)項目，并且這些項目的到了較好的回應，在保證農(nóng)民增收的基礎(chǔ)上，對于糧食供給和食品安全領(lǐng)域的助推也是顯而易見的。在全國性的環(huán)境監(jiān)控方面的發(fā)展上我們同樣有我們自己的比較成功的實用案例。但是我們總體層次上相較之國外的發(fā)展，還是存在著很多的問題。物聯(lián)網(wǎng)農(nóng)業(yè)遍地開花的局面并沒有產(chǎn)生，傳統(tǒng)小田農(nóng)業(yè)結(jié)構(gòu)的弱化甚至是破碎較為嚴重！換言之，我們的傳統(tǒng)的耕作與管理模式都在弱化！國家從2003年就在不斷的加大農(nóng)業(yè)生產(chǎn)上的補助與扶持，從國家政策層面上來講，我國已經(jīng)在農(nóng)業(yè)發(fā)展上出臺了多個國家級文件。但是，從全局縱向上看，我國的傳統(tǒng)農(nóng)業(yè)的發(fā)展也僅僅是負重式的發(fā)展，整體的發(fā)展速度在區(qū)域上是存在巨大差異的，并且這種差異在進一步擴大！物聯(lián)網(wǎng)農(nóng)業(yè)的成熟應用主要集中在農(nóng)畜牧業(yè)發(fā)展比較強大的西方國家，這不是偶然卻存在著必然！農(nóng)業(yè)的發(fā)展是一個循序漸進的過程，它集中體現(xiàn)了一個國家在民生方面的積累與沉淀。對于中國這樣一個傳統(tǒng)的農(nóng)業(yè)大國來說，農(nóng)業(yè)發(fā)展是的不平衡性不是一個政策一攬子文件就能解決的，它背后體現(xiàn)的是市場與價值還有實際人文的選擇與轉(zhuǎn)變，這就意味著農(nóng)業(yè)的不平衡性將是長期的。一時的大手筆絕對不是解決的方法，一味的放置偏頗更是不可取，在技術(shù)與資金上的積極引導才是正道，國家層面的示范建設(shè)是標桿，企業(yè)及個人的投入是補充，主體與局部的結(jié)合才是物聯(lián)網(wǎng)農(nóng)業(yè)在中國當前的實際技術(shù)與地理環(huán)境上的真正選擇！1.3 篇章組織本文面向建立的是小型化的農(nóng)業(yè)生產(chǎn)環(huán)節(jié)的環(huán)境監(jiān)控的研究平臺。主要就是建立一個核心在局域網(wǎng)的小型農(nóng)田監(jiān)控系統(tǒng)，主要是對中、近距離數(shù)據(jù)傳輸與監(jiān)控。整個設(shè)計分為三個模塊：服務(wù)器模塊，數(shù)據(jù)采集模塊，應用層模塊。在服務(wù)器端將采用Cortex-A9芯片，數(shù)據(jù)采集模塊采用的是芯片Cortex-M0，應用層是移動終端通過訪問本地路由器建立與通信。在M0模塊將實現(xiàn)光照監(jiān)控子模塊，溫度監(jiān)控子模塊。還有簡單的模擬開關(guān)燈子模塊，模擬開關(guān)風扇子模塊。在服務(wù)器A9端實現(xiàn)數(shù)據(jù)的處理存儲，同時是通過有線與本地路由器進行連接，服務(wù)器A9與M0模塊是通過ZigBee模塊進行通信的。用戶可以通過手機、平板等移動終端通過WIFI與路由器進行通信，從而訪問服務(wù)器。針對現(xiàn)實學習需求與知識技能的儲備，本文僅僅是有選擇有裁剪的模擬實現(xiàn)了環(huán)境檢測的簡單框架。本文第二章簡要介紹了智能家居實現(xiàn)監(jiān)控的基本邏輯框架與思路。因為物聯(lián)網(wǎng)農(nóng)業(yè)監(jiān)控與智能家居在起點與數(shù)據(jù)處理階段同宗同源，同時詳細說明本設(shè)計的框架。第三章對整個系統(tǒng)的模塊細分并說明各自的功能與實現(xiàn)邏輯以及硬件部分詳細設(shè)計。第四章為整個系統(tǒng)軟件部分詳細設(shè)計。第五章是單元測試以及系統(tǒng)綜合驗收測試。第六章指出該系統(tǒng)的特色與反思以及對物聯(lián)網(wǎng)農(nóng)業(yè)的展望。第二章 基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)的設(shè)計框架 1.1智能家居系統(tǒng)中的環(huán)境監(jiān)控解決思路這里首先介紹下當前物聯(lián)網(wǎng)框架下的智能家居系統(tǒng)的模式與基本實現(xiàn)解決思路。物聯(lián)網(wǎng)農(nóng)業(yè)是基于物聯(lián)網(wǎng)發(fā)展而來的，是物聯(lián)網(wǎng)應用向農(nóng)業(yè)的觸及，但是從當前的大環(huán)境上來講，物聯(lián)網(wǎng)在農(nóng)畜牧業(yè)的發(fā)展也僅僅停留在大田示范園的階段，而物聯(lián)網(wǎng)在適宜人居環(huán)境的應用、推廣與投入是比較成功也是比較大的。這種現(xiàn)象其實很好找到原因。作為一個商業(yè)性的發(fā)展，利益驅(qū)動才是根本，很明顯投資物聯(lián)網(wǎng)農(nóng)業(yè)在成本上與市場回報上周期都是很長的，而研發(fā)成本以及硬件成本是很高的，而做出的產(chǎn)品在市場的普及上又是未知的，利益小風險大，所以說這個領(lǐng)域的成熟的參考是較少的。但是智能家居與物聯(lián)網(wǎng)農(nóng)業(yè)在模塊化的數(shù)據(jù)采集與數(shù)據(jù)的傳輸階段又是相通的，我們基于“用已知去探求未知，化抽象為具體”的解決思想，從當前智能家居的模式與問題解決方案來找到靈感，打趣的說我們是站在巨人的肩膀上看待物聯(lián)網(wǎng)農(nóng)業(yè)前景的！坦率的講，在智能家居領(lǐng)域的產(chǎn)品競爭早已不是單個產(chǎn)品再或者單個系列的小打小鬧，在競爭的背后是對這個行業(yè)甚至是對互聯(lián)網(wǎng)+時代的技術(shù)與市場的把控與行業(yè)標準的搶占。當前，無論是實力強大的互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)的電商大鱷，更甚是剛步行業(yè)的微小型公司，他們都在利用自己的優(yōu)勢打造自己關(guān)于物聯(lián)網(wǎng)智能家居的理解和對未來高品質(zhì)家居生活的闡釋。通俗的講，這些企業(yè)關(guān)注點和搶占的先機就是智能家居的控制入口。任何一個標準化的產(chǎn)品都是從竟態(tài)下的考驗最終在市場與利潤的現(xiàn)實驅(qū)動因素下走向標準，今天的物聯(lián)網(wǎng)產(chǎn)業(yè)正處于竟態(tài)下，都在把握市場與價值的切合點上起舞，不同的性質(zhì)的企業(yè)對這個舞蹈的欣賞又是各不相同的！智能硬件企業(yè)：手機+智能小部件模式。毫不夸張的說在嵌入式產(chǎn)品中的發(fā)展中，各大手機廠商絕對可以稱得上主要力量。從智能手機的門被打開的那一刻，疙瘩手機更是層出不窮，做情懷產(chǎn)品的時代幾乎是一夜間就消失殆盡了。同時在智能家居的領(lǐng)域這些廠商也是拼勁十足。主要代表的就是小米和華為的智能家居戰(zhàn)略。他們的思路就是在路由器上做文章，將自家的路由器作為智能家居戰(zhàn)略的入口和推廣平臺，并且配置相關(guān)系列的智能配件來自我組裝一個可供自己選擇且適合自己的口味的智能家居環(huán)境，同時將自己的平臺做有限的開放，將更多的開發(fā)接口提供出來，為個人的意愿發(fā)展提供現(xiàn)有微小平臺。對于手機制造廠家來說輕車熟路更易于成功，所要解決的問題主要是“點”的定位，而不完全受制于一個完整的平臺約束，擴展性很強，在網(wǎng)絡(luò)接入和產(chǎn)品控制上，變得更容易！互聯(lián)網(wǎng)企業(yè)：用解決方案來做云上的智能家居。談及對當前科技的把控，互聯(lián)網(wǎng)大公司絕對是最為敏感的，對于做服務(wù)的互聯(lián)網(wǎng)大佬們，利潤的驅(qū)動絕對是至上的，從這幾年BAT一系列的收購行為以及對P2P與O2O平臺的大手筆的投入便可看出。對于智能家居，他們也有著自己對未來宜人家居的品質(zhì)生活的定位與看待。百度通過搭建硬件平臺并推出了自家的云服務(wù)；騰訊則是以微信為自己的突破口；阿里則借助視頻盒子和云OS作為智能家居平臺的入口。當我們靜下心去細細想下這些互聯(lián)網(wǎng)公司的選擇的突破口，我們會發(fā)現(xiàn)他們最大的優(yōu)勢是其巨大的流量、用戶數(shù)據(jù)、附帶的系列軟件等，結(jié)合當前的云存儲與云計算，為智能家居的提供一個頂層設(shè)計也是一種完美的擬合。但是到目前為止也僅僅是百度做出了點成效。在早期的智能家居探索的產(chǎn)品是很多的，但是收益甚微，那一輪的家居熱情就此虎頭蛇尾的結(jié)束了。對于智能家居的家居元素的理解的深度還是不夠透徹，由此可見當前市場上充斥著以小米模式噴涌的智能小產(chǎn)品，但是主流價值產(chǎn)品卻是不足！不得不說主流產(chǎn)品布局的智能家居是一個整體框架的必然需要。傳統(tǒng)家電企業(yè)：產(chǎn)業(yè)聯(lián)盟式入口模式。不得不說最早嗅到物聯(lián)網(wǎng)下智能家居發(fā)展的是傳統(tǒng)的家電廠家。物聯(lián)網(wǎng)本身就是一個技術(shù)驅(qū)動的產(chǎn)業(yè)，很顯然憑借傳統(tǒng)電商的營銷老路子是走不通的，曾經(jīng)大批家電企業(yè)在轟轟烈烈的進軍PC產(chǎn)業(yè)的教訓是痛在他們心里的?，F(xiàn)實的狀況是，在專業(yè)性技術(shù)和推廣策略的限制下傳統(tǒng)家電企業(yè)在智能家居領(lǐng)域的單打獨干顯得很無力。當物聯(lián)網(wǎng)的浪潮真正全面襲來的時候，主流的家電公司紛紛選擇他們的方式家電聯(lián)盟，去融入并打造他們世界觀下的智能家居。比如海爾的U-home系統(tǒng)為平臺，憑借E家佳聯(lián)盟標準達到了多產(chǎn)品的兼容。傳統(tǒng)家電企業(yè)對家用電子設(shè)備是真正理解，憑借自己在傳統(tǒng)家電行業(yè)內(nèi)的威望，組建一個企業(yè)聯(lián)盟進而建立拉攏一批小型智能家居制造商，搭建統(tǒng)一的開放平臺，以此來把控智能家居的入口也不失為一個上上策。1.2基于物聯(lián)網(wǎng)的農(nóng)田環(huán)境監(jiān)控系統(tǒng)解決思路這里我主要關(guān)注的是小米家的解決模式。手機+智能單品的模式下，小米絕對是獨樹一幟的前行者，小米的產(chǎn)品的營銷模式雖廣受詬病，但是小米產(chǎn)品還算是成功的?；乜匆灾悄苁謾C為核心的等一批便攜式的智能硬件的發(fā)展軌跡，4年來，有的企業(yè)倒了，有的市場在不斷萎縮。小米在壯大中，正如小米的技術(shù)總監(jiān)孫鵬說的，智能家居的思路想法誰都有，能做出使用的產(chǎn)品在說！在小米的智能家居設(shè)計理念中，路由器是數(shù)據(jù)處理的核心，智能插座等小部件是入口。各種米系列的產(chǎn)品通過無線或者有線鏈接到路由器，米路由器從功能上來說，除了基本路由器常有的網(wǎng)關(guān)、Wi-Fi熱點功能之外，還支持小米設(shè)備快連、可擴展功能的插件模式、DLNA 方式共享文件、支持 LAMP功能。我的設(shè)計就是基于本地路由訪問方式實現(xiàn)數(shù)據(jù)收集與監(jiān)控的！整個設(shè)計是模式探索型的設(shè)計，基于這種定位整個系統(tǒng)的模塊是很簡單的，在功能上也進行了相關(guān)的裁剪和功能的模擬轉(zhuǎn)移。這種定位是對實際技術(shù)與成本進行相關(guān)考量后做出決定的。作為一個畢業(yè)設(shè)計受制于個人知識與眼界，我僅僅能做我能勝任的部分，同時當前可以學習參考的模型是有的，但都不是開源的資料，對于當前物聯(lián)網(wǎng)來說一切都是在起步上下功夫，一切都是商業(yè)！雖然小米曾承諾將相關(guān)協(xié)議開放，就是BAT也曾說將平臺開放，但是實際對于個體用戶的測試學習還是很困難的。本設(shè)計主要分為三個模塊，服務(wù)器模塊，數(shù)據(jù)采集模塊，移動控制端模塊。服務(wù)器端選擇的是三星以ARM的cortex-A9系列為核心開發(fā)的Exynos 4412。這款芯片采用了三星最新的32nm HKMG工藝，主頻最高為1.4GHGz，是三星的第一款四核處理器。因為采用了新的工藝實現(xiàn)相同性能的同時功耗控制更加出色。此外，三星Exynos 4412支持雙通道LPDDR2 1066內(nèi)存，這款芯片在同期同層次的芯片中算是最優(yōu)的，特別在很多媒體的測試中，搭載了這款芯片的移動設(shè)備的跑分都是很高的。數(shù)據(jù)采集模塊采用的以Cortex-M0為核心板的LPC11C14芯片。數(shù)據(jù)傳輸模塊用的是ZigBee技術(shù)。LPC11C14集成了溫濕度度傳感器，光照傳感器，可調(diào)速小風扇等小模塊，通過這些模塊 對周圍環(huán)境的溫濕度，光照強度數(shù)據(jù)進行收集，然后通過組合的ZigBee模塊將數(shù)據(jù)傳輸?shù)紼xynos 4412服務(wù)器端，服務(wù)器端對數(shù)據(jù)容錯，存儲。服務(wù)器一端通過ZigBee與LPC11C14模塊通信，另一端通過有線與本地路由器進行鏈接通信。當用戶通過設(shè)置固定IP訪問本地路由器的移動端向服務(wù)器發(fā)出服務(wù)請求，服務(wù)器端對相關(guān)請求進行解析，做出開關(guān)燈、風扇的邏輯操作。約定：以下Cortex-A9表示服務(wù)器，簡稱A9；以下Cortex-M0表示數(shù)據(jù)采集模塊,簡稱M0；以下APP表示智能家居 Android 客戶端應用程序。第三章 硬件環(huán)境的搭建2.1硬件環(huán)境組成框圖本設(shè)計主要分為三個大模塊，服務(wù)器模塊，數(shù)據(jù)采集模塊，移動控制端模塊，服務(wù)器模塊與數(shù)據(jù)采集都集成了數(shù)據(jù)傳輸模塊。服務(wù)器端選擇的是三星公司開發(fā)的Exynos 4412。數(shù)據(jù)采集模塊采用的LPC11C14芯片。數(shù)據(jù)傳輸模塊用的是ZigBee技術(shù)。LPC11C14集成了溫濕度度傳感器，光照傳感器，可調(diào)速小風扇等小模塊，這些模塊獲得的數(shù)據(jù)通過組合的ZigBee模塊傳輸?shù)紼xynos 4412服務(wù)器端，服務(wù)器端對數(shù)據(jù)容錯，存儲。服務(wù)器一端通過ZigBee與LPC11C14模塊通信，另一端通過有線與本地路由器進行鏈接通信。用戶通過設(shè)置固定IP訪問本地路由器，服務(wù)器端對相關(guān)請求進行解析，做出及時響應。整體系統(tǒng)組成框圖如圖2-1：圖2-1 整體系統(tǒng)組成框圖2.2服務(wù)器端環(huán)境搭建2.2.1開發(fā)與調(diào)試工具包安裝對于整個系統(tǒng)來講環(huán)境的配置是至關(guān)重要的，整個系統(tǒng)將會把大把的時間花在硬件的調(diào)試，以期獲得一個穩(wěn)定的性能，（1）安裝gcc編譯工具：yagarto-bu-2.21_gcc-4.6.2-c-c+_nl-1.19.0_gdb-7.3.1_eabi_20111119.exe。（2）安裝tools工具：yagarto-tools-20100703-setup.exe。（3）安裝FS-JTAG工具：（4）安裝JTAG驅(qū)動：把JTAG 接入計算機USB口，會提示發(fā)現(xiàn)新硬件，選擇從列表或指定位置安裝。（這個過程需要安裝3次）2.2.2開發(fā)板調(diào)試與開發(fā)環(huán)境配置服務(wù)器A9中跑的不是裸機是一個裁剪了小型化的Linux內(nèi)核，下邊就是往開發(fā)板上配置相關(guān)環(huán)境。我們板子上跑的是Linux系統(tǒng)所以我們開發(fā)調(diào)試階段也要在這樣一個環(huán)境中進行，所以開發(fā)的階段必須在Linux虛擬機上通過調(diào)試工具建立一個相關(guān)聯(lián)的環(huán)境。模擬一個同板子環(huán)境相似的環(huán)境。在產(chǎn)品開發(fā)并測試完成后在將板子與虛擬機環(huán)境徹底分離。Exynos 4412開發(fā)板如圖：圖2-2 Exynos 4412整個A9模塊開發(fā)的過程分為兩個三個階段：階段一進行相關(guān)環(huán)境的配置，主要是對開發(fā)環(huán)境與開發(fā)板環(huán)境的配置；階段二進行軟件層次的設(shè)計，諸如服務(wù)器端的數(shù)據(jù)庫的設(shè)計；階段三將進行A9單個模塊的調(diào)試以及整體組合后的調(diào)試，這個過程是最為關(guān)鍵的，關(guān)乎整個系統(tǒng)的穩(wěn)定性能，同是也是復雜程度最高的模塊。在階段一，我們將開發(fā)環(huán)境與開發(fā)板環(huán)境分別稱為Host端開發(fā)與Target端開發(fā)，在Host端開發(fā)我們要安裝一系列的開發(fā)調(diào)試工具包，并且配置Host與Target開發(fā)的服務(wù)器環(huán)境。在Target端我們主要是對目標機環(huán)境簡單設(shè)置，同是進行相關(guān)功能的實驗。當三個階段做好之后將做好的Boot Loader和Kernel還有Roofs燒寫到開發(fā)板上，至此一個裁剪的嵌入式小型數(shù)據(jù)處理服務(wù)器做好了！嵌入式Linux開發(fā)模式如圖2-3：圖2-3 嵌入式Linux開發(fā)模式框圖開發(fā)板調(diào)試模式如圖2-4：圖2-4 開發(fā)板調(diào)試模式框圖這里將X86機器作為開發(fā)服務(wù)器機器，開發(fā)板作為目標機或者調(diào)試機。tftp服務(wù)器的配置：TFTP（Trivial File Transfer Protocol,簡單文件傳輸協(xié)議）是TCP/IP協(xié)議族中的一個用來在客戶機與服務(wù)器之間進行簡單文件傳輸?shù)膮f(xié)議，提供開銷不大且不復雜的文件傳輸服務(wù)。端口號為69。TFTP是一個傳輸文件的簡單協(xié)議，它基于UDP協(xié)議而實現(xiàn)。在調(diào)試開發(fā)階段我們使用tftp服務(wù)器目的就是可以將我們在Host機中編譯開發(fā)好的內(nèi)核高速的下載到Target中。對于產(chǎn)品的快速開發(fā)調(diào)試是至關(guān)重要的。Tftp服務(wù)器的具體配置如圖2-5：圖2-5 tftp服務(wù)器配置流程圖nfs服務(wù)器的配置：nfs是Network File System的縮寫，即網(wǎng)絡(luò)文件系統(tǒng)。一種使用于分散式文件系統(tǒng)的協(xié)定，它的最大的功能就是通過網(wǎng)絡(luò)讓不同的機器、不同的操作系統(tǒng)能夠彼此分享個別的數(shù)據(jù)，它的基本原則是“容許不同的客戶端及服務(wù)端通過一組RPC分享相同的文件系統(tǒng)”，它是獨立于操作系統(tǒng)，容許不同硬件及操作系統(tǒng)的系統(tǒng)共同進行文件的分享。也正是nfs簡單實現(xiàn)但功能相對健壯的特點，給調(diào)試和文件系統(tǒng)的制作過程帶來極大的快捷、方便。具體搭建過程詳見圖2-6：圖2-6 nfs服務(wù)器配置流程圖整個過程必須保證完整且正確，在實際的配置的過程會出現(xiàn)很多調(diào)試配置上的問題，一定要克服解決！做好A9開發(fā)和調(diào)試后環(huán)境后就是具體的內(nèi)核移植的過程了。內(nèi)核移植主要工作就是U-Image的制作，這個制作過程在第三章講解，下邊大體介紹整個開發(fā)板的啟動流程如圖2-7：圖2-7 開發(fā)板的啟動流程圖2.3 數(shù)據(jù)采集端環(huán)境配置2.3.1硬件資源概覽數(shù)據(jù)采集模塊采用的是基于ARM Cortex-M0 內(nèi)核的LPC11C14 微控制器 ，集成多種傳感器、RFID、ZigBee、OLED 顯示模塊等的一款芯片。配套有開放的CoLink仿真器，使用者可以在不另外配置U-LINK2仿真器的情況下進入開發(fā)。本設(shè)計中我選擇了溫濕度傳感模塊、光照傳感模塊、ZigBee數(shù)據(jù)傳輸模塊。LPC11C14芯片整體框架如圖2-8：圖2-8 LPC11C14芯片整體框架本套架構(gòu)設(shè)計是用于Exynos 4412服務(wù)器端與LPC11C14之間的程序設(shè)計的整體框架和數(shù)據(jù)的處理過程。Exynos 4412通過發(fā)送操作請求數(shù)據(jù)包到LPC11C14來完成相應的用戶希望得到的操作與數(shù)據(jù)，同時LPC11C14給Exynos 4412回復相應的確認包，表示LPC11C14已經(jīng)完成了這項操作。這樣就可以完成一次交互。LPC11C14的實物展示如圖 2-9：圖2-9 LPC11C14芯片實物展示2.3.2 模塊芯片的選擇溫濕度傳感器DHT11的基本原理：DHT11是一款有校準數(shù)字信號輸出的溫濕度傳感器。精度濕度+-5%RH，溫度+-2，量程濕度20-90%RH，溫度050。它采用的是簡化的單總線通信，系統(tǒng)中的數(shù)據(jù)交換、控制均由單總線完成。DATA用于微處理器與DHT11之間的通訊和同步,采用單總線數(shù)據(jù)格式，一次傳送40位數(shù)據(jù)，高位先出。數(shù)據(jù)格式: 8bit 濕度整數(shù)數(shù)據(jù) + 8bit 濕 度小數(shù)數(shù)據(jù)+8bit 溫度整數(shù)數(shù)據(jù) + 8bit 溫度小數(shù)數(shù)據(jù)+8bit 校驗位。原理圖如圖 2-10：圖 2-10光照感應器ISL29003的基本原理：ISL29003內(nèi)部有兩個光電管。光電管1對可見光和紅外光都是敏感的，光電管2主要是對紅外光敏感的。這兩個的光譜反應是獨立的。兩個光電管將光信息轉(zhuǎn)換為電流，然后通過二極管的電流輸出會被一個16位的A/D轉(zhuǎn)換為數(shù)字信號。原理圖如圖 2-11：圖 2-112.3.3開發(fā)與調(diào)試工具包安裝在這個階段開發(fā)環(huán)境是Keil Real View MDK，這個軟件是ARM公司推出的。Real View MDK 集成了業(yè)內(nèi)最領(lǐng)先的技術(shù)，包括 Vision4 集成開發(fā)環(huán)境與Real View編譯器，它支持 ARM7、ARM9和最新的Cortex-M0、Cortex-M1、Cortex-M3 和 Cortex-M4核處理器，自動配置啟動代碼，集成Flash 燒寫模塊，強大的 Simulation 設(shè)備模擬，性能分析等功能在LPC11C14開發(fā)過程我們同樣需要調(diào)試工具，這里我們選用的是CoLink仿真器，該仿真器上有Colink固件。Colin實物展示如圖2-12：圖2-12 Colin實物展示Colin的安裝調(diào)試如圖2-13：圖2-13 Colin的安裝調(diào)試流程圖第四章 軟件設(shè)計整個系統(tǒng)的軟件設(shè)計部分主要有四個部分：服務(wù)器端，數(shù)據(jù)采集端，數(shù)據(jù)傳輸模塊，APP模塊，在服務(wù)器端主要的工作將集中在對Linux系統(tǒng)移植和數(shù)據(jù)傳輸階段，前者是一些固化的操作，僅僅是在驅(qū)動的實現(xiàn)階段有點難度，相較之后者要比較麻煩要不斷的進行測試才可以穩(wěn)定的數(shù)據(jù)傳輸通信。數(shù)據(jù)采集端主要實現(xiàn)的是數(shù)據(jù)通信與光照傳感器與溫濕度傳感器的驅(qū)動，這個過程都算可以，還是傳輸數(shù)據(jù)的階段最為反復。在移動APP設(shè)計，用的是Android進行開發(fā)的，主要解決的問題是數(shù)據(jù)的展示與請求命令的解析處理。在服務(wù)器端采用的是Json格式數(shù)據(jù)進行存儲的。整個系統(tǒng)的軟件框架如圖3-1：圖3-1 系統(tǒng)的軟件框架3.1 服務(wù)器端的軟件設(shè)計3.1.1 Linux內(nèi)核移植內(nèi)核移植是這個模塊的核心工作，也同樣是嵌入式產(chǎn)品的核心，我們是在一個固定的框架下做東西，是在開源代碼的基礎(chǔ)上裁剪出自己需要的模塊，在根據(jù)自己實際的需求，去實現(xiàn)相應的模塊的驅(qū)動，這個過程在這里不詳細說明，這個過程的框架流程如圖3-2：圖3-2 Linux內(nèi)核移植跨職能流程圖3.1.2 SQLite數(shù)據(jù)庫SQLite，是一款關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，它的設(shè)計目標是嵌入式的，目前在嵌入式領(lǐng)域絕對不二選擇。這個數(shù)據(jù)庫占用資源非常的低，很符合嵌入式內(nèi)存有限的基本現(xiàn)狀。這里使用SQLite3來對APP傳輸來的登錄數(shù)據(jù)進行存儲。這里的建表很簡單就是為了存儲用戶的登錄信息。LogName，PassWord, PhoneNumber，UserToken這些字段，其中UserToken是Key值。圖3-3 sqlite3用戶數(shù)據(jù)庫設(shè)計3.1.3 Json文件的格式實現(xiàn)這里數(shù)據(jù)通信中的數(shù)據(jù)格式都是采用的Json，這是一種輕量級的數(shù)據(jù)交換格式，它采的是用完全獨立于語言的文本格式，但同時又保留了類C的習慣。易于人編寫和閱讀，于此同時讀，解析和生成都比較快速。也正是這些特性使之成為使用比較方便的數(shù)據(jù)交換格式。3.1.4 服務(wù)器端的通信協(xié)議的設(shè)置服務(wù)器A9的通信主要是與客戶端通信、M0進行通信，雙方之間通信通過 TCP 協(xié)議通信，在應用層指定自己的數(shù)據(jù)包格式，并且?guī)в写_認機制，這個模塊講解說明的是Android的APP與服務(wù)器A9進行通信。這里根據(jù)實際的功能需求進行了通信協(xié)議的設(shè)置如表3-1，表3-2：表3-1 JSON格式的KEY值數(shù)據(jù)包格式JSON格式的KEY值如下：userName用戶名oldPassword 舊密碼newPassword 新密碼password 密碼phoneNumber手機號userToken 用戶身份識別碼randomCode 驗證碼（6 位大小寫字母和數(shù)字組成）stateCode狀態(tài)值（int）temperature溫度humidity 濕度light 光照deviceNumber 設(shè)備號deviceCode 設(shè)備操作碼deviceState 設(shè)備狀態(tài)碼videoList 獲取視頻文件列表表3-2服務(wù)器與客戶端通信的狀態(tài)碼格式服務(wù)器返回給客戶端的狀態(tài)碼：stateCode ：0 客戶端請求成功stateCode ：1 客戶端請求失敗stateCode ：2 客戶端用戶名錯誤stateCode ：3 客戶端密碼錯誤stateCode ：4 客戶端手機號錯誤stateCode ：5 客戶端驗證碼錯誤stateCode ：6 客戶端 userToken 錯誤stateCode ：7 客戶端 userToken 過期服務(wù)器返回給客戶端的設(shè)備狀態(tài)：deviceState:0 設(shè)備處于打開狀態(tài)deviceState:1 設(shè)備處于關(guān)閉狀態(tài)deviceState:2 設(shè)備處于故障狀態(tài)客戶端請求設(shè)備操作碼：deviceCode:0 請求打開設(shè)備deviceCode:1 請求關(guān)閉設(shè)備deciceCode:2 請求獲取當前設(shè)備的狀態(tài)表3-3服務(wù)器與客戶端通信數(shù)據(jù)包格式數(shù)據(jù)包格式如下:報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 數(shù)據(jù)包格式的詳細說明(1)報文類型 : 表示誰跟誰通信,大小為1byte報文類型 表示誰跟誰通信 0 xaa AndroidAPP-A90 xffA9-AndroidAPP(2)功能號 : 表示要干什么事情,大小為1byte 功能號(大小為1byte)用戶操作 0 x00用戶注冊 0 x01用戶登陸 0 x02忘記密碼 0 x21發(fā)送用戶原密碼 0 x03修改密碼 0 x04請求獲取溫度0 x05請求獲取濕0 x06請求獲取光照 0 x07請求獲取三軸數(shù)據(jù) 0 x08打開關(guān)閉燈 0 x09打開關(guān)閉風扇 0 x0a打開關(guān)閉門 0 x0b得到視頻文件 0 x0c獲取設(shè)備狀態(tài)(3)數(shù)據(jù)長度:數(shù)據(jù)包攜帶大小為 2byteJSON格式的數(shù)據(jù)（4）數(shù)據(jù)內(nèi)容：JSON格式的字符串數(shù)據(jù)包3.2 數(shù)據(jù)采集端軟件設(shè)計3.2.1總體設(shè)計概述本套架構(gòu)設(shè)計是用于的Exynos 4412（Cortex-A9）與 LPC11C14（Cortex-M0）之間的程序設(shè)計的整體框架和數(shù)據(jù)的處理過程。這里采用的是“三次握手”的機制進行可靠傳輸?shù)模紫華9 通過發(fā)送操作請求數(shù)據(jù)包到M0完成相應的用戶希望得到的操作，同時M0給 A9回復相應的確認包，表示M0已經(jīng)完成了這項操作，這樣就可以完成一次交互。具體實現(xiàn)如圖3-4：圖3-4 M0與A9通信的框架模型圖一 ：（1）設(shè)計思路：A9與 M0之間是用 ZigBee 來進行數(shù)據(jù)的傳輸，ZigBee 有兩個模塊，一個是協(xié)調(diào)器，它與A9是通過串口相連接。另一個是終端，它與M0也是通過串口相連接。 所以我們通過讀和寫串口的函數(shù)接口就可以得到我們想要的數(shù)據(jù)包。（2）設(shè)計講解：在圖中分別有發(fā)出的數(shù)據(jù)包和獲得數(shù)據(jù)包兩種包，這里的包是由之前我們自己定義的通信協(xié)議來決定的。圖中標為淺藍色的字體，數(shù)據(jù)包是從M0發(fā)送到A9。紅色字體說明處理的是溫濕度的數(shù)據(jù)包，當A9請求M0發(fā)送溫濕度或者是光照的時候，M0 采集到溫濕度或光照的信息之后，通過寫串口函數(shù)接口把數(shù)據(jù)寫入ZigBee的寫緩沖區(qū)中，終端ZigBee再通過從電磁波上分離出的數(shù)據(jù)包發(fā)送到協(xié)調(diào)器ZigBee，此時的協(xié)調(diào)器將數(shù)據(jù)包搬移到串口的讀緩沖區(qū)，A9通過讀串口的函數(shù)接口獲取到希望得到的傳感器數(shù)值。圖二 （1）設(shè)計思路：M0中程序的執(zhí)行邏輯，因為數(shù)據(jù)都是通過串口來發(fā)送和獲取的，所以我們可以采用輪詢的方式來查詢終端ZigBee的讀緩沖區(qū)是否有A9數(shù)據(jù)包請求。如果有， 則解析這個數(shù)據(jù)包，從而做出客戶想要得到的操作效果；如果沒有，則需要溫度的數(shù)據(jù)實時（1ms）的寫入終端ZigBee的寫緩沖區(qū)中，目的是為了客戶可以隨時獲取和感知家里的溫度信息。（2）設(shè)計講解：在圖中的第一個分支，當檢測到終端ZigBee的讀緩沖區(qū)中有數(shù)據(jù)，表 明客戶希望操作家里的硬件設(shè)備（風扇、燈）或者是獲取當前家里的溫濕度、光照信息。在這時M0就要解析這些從A9發(fā)來的數(shù)據(jù)包，完成客戶的操作后返回一個確認包，表明已經(jīng)完成此項操作。當檢測到終端 ZigBee 的讀緩沖區(qū)中沒有數(shù)據(jù)，表明客戶沒有操作請求， 需要M0實時的將信息發(fā)送到終端 ZigBee的寫緩沖區(qū)，再通過ZigBee把數(shù)據(jù)包發(fā)送到A9，實時的對周圍環(huán)境行監(jiān)控。M0模塊對數(shù)據(jù)發(fā)送與請求命令的解析過程如圖3-5：圖3-5 M0模塊對數(shù)據(jù)發(fā)送與請求命令的解析過程3.2.2 數(shù)據(jù)采集端M0與服務(wù)器端A9通信協(xié)議設(shè)置這里的協(xié)議是涉及的是M0與A9進行通信的，這些協(xié)議是根據(jù)實際的硬件需要建立的比較簡單的一個協(xié)議。如圖 表3-4,3-5：表3-4 .請求數(shù)據(jù)包格式1.請求數(shù)據(jù)包格式如下報文類型 功能號 設(shè)備編號 數(shù)據(jù)內(nèi)容 (1)報文類型 : 表示誰跟誰通信，大小為 1byte。 報文類型 源端（發(fā)送端） 目標端（接收端） 0 xdd Exynos4412（cortex-A9） LPC11C14（cortex-M0） (2)功能號: 表示要干什么事情，大小為 1byte。 功能號 功能說明0 x04 FS4412 請求 LPC11C14 控制燈0 x05 FS4412 請求 LPC11C14 控制風扇0 x06 FS4412 請求 LPC11C14 控制門(3)設(shè)備編號：區(qū)分同類的每個設(shè)備，大小為 1byte。如 LED1：0 x00；LED2：0 x01(4)數(shù)據(jù)內(nèi)容:數(shù)據(jù)大小溫度（1byte） 濕度（1byte） 三軸信息（3byte）光照（2byte） 7byte 門禁狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關(guān)閉 1byte 燈光狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關(guān)閉 1byte風扇狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關(guān)閉 1byte 表3-5應答數(shù)據(jù)包格式2.應答數(shù)據(jù)包格式如下報文類型 功能號 設(shè)備編號 數(shù)據(jù)內(nèi)容 (1)報文類型: 確認包,報文類型固定為 0 xcc,占用 1 個字節(jié)。報文類型 源端（發(fā)送端） 目標端（接收端） 0 xcc LPC11C14（cortex-M0） Exynos4412（cortex-A9）(2)功能號: 確認的是什么事情。功能號（1byte） 功能說明0 x00LPC11C14 響應溫度數(shù)據(jù)到 Exynos44120 x01LPC11C14 響應濕度數(shù)據(jù)到 Exynos4412 0 x02LPC11C14 響應光照數(shù)據(jù)到 Exynos44120 x03LPC11C14 響應三軸數(shù)值到 Exynos44120 x04LPC11C14 響應燈狀態(tài)到 Exynos44120 x05請求 LPC11C14 響應風扇狀態(tài) Exynos44120 x06請求 LPC11C14 響應門的狀態(tài) Exynos4412(3)設(shè)備編號：區(qū)分同類的每個設(shè)備，大小為 1byte。如 LED1：0 x00；LED2：0 x01(4)狀態(tài)：成功還是失敗，占用 1 個字節(jié)。狀態(tài) 說明0 x00門打開 0 x01門關(guān)閉 0 x00燈打開 0 x01燈關(guān)閉 0 x00風扇打開 0 x01風扇關(guān)閉 3.3 Android客戶端軟件設(shè)計如圖3-6：所示，這個是整個客戶端軟件的功能展示與通信流程：圖 3-6 Android客戶端軟件模塊設(shè)計圖 3-7 是整個客戶端執(zhí)行流程：圖 3-7 Android客戶端執(zhí)行流程圖第五章 系統(tǒng)實驗與調(diào)試4.1 服務(wù)器A9模塊的數(shù)據(jù)接/發(fā)調(diào)試的相關(guān)過程展示依據(jù)前面對服務(wù)器與客戶端約定的協(xié)議進行通信測試：表 4-1 注冊數(shù)據(jù)包收發(fā)格式注冊發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa 0 x00 APP 那邊發(fā)送 的JSON長度用戶名，密碼,手機號發(fā)送數(shù)據(jù)包 A9向服務(wù)器APP發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x002byte 狀態(tài)的JSON格式字符串數(shù)據(jù)內(nèi)容：“stateCode” : 0 成功 數(shù)據(jù)內(nèi)容：“stateCode” : 1 失敗圖 4-1 服務(wù)器端注冊測試表 4-2 登錄時數(shù)據(jù)包格式登錄發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x01 2byte userToken( 唯 一 標識符號)+狀態(tài)注意:登陸成功后，服務(wù)器端需要給客戶端返回一個 ID(唯一身份識別碼)。 客戶端去解析。userToken 為 JSON 格式的字符串。數(shù)據(jù)長度為 JSON 格式的數(shù)據(jù) 內(nèi)容長度.數(shù)據(jù)內(nèi)容：“userToken”:”Qrt3T4”,“stateCode”： 0-登錄成功。 數(shù)據(jù)內(nèi)容：“userToken”:“null”,“stateCode”： 2-用戶名錯誤 數(shù)據(jù)內(nèi)容：“userToken”:“null”,“stateCode”： 3-密碼錯誤圖 4-2 服務(wù)器端登錄時測試表 4-3 找回密碼時數(shù)據(jù)收發(fā)格式忘記密碼發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x02APP那邊發(fā)送的JSON長度 用戶名，手機號碼APP 給服務(wù)端發(fā)送用戶名和手機號，服務(wù)端會通過用戶名和手機號生成一個唯一驗證碼并將其與此用戶名對應起來。圖 4-3 找回密碼時服務(wù)器端驗證碼測試表 4-4 獲取溫濕度時數(shù)據(jù)收發(fā)格式獲取溫度發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x04APP 那邊發(fā)送 的JSON長度用戶名 ，userToken服務(wù)器分配的數(shù)據(jù)內(nèi)容： “userName”:”Qrt3T4”,“userToken”: ”Qr5T4Y” , ”deviceNumber”:0 發(fā)送數(shù)據(jù)包 A9向服務(wù)器APP發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x04 FS4412發(fā)送的 JSON長度溫度JSON字符串數(shù)據(jù)內(nèi)容：獲得到溫度并返回狀態(tài) “temperature ”：20,“stateCode”: 0 數(shù)據(jù)內(nèi)容：未獲取到溫度 “ stateCode” : 1 獲取濕度 發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x05APP 那邊發(fā)送 的JSON長度用戶名 ，userToken服務(wù)器分配的數(shù)據(jù)內(nèi)容： “userName”:”Qrt3T4”,“userToken” : ”Qr5T4Y” ”deviceNumber”:0發(fā)送數(shù)據(jù)包 A9向服務(wù)器APP發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x04 FS4412發(fā)送的 JSON長度濕度JSON字符串數(shù)據(jù)內(nèi)容：獲得到濕度 “humidity” ：21,“stateCode” : 0 數(shù)據(jù)內(nèi)容：未獲取到濕度 “ stateCode” : 1 圖 4-4 獲取溫濕度時數(shù)據(jù)測試表4-5 獲得光照數(shù)據(jù)收發(fā)格式獲取光照 發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x06APP 那邊發(fā)送 的JSON長度用戶名 ，userToken服務(wù)器分配的數(shù)據(jù)內(nèi)容： “userName”:”Qrt3T4”,“userToken” : ”Qr5T4Y”, ”deviceNumber”:0 發(fā)送數(shù)據(jù)包 A9向服務(wù)器APP發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x06 FS4412發(fā)送的 JSON長度濕度JSON字符串數(shù)據(jù)內(nèi)容：獲得到光照 “l(fā)ight” ：300,“stateCode”: 0 數(shù)據(jù)內(nèi)容：未獲取到光照 “ stateCode” : 1 圖4-5 獲得光照數(shù)據(jù)測試表4-6 控制LED開關(guān)的數(shù)據(jù)收發(fā)格式控制LED燈 發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x08APP 那邊發(fā)送 的JSON長度0：開燈 1：關(guān)燈數(shù)據(jù)內(nèi)容： “userToken”:”Qr5T4Y”,”deviceNumber”:0, “deviceCode” : 0, “userName”: ”Qrt3T4” -開燈 “userToken”: ”Qr5T4Y” ,”deviceNumber”:0, “deviceCode” : 1,“userName”: ”Qrt3T4” -關(guān)燈發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x08APP 那邊發(fā)送 的JSON長度狀態(tài)JSON格式的字符串 數(shù)據(jù)內(nèi)容：“stateCode”: 0,”deviceState”:0 用 戶操作成功 設(shè)備處于打開狀態(tài) 數(shù)據(jù)內(nèi)容： “stateCode” : 1，deviceState:1 用 戶操作失敗 設(shè)備處于關(guān)閉狀態(tài)圖4-6 控制LED開關(guān)的測試表4-7 控制風扇開關(guān)的數(shù)據(jù)收發(fā)格式控制風扇 發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 APPA9報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xaa0 x09APP 那邊發(fā)送 的JSON長度0：開風扇 1：關(guān)風扇數(shù)據(jù)內(nèi)容： “userToken”:”Qr5T4Y”,“deviceCode” :0,“userNa me”: ”Qrt3T4”,”deviceNumber”:0-開風扇 “userToken”: ”Qr5T4Y” ,“deviceCode” :1,“userN ame”: ”Qrt3T4”,”deviceNumber”:0-關(guān)風扇發(fā)送數(shù)據(jù)包 APP向服務(wù)器A9發(fā)送注冊數(shù)據(jù)包數(shù)據(jù)流向 A9APP報文類型 功能號 數(shù)據(jù)長度 數(shù)據(jù)內(nèi)容 0 xff0 x09APP 那邊發(fā)送 的JSON長度狀態(tài)JSON格式的字符串 數(shù)據(jù)內(nèi)容：“stateCode”:0,”deviceState”:0 用戶 操作成功 設(shè)備處于打開狀態(tài)數(shù)據(jù)內(nèi)容： “stateCode” : 1,”device圖4-7 控制風扇開關(guān)的數(shù)據(jù)收發(fā)格式4.2 數(shù)據(jù)采集M0模塊的調(diào)試如圖4-8 光照傳感器測試：圖4-8 光照傳感器測試如圖 4-9 溫濕度傳感器測試：圖 4-9 溫濕度傳感器測試4.3客戶端測試展示圖 4-10 客戶端注冊圖 4-11 客戶端登錄圖 4-12 客戶端找回密碼圖 4-13 客戶端主界面第六章 總結(jié)反思整個系統(tǒng)選擇定位的就是一個輕量級別的輔助系統(tǒng)，所以在實際的開發(fā)中也是很方便簡單的，我參照的就是小米智能家居的模式，在實際的開發(fā)中，模塊靈活的度高，拓展性較強。但是在實際的開發(fā)的過程的時候，能夠參考的資料并不多。整個系統(tǒng)采用的是以路由器為核心的管理模式。但是問題也來了，路由器中心論從產(chǎn)品層面看，路由必須做到全天候在線監(jiān)控，對穩(wěn)定性要求無疑是極高的。從另一個角度講路由器這個東西是單一性質(zhì)的，本地中一般僅一個。這也意味著，你的產(chǎn)品好呢一切大吉，一旦一款產(chǎn)品不好，甚至整個產(chǎn)品鏈都會被消費者拋棄。在當前物聯(lián)網(wǎng)發(fā)展的過程中，無論是傳統(tǒng)電商還是互聯(lián)網(wǎng)公司，他們都在做平臺推廣平臺，從而爭奪物聯(lián)網(wǎng)的話語權(quán)。對于物聯(lián)網(wǎng)的在宜人家居的發(fā)展模式，可謂是仁者見仁智者見智，他們認為智能家居沒有天生的中心，也不會產(chǎn)生入口，它所提供給我們的是一個以服務(wù)為核心的架構(gòu)。在當前市場背景下作為一個企業(yè)來說，能夠生存下去，要么賣服務(wù)要么賣產(chǎn)品，對于一個互聯(lián)網(wǎng)科技公司，我們能夠為農(nóng)業(yè)提供什么樣的優(yōu)質(zhì)服務(wù)！？做推廣服務(wù)的時代已經(jīng)是活不下去了，對于硬件產(chǎn)品的投入的也是遙遙無期的，單純農(nóng)業(yè)領(lǐng)域的硬件投入是不科學的，無論是從使用價值上還是現(xiàn)實的技術(shù)條件都是一蹴而就的。生活是生命的一部分，工作是生活的一部分。這些硬件僅僅是工作的一部分，家電卻是是我們優(yōu)質(zhì)生活的一部分，在追求優(yōu)質(zhì)的生活的時候必須考量的因素，但是對于這些物聯(lián)網(wǎng)硬件來說也僅僅是你工作的一部分，只要能夠高效的輔助工作我們在實際的理念上已經(jīng)屏蔽掉的具體硬件的選擇。所