菜鳥是如何打造智能家居系統的

     首先須要說明的是本人只是一名普通的研究生，在學校的研究方向和物聯網系統也沒半點毛線關係，關於這個項目只是業餘時間的一點嘗試，至今也沒作出能讓我有資格得瑟的產品。說不定這個系統對於專業人士來講簡直是小兒科，但對我這個業餘選手來講，卻斷斷續續嘗試了兩年。

    故事得從我大三下學期（2013年）提及，話說我當時只是一個一心一意搞學習的好學生，反正就是社會上說的關於大學生的噁心在我身上是找不到半毛，對，我就是這樣一個好學生，我也就打算這樣渾渾噩噩混到畢業了，若是運氣好，可以憑好成績保上研究生也是極好的。某日，室友找到我說某某人有一個大學生創業項目缺人，他推薦了我。其實一開始我是拒絕的，由於我清楚本身除了能考個好成績肚子裏可真心沒多少貨，一會兒來了一個聽起來這麼高大上的項目，我哪裏敢接手，可是後來一想，本身在團隊裏也不是主要負責人，只是去打個下手吧，只要作好力所能及的事就行了，也就答應了下來。好久之後，我才明白，其實項目裏的全部人基本都是菜鳥，都是在摸索，找隊員的時候，並非看我的都對這種項目瞭解多少，看中的是你這我的的自學能力有多強，如今我也發現，技術這麼多，項目換來換去，一我的能掌握多少，一流的公司招人的時候就應該適當多考慮那種自學能力強、潛力巨大的人，說的就是我這種人哈!

    不能廢話了，介紹一下那個大學生創業項目，國家爲了培養大學生的創新創業能力，政策上仍是給了不少支持的，（我會告訴你，國家的錢大部分都打了水漂嗎？固然，也只能靠錢砸了），首先是學院的一個老師知道這個項目，就聯合校外一個咱們前幾屆學長的小的初創公司想找幾個本科生來申請這個項目，（我會告訴大家，咱們只是用來套國家錢的嗎，哈哈，可是事情每每從不靠譜開始）。由於是創業項目，申請項目時須要有完整的商業計劃書，就是吹吹咱們的技術有多麼牛逼，之後發展前景多麼廣大，記得當時咱們的初稿只有20多頁，老師非要咱們擴充到60業以上，咱們東拼西湊，因而就有了：

基於能量收集的智能家居-2013國家級大學生創業實踐項目申報_商業計劃書，項目標題加上」基於能量收集「，固然是爲了響應綠色環保的號召，其實能量收集哪有那麼好作，反正先無論了，先忽悠評委把項目拿下來，把錢搞到手纔是當務之急。結果可想而知，咱們順利忽悠了評委，否則也沒有之後的故事了。固然錢進了老師的腰包（咱們當時並不懂額，咱們只是純潔的學生而已）。

    大三暑假，咱們須要實習，小夥伴們都跟着學院的安排去了葛洲壩，咱們就鑽空子去了學長的公司實習，恰好有那個老師當實習指導老師，順便去把這個項目也給作了，真是一箭雙鵰，整個暑假咱們都在公司那邊，那是一個初創的公司，還沒一個像樣的產品，不過有一個經驗比較豐富的學長也是極好的，咱們滿懷期待的開始作項目了，你覺得咱們是作前面申請的那個項目嗎，都說了那個只是用來套錢的。咱們的第一個的工做室花一個星期翻譯了這個：

TI  Zigbee Light Link 參考設計可是也沒接觸過這類東西，後來開始作的時候，才發現翻譯錯了好多東西。這個文檔是TI（德州儀器）公司出的，介紹了智能燈泡的控制，利用這個設計大概能夠作出像飛利浦hue這樣的產品（ 智能照亮生活：飛利浦 hue 智能照明評測），什麼，你沒聽過飛利浦hue,其實小米官網也有這樣一款相似的產品（ Yeelight牀頭燈）

這個是yeelink公司出的，產品的創意應該也是參照了飛利浦hue。整個暑假咱們的目標就是參考 TI  Zigbee Light Link 試圖設計出一款這樣高大上的燈泡。借用學長的一句話，」別看這個系統，麻雀雖小，五臟俱全「，確實，不管多麼大的智能家居系統，基礎原理和這個都是相同的，咱們的方案是設計一個帶ZigBee通訊功能的燈，用STM32作網關，在STM32上也帶一個Zigbee模塊和燈通訊，而後將網關連上路由器和遠程的雲平臺通訊。而後咱們就開始分工了，一我的負責網關的芯片設計，一我的負責網關的程序開發，一我的負責終端燈的程序，一個負責燈的硬件，一個負責遠程控制須要的雲服務。我對硬件一竅不通，因此負責了網關的程序開發，參考 TI  Zigbee Light Link 參考設計硬是啃了兩個多星期，才差很少弄清楚裏面網關程序的設計，寫了三篇文檔：

1. 主機接口的信息處理流程
2. 網關程序分析
   
3. 本地局域網通訊過程
   

     這個程序原本是運行在Linux嵌入式系統的，個人任務就是把它移植到STM32中，這裏我固然不能具體的分析裏面的程序了，不得不說，那時從沒有接觸過這麼大型的程序，分析透徹事後才發現，網關裏的程序設計的真心規範，對燈的控制流程程序寫的至關巧妙高超。有興趣能夠本身研究。那年暑假咱們都在作 TI  Zigbee Light Link，最後的成果咱們順利實現了局域網內燈的控制，開關、亮度、顏色都能實現了，這個貌似比yeelink還早作出來。暑假結束後，由於要準備保研的事情，因此項目暫時放下了，直到保研結束，咱們又撿起了這個項目，這個時候，原來的團隊已經散掉了，有出國，有工做的，有保研的，看着這個半成品，我仍是想把遠程控制繼續作完，所以須要搭建一個雲平臺（請原諒我說的這麼高大上）完整的系統大概是這樣的

基於ZigBee的家居控制系統的設計與應用

    由於本科時一個偶然的機會寫過幾句php，學長就把這個任務交給我了，其餘的交給一些新來的小弟來作了，後來才發現這個平臺哪裏是幾句php能完成的，那個時候連框架都不知道是什麼東西。最後我仍是決定仿照yeelink平臺搭建一個，這個平臺不只僅是控制燈用的（畢竟咱們要作一個智能家居系統），而是將全部終端設備抽象成傳感器，這個概念我在 基於ZigBee的家居控制系統的設計與應用開頭的PPT裏有介紹 。因而就有了： 智能家居雲平臺設計學長提的要求是雲平臺接口要用RESTful風格。通過搜索，最後選擇了 codeignite框架來搭建平臺，這個框架自己是不支持RESTful風格的，幸好國外的大神修改了代碼，讓其支持RESTful，能夠參考 使用CodeIgniter框架搭建RESTful API服務，代碼可參考 雲平臺代碼。

    雲平臺設計好事後，我就開始興奮的測試個人燈了，到底能不能實現傳說的遠程控制呢，結果我發現雲平臺設計有一個缺陷，不能推送數據到終端設備。終端設備必須輪詢雲平臺才能知道數據有沒有變化，這樣的控制卻是測試成功了。這樣對服務器和終端設備性能就會產生很大影響，只有兩種解決方案，要麼用第三方推送（如，極光推送），要麼本身搭建，鑑於應用的特殊性，第三方可能不知足要求，因此我決定本身搭建一個。最後參考了 基於 HTTP 長鏈接的「服務器推」技術也就是comet，從新編譯了服務器的nginx，讓其支持 Comet技術，測試事後勉強能用推送，遠遠沒到能適用的程度，這種技術用在瀏覽器終端卻是很實用，可是讓 服務器推送到 一個嵌入式的終端設備，倒以爲很不適用。作到這裏，個人研究生生涯開始了，我就辭掉了公司的工做，開始學習和實驗室的項目，很久沒過問了。

     前不久，學長又找到我，讓我幫他們的智能家居控制APP作一個後臺，我覺得仍是接着那個雲平臺作，後來他告訴我，設備控制走的是 機智雲。只須要作一個app自己的後臺就好了。一個偶然的機會我發現他們在調試與機智雲的通訊時錯誤提示中出現了MQTT的字眼。忽然想起我以前收藏的一篇文章： Android實現推送方式解決方案中提到了一個MQTT協議，我就猜測像機智雲這樣的雲平臺與設備間的通訊協議是否是應該是MQTT協議而不是http協議。我趕忙萬能的百度，果不其然，搜索」機智雲mqtt「和」yeelink  mqtt「肯定這兩個平臺如今都用到了MQTT協議，再搜索MQTT，如： 例說「MQTT協議」，才發現這個協議在物聯網上如今用的不少，當時作的時候這類信息尚未， 惋惜設計雲平臺的時候yeelink仍是 基於HTTP RESTful的輪訓方式，否則我早就發現了。不過如今也有了思路，若是接下來有時間我就會加上MQTT服務，一個高大上的簡單的智能家居雲平臺就完整了。看來小公司打造本身的智能家居生態系統也不是不可能的事。

 

 

 

 

來自爲知筆記(Wiz)