首先需要說明的是本人只是一名普通的研究生，在學校的研究方向和物聯網系統也沒半點毛線關系，關於這個項目只是業余時間的一點嘗試，至今也沒做出能讓我有資格得瑟的產品。說不定這個系統對於專業人士來說簡直是小兒科，但對我這個業余選手來說，卻斷斷續續嘗試了兩年。
故事得從我大三下學期（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 參考設計硬是啃了兩個多星期，才差不多弄清楚里面網關程序的設計，寫了三篇文檔：
這個程序本來是運行在Linux嵌入式系統的，我的任務就是把它移植到STM32中，這里我當然不能具體的分析里面的程序了，不得不說，那時從沒有接觸過這么大型的程序，分析透徹過后才發現，網關里的程序設計的真心規范，對燈的控制流程程序寫的相當巧妙高超。有興趣可以自己研究。那年暑假我們都在做
TI Zigbee Light Link，最后的成果我們順利實現了局域網內燈的控制，開關、亮度、顏色都能實現了，這個貌似比yeelink還早做出來。暑假結束后，因為要准備保研的事情，所以項目暫時放下了，直到保研結束，我們又撿起了這個項目，這個時候，原來的團隊已經散掉了，有出國，有工作的，有保研的，看着這個半成品，我還是想把遠程控制繼續做完，因此需要搭建一個雲平台（請原諒我說的這么高大上）完整的系統大概是這樣的
因為本科時一個偶然的機會寫過幾句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服務，一個高大上的簡單的智能家居雲平台就完整了。看來小公司打造自己的智能家居生態系統也不是不可能的事。