首先需要说明的是本人只是一名普通的研究生，在学校的研究方向和物联网系统也没半点毛线关系，关于这个项目只是业余时间的一点尝试，至今也没做出能让我有资格得瑟的产品。说不定这个系统对于专业人士来说简直是小儿科，但对我这个业余选手来说，却断断续续尝试了两年。
故事得从我大三下学期（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服务，一个高大上的简单的智能家居云平台就完整了。看来小公司打造自己的智能家居生态系统也不是不可能的事。