一、物联网接触经历
1、2016年9月-2017年9月
毕业课题研究恰好是关于物联网架构的设计与搭建，大体完成有：树莓派GPIO口采集传感器数据，并将数据存储到亚马逊云服务器中，加上一个简单的网页进行数据展示。
但当时的”传感器“略为粗暴了点，分别是:一个为了测光强从花园灯上拆下来的太阳能电板;一个接上电源，有风吹会产生高低电平的风叶，只是没有驱动..于是根据风叶的技术手册在树莓派上用python读取GPIO硬生生编了一个”驱动“出来，计算出的风速和气象局的数据还挺接近。
向亚马逊的云服务器传输数据并没有使用图形化界面，写了一个建立在ssh连接上的C语言套接字程序；数据发送到云服务器上后存到数据库这一步骤也得自己动手，C语言操作数据库，数据库用的sqlite3.为了在web显示数据，html网页,php访问数据库也写了点。
不过，自己编也有自己编的好处，比如可以自己制定发送数据的格式，可以将在树莓派各个程序中交换的50Bytes的数据用C语言位操作降至15Bytes，再用套接字发送到网络，到服务器端再位反操作，除了节省网络数据流量之外也算一种简单加密吧。
经历过上述步骤后，觉得物联网真正从零开始搭建其实不太容易。但是有了前人的努力，现在最重要的应该是怎么分析和使用这些数据，以及考虑在实际应用中可能会出现的问题并加以解决。
2、2019年4月-5月
今年上半年，在DF创客社区申请了ESP32(Gravity套件)与阿里云的试用并做了一些评测。
具体完成有：
a.搭建ESP32与阿里云的直接连接(WIFI->有线).
b.调试各种传感器采集数据并存储至阿里云端.
与之前自己搭建的系统相比，阿里云IoT平台实在是省去了很多气力。不过，自己从底层开始编写代码也有其好处，比如可以自己制定发送数据的格式，可以将在树莓派各个程序中交换的50Bytes的数据用C语言位操作降至15Bytes，再用套接字发送到网络，到服务器端再位反操作，除了节省网络数据流量之外也算一种简单加密吧。
---------------------------------------------------------------------------------
二、毕业课题研究回顾
当时设想的是，在一块区域中，有大量采集数据的节点（为方便叙述称为端节点），体积小、功耗低。每个节点都有多个传感器，不间断采集数据并发送。同时该区域内有一个服务器汇集所有的数据进行分析。
但由此会产生一些问题，课题中主要讨论的是大量数据的产生，将导致服务器任务的过于繁重以及网络的拥堵。当时讨论的传输方式讨论是Zigbee,WiFi,和有线连接，分别在不同情况应用。现在5G在国内的大力推广也许由此会产生新的解决方案。
I.中间节点
为了解决上述问题,在端节点和服务器之间引入中间节点，每个中间节点收集其附近的端节点数据，进行一定处理后发送给服务器。这样一来可以减轻某一时刻服务器的压力。比方说，由原来和1000个端节点通信现在只需要和100个中间节点通信就行。但是由此一来，网络传输的模式也要发生变化。刚才提到的Zigbee，WiFi等也就是用于这时候。
Zigbee短距离、低功耗、低传输速率，适合中间节点收集附近节点数据；WiFi长距离、高功耗高传输速率，通过无线基站和服务器通信。中间节点到无线基站是无线，无线基站到服务器是有线连接。
中间节点和端节点的区别，之前设想的是从端节点中“选出来”，也就是没有区别的。不过每个端节点搭载有多种信息传输方式。工作为中间节点方式时，为高功耗的WIFI模式。端节点模式时是低功耗的Zigbee模式。至于如何从端节点中选出中间节点，初步想法是根据端节点位置、电量、周围覆盖包含端节点数量等。又因假设端节点可以移动，较为复杂，课题研究的主要目标为搭建整体系统，故当时并没有细究。
II.区域自治(automony)
有从端节点到服务器的数据采集，也就有服务器到端节点的动作指令。选出中间节点后，区域内的数据经服务器进行分析，得出一定的模式。根据这个模式，服务器将这个动作指令告诉中间节点，由中间节点对各个端节点进行指令的发出。无需服务器对每个端节点进行直接操作（参照过雾计算）。
就像大学里辅导员管班长，班长管一个班几十号人。
当时课题中和导师讨论的关于架构方面主要是上述两点。至于应用方面，导师给出过一些例子。
III.一个例子
做课题研究时，所在的小城是一个很会刮风的地方，尤其是风喜欢和雨一起来。这时候就给撑伞的人们带来很大不便，尤其是老人和小孩，过于强烈的风可能还会使他们受伤。于是就想，是不是可以有这么一个系统，在风到来之前可以预警附近撑伞的人们，比如用喇叭广播。
联系之前讨论的物联网系统，在一座城市中，有很多可以实时监测风速的传感器（端节点）。现城东边缘的传感器监测到了强风，将数据发送至附近的中间节点，中间节点将数据汇总发送至城市中心的服务器，服务器分析得出风的轨迹以及接下来影响到的区域，将预警信息发送给该区域的中间节点，中间节点给所在区域的端节点发送指令，各端节点提示附近人们:有强风来了!撑伞的人注意!
至于区域自治，一个季节的风一般具有规律。服务器在采集了足够多的数据之后，可以得出风的模式，根据该模式可以得出一个布署在中间节点的程序。于是下一个该季节到来时，可以不必再由服务器给出指令，中间节点可以自行作出预报对各端节点进行控制。
当然上述有许多地方没有说明，比如喇叭广播的高功耗与假设低功耗的节点不符,位于城东风前沿的节点是否可以进行端节点到端节点的直接通信；区域自治的讨论中，中间节点脱离服务器能否收到其他中间节点的纠正信息。涉及到具体应用时要展开讨论的比较多，该例子主要是为了把课题研究中的架构进行阐述说明，脱离一定的实践再继续展开过远的讨论可能有点过于夸夸其谈。
-----------------------------------------------------------------------
三、未来计划（2020年-2021年）
I.概述
由阿里云到ESP32的二层模型到初步搭建三层模型。即在阿里云（服务器）和ESP32（端节点），中间加入一个中间节点，实现由阿里云与中间节点，中间节点与ESP32的通信。
注：中间节点此时选择树莓派。
II.具体步骤
a.搭建ESP32与中间节点的连接(蓝牙).
b.传感器数据采集、储存至中间节点.
c.中间节点整理汇总数据，发送至阿里云(WIFI->有线).
d.阿里云分析数据，得出其变化的模型、预计其今后的趋势.（例如:土壤一天湿度变化，参照变量有晴雨阴天等）
e.服务器向中间节点发出指示.
f.中间节点令端节点做出动作.
III.一些点
a.ZigBee的部署.
b.中间节点与端节点的一致.
c.arduino的加入.
IV.现有设备
树莓派2代*1、Arduino*2、散装购置的传感器若干。
------------------------------------------------------------------------
四、杂记
2018年6月和2019年年初试了试阿里的云服务器，分别是低配包月和按时计费。纯属看看玩玩，没有什么实际成果。前段时间阿里云客服还打电话建议我如果不用资源可以先释放掉，好像虽然按时计费但是就算停止实例也要收费。
2019年5月左右国家新出了物联网安装维护师、无人机驾驶员等新职业，感觉还是有点小期待的。对纯粹的编写代码确实不太感冒，希望以后自己能多接触一些硬件。
2019年10月以来，一直免费的阿里云IoT好像终于要开始收费了，而且一直提醒我有更新的内容与功能，看来发展势头良好。