阿里云物联网平台搭建（3）基础平台深入理解脚本

最近几天专门针对自动生成的脚本进行深度理解，要求达到能够独立修改和编写。不可否认自动生成的代码有很多的参考价值，但也有很多坑。

首先一定要确保脚本版本、MCU物模型文件 与物模型保持一致，不然会导致属性id对不上，属性类型对不上。INT 和 UINT 类型不一样，硬件对于其长短定义不一样，会导致上报解析错误，这是开发应用层的同学很容易忽视的错误，命名两个方法解析得步骤都一模一样，甚至进去把解析源码看了一遍，始终想不到问题所在，硬件同学一提示就能明白了。

对于功能定义中提交新增或修改了数据类型的需要审核，修改数据长度的不需要审核，审核时间挺长的，为了避免影响开发进度，尽量按照实际类型和长度来，不要在一个字段里面再加解析判断。

对于服务的开发，service方面的文档比较少，服务用于实时获取设备属性，是设备直接返回的。get方法是获取的飞燕订阅设备的属性，设备有改变就上报，从而保证飞燕服务器存储的属性是实时的，但是如果设备某个属性变化频繁会带来很大的流量负担，不同的产品还有其他的不适用的地方，基于这种问题选择使用服务更好些。

下面这个表很重要，缺少很多说明，只能一步步验证自己的猜想了。

不同操作的不同方法

这里很容易忽视的地方在于回复的方法不一样，对应到脚本里面的处理逻辑会有点头晕，其实认真看看不难发现其中的规律，也就是tcp\ip 协议的回应机制。

没有数据的回复都是通过ack回复的，有数据的回复，不同的数据请求有不同的回复方式，service的数据回复通过service回复，发布和订阅都是用0x02.脚本对于服务、事件、属性的解析是平行的，也就是说都有各自的id，服务有服务id。

服务和事件的id是放在data域里面的1字节，与属性id放在外面4字节不一样

基础平台的服务在上行的时候会提示上行错误，提了工单都说基础平台服务不能上报，主要用来触发多个同时设置的值。