仪表在电池/外电源切换时平台的自动切换支持
PS：可参照电信NB平台，下文中的短链接模式下平台实现的机制类似电信NB后台的功能。
2种模式说明：在外电源供电情况下，采用长链接模式，仪表定时发送心跳包，服务器与仪表之间采用应答式通讯机制，所有指令实时下发，包括定时数据采集及控制指令；在电池供电情况下，采用短链接模式，控制指令在服务器缓存，只有当仪表上线并主动上报数据完成，服务器才下发控制指令，所有工作完成后仪表断网进入休眠状态。
本功能实现以下目的：
1 支持外电源长链接模式，客户可自由设定数据刷新间隔，可设定远程操作指令
2 支持电池供电定时上线模式，仪表定时上报数据，可设定远程操作指令
3 系统可根据仪表工作模式自动切换（仪表上报指令通知平台）
要解决的问题
1 电池供电模式下，仪表定时上线，需要解决控制命令缓存的问题，只有当设备上线的时候才下发
2 在部分情况下，需要比较详尽的数据，但是频繁上线会消耗电量，所以采取仪表定时采集传感器数据，上线时集中上报数据。举例说明：下位机单片机5分钟采集一次数据，6小时上报一次。每次上报数据有72条，在连续上报历史数据的过程中，会产生2个问题 1 如果连续上报，会产生粘包问题 2 如果间隔5S上报数据，耗时太长，且不能消除粘包问题。
3 在有下发指令的情况下（在线充值，开关阀），如何协调指令下发与数据上报之间问题
解决方案
1 C5短链接模式下仪表与平台交互逻辑
2 数据包头机制
所有数据（包括上报数据及下发指令）均加上包头，包头格式为：
0XFA 0X0A 0X1F 0 X1F 0 X1F 数据长度(1个字节)
比如仪表上传数据为 01 03 04 11 22 33 44 4B C6，则在C5包头机制下发送数据为 FA 0A 1F 1F 1F 09 01 03 04 11 22 33 44 4B C6
此机制可以解决如下几种情况：
A 2条数据包粘成一条，可以正确识别。
B 3条数据包，平台接收变成2条数据。系统会自动将此2条数据进行拼接并识别为3条数据。
C 连续3条数据，平台接收的时候，每2条数据中间都会插入一些垃圾数据。此情况下，系统也会准确的识别3条数据。
注：此机制已经可以确保数据准确性，无须包尾。理论上说，基于无线联网的系统均需加上包头机制。当然，在有线联网情况下，无需添加包头。
至于仪表与服务器平台之间的数据交互指令，可使用任意格式和规范。标准modbus可以，自定义的通讯协议也可以，只要满足包头机制即可。
3 数据确认机制
部分重要的数据，必须要 仪表/平台 确认收到才能够做下一步操作，比如模式切换机制（在平台，长链接与短连接是完全不同的运行机制），仪表由电池供电切换成外电源供电，上报模式通知指令的时候必须收到服务器的回复才可以正式切换，这样可以保证仪表及服务器均可以运行在同一种模式下。当然，绝大多数情况下，数据不需要回复。有了这样一种机制，可以做到平台跟随仪表自动切换运行模式，因为在服务器平台，2种模式除了数据接收，指令下发，对历史数据的处理也是完全不同的逻辑。
所以，在做仪表程序初始设计的时候，至少应该设计一条供电模式切换通知指令，且此指令，服务器必须回复，且只有收到服务器正确回复后，单片机数据收发机制才能按照新模式运行。当然某些重要的时间节点数据，以及重要的报警数据，也需要平台确认回复收到。
4 时间戳机制
如果需要上报历史数据，则在中间中必须携带时间戳。
通过以上4个方面的改进，可以完美实现平台在仪表供电机制改变时候的自动切换。
当然了，有人可能会说，我的要求比较简单，比如流量计，不管是外电源，还是电池供电，6个小时主动上报一次数据，别的需求也没有，还用弄得你这么复杂嘛。当然不需要了，如果只是这么简单的一个需求，上面的啥交互机制，包头机制，确认机制，时间戳机制通通都是废话。只需要仪表程序设计成定时6个小时上报一次就完事，不涉及到模式切换的问题，当然了，服务器平台也不涉及到什么模式切换的问题。
