之前的物联网大多以项目为导向，结果许多项目被甲方牵制，无法实现一个通用物联网设备云的目标。现在总算抽空开始将之前的项目中性化，转化为一个通用的物联网设备云：EPIC，Extensible Python IoT Cloud。由通用的设备（云）服务器和应用服务器（云）构成。
如果设备能力足够强，使用HTTP/MQTT+TLS方式接入云端，可以采用BAT/GAF + Azure提供的标准化IoT Hub。各类IoT Hub本质上都是一样的：先通过HTTPS获得凭证，然后通过MQTT/TLS接入IoT Hub。IoT Hub可以作为一个透明传输通道，而且解决了在第三方数据流分享的过程，随后附带数据分析、数据存储等服务。这种做法的鼻祖就是Xively。
EPIC设备云存在的意义
所谓设备能力足够强，主要是指计算能力、RAM/ROM存储空间足够满足HTTPS/MQTT+TLS方式，还需要JSON等传统联网编码的需求。这需要MCU具备M3/M4内核，64KB RAM + 512KB ROM左右的配置。虽然最近涌现的ESP8266/ESP32及其IoT竞品的价格组件降低（< CNY10），但是传统架构如M4 + WiFi SoC的BOM价格都不低（> CNY 25）。所以更多的配置是采用低配MCU + SoC的做法。RAM/ROM太少，两者间RAM太少是致命伤。所以低端配置往往不具备采用标准方式联网的条件。这迫使设备云必须提供一定程度的定制。这就是其存在的意义。
定制不意味着放弃最佳实践
在定制协议的时候，不能够放弃行业的最佳实践。以项目为导向的工程中，话语权很容易倒向制造商，但是来自传统行业的设备制造商的开发团队最容易犯的毛病包括：
- 把TCP连接等同于串口连接，将串口协议直接平移到TCP协议中；
- 把设备云的云计算是为对等的上位机，引入复杂的状态机模型；
- 把设备云视为自己系统的一部分，限制设备云的扩展能力；
- 忽略安全。
TCP连接与串口连接
串口连接是一种实时的，面向连接的数据流。TCP是一种非实时的，面向连接的数据流。相同点都是面向连接的数据流，差异点在于TCP是一种虚连接，不是电路连接，所以容易产生收发粘连和卡顿。而这在接收端造成了困难，需要依靠通讯协议来切割以及拼接分组报文。所以，串口协议不能够平移到TCP协议上。
我接触的客户，凡是有这种冲动的，无法说服的话，我会放弃这家客户。
复杂状态机
实际上，在串口通讯中，上位机（主机）和下位机（设备）之间往往会有不同的状态机：数据采集、设备配置、事件推送、固件下载，甚至和业务本身相关联的状态等。这一点主要和串口的分层模型有关。由于串口只有物理层和应用层，所以设计者的设计思路主要集中在业务状态中。
在物联网中，制造商往往会本能地将此类应用层状态机带入到设备云中。而设备云恰恰只是一个透明通道，不应该涉及到此类状态机设计中。
参考MQTT/CoAP协议，都只是提供一个传输层协议，至于Topic/Message/URI是什么，对于设备云来说完全无感。它仅仅负责传输而已。
所以，在物联网中，更多的状态机管理会移动到设备端一侧。正确的定制方式是分为两层：在TCP之上定义的一层不应涉及业务，而业务应用相关的额外定义。简化的是MQTT/CoAP的定义而已。
对应的方式是采用虚拟寄存器的方式进行交互。
设备与设备云的关系
由于商业的因素，导致话语权失衡。供应商经常将设备云视为自己的资产，会下意识地减少自己在设备测的开发难度。但许多做法会限制自己将来的发展。比如，企图简化所有Id/Key的流程，将产品序列号作为唯一索引。
道理是这样的，即使是同一框架下，凡是进过一个关卡，比如验证对象的Id和Key。而且Id/Key发行权归属于关卡。
所以制造商必须向设备云申请下发Id/Key，烧录在设备中，设备联网向设备云提交Id/Key。而且产品序列号和设备Id/Key的发行方和发行目的完全不同。绝对不能够混用。
忽略安全
物联网安全一直被人反复提及，却又放在最好。主要原因还是成本，因为TLS套件需要不少计算资源。目前我在测试ECDH/ECDSA/SHA/AES的加密套件。目前还没有完全测试，仅仅使用了AES128 CBC模式。
EPIC组成部分和提供的定制服务
- 支持MQTT/CoAP和自定义协议；
- 定制自定义协议的Connector，接入EPIC设备云；
- 针对自定义协议生成mbed/Arduino C++代码；
- 采用数据缓存/RDBS/TSDB混用方式存储数据，无数据瓶颈；
- 采用消息队列转发数据；
- 采用JSON下发配置。
- 选用HTTPS下发登陆地址（可选）；
