物联网版本的水控机：可以扫码打水（微信，支付宝，电子钱包），以及刷卡打水，最多4个出水口，具有修改扫码单价，刷卡单价，限额，脉冲数还可以在线充值。
要解决的问题：
刷卡以及扫码达到限额（单次最大出水量），不能立即返回主界面，要显示计量消费界面，让客户知道为什么水停了。达到6s，流量计未计数，此时需要显示流量计故障，刷卡时，是实时扣费的，这问题不大，扫码是预付的，固定金额的。如果扫码支付2元，出水1元，报流量计故障了。此时的结算包改如何处理，我这里的处理是消费了多少，就上传多少，服务器如何处理，返还还是吃掉，设备端不管。
流量计故障如何消除呢，刷卡容易消除，只要消费了就有结算，说明流量计跑数了，在结算函数里给流量计好坏标志置位0；如果是扫码呢，扫码也有一个结算，没有消费也存在一个结算，固定金额和电子水卡都会出现类似情况，在扫码结算时加一个判断，如果有消费才置位0。本可以状态包105，能够实时上传流量计工作状态，流量计故障就显示不可以扫码支付。
流量计出现故障，置位1（定时器中断里置位，并且尽可能发送状态包105，告知服务器这个出水口流量计故障，扫码支付暂时不可用）。只能通过刷卡打水，成功结算清除流量计故障状态。
3.刷卡出水过程中，如果扫码支付，支付会成功，需要做的是，刷卡出水，要置位（因为之前的bug目前实现较困难），
工作状态是在制水中；扫码出水中，本地已经禁止刷卡了。
工作状态很重要：忙与空闲，扫码以及刷卡触发阶段就要改变工作状态，扫码刷卡消费结束立即改变状态；工作状态是判断设备能够提供服务的充要条件。何时置位，何时清置位，类似malloc与free的关系，形成闭环，设备才能工作的顺畅。
触发阶段：扫码支付成功，这里是回复404。
如果是刷卡呢，会发个104，服务器会比对数据，禁止打水，充值都在此阶段完成。这个阶段咋改变状态呢？按灌装键发送一条状态包，结算时在发送一条状态包。出水时间很短，这2条状态包发送间隔是不是很短，实际上，刷卡出水中，有谁那么无聊会去扫码支付呢？这个问题先保留。
4.刷卡板和4g通讯板不同时供电，可能存在登录不成功；连上服务器不代表服务器能够与设备通信，服务器要通过一个id(唯一标识符)查找连接的句柄，登陆包错位，就能通信不上，虽然模块指示灯在闪烁，解决方法是：4g模块负责联网，并且登陆包，心跳包，校时包也交给4g模块直接发送。这样灯快闪，服务器就能找到设备，单片机发送心跳包，存在个时序，id在刷卡板内。
5.离线数据处理：在网络状况不好的情况下，需要把消费记录保存起来，半夜主动上传，或者设备在线的状况下，手动获取离线数据。
6.4G模块发送心跳包，校时包，登陆包由设备端发送，发送完，4G模块缓存登陆包重要信息，当网络不稳定时，4g模块发送登陆包，因为网络不稳定，连接断了，必须有登陆包，服务器才知道是谁连接上了他，心跳包里有设备号也不行，必须先登陆包，建立一个认证，心跳包才认可，不然，发送心跳包服务器就会踢掉。
单片机代码是C语言：采用时间片模式，周期是1s,各个任务函数时间点间隔125ms,一共6个任务，时间一共750ms,还有250ms作为冗余，以备某个任务超时。优先级采用传统的 if else if 模式。不允许任何延时函数。保证单片机高效率扫描，兼顾到所有任务函数，任务函数的最大处理时间是可以模拟出来的。其实也可以基于freertos开发，个人觉得，没必要，框架搭建好，几个函数来回跑 ，问题也不大。rtos优点是大部分函数都封装好了，搞个消息队列，当个全局管理者，下面的任务时不时上报一下，这样系统就像处于控制之中，操作时注意中断里能使用的，任务里能使用的函数，就好了，至于任务的优先级，一般是中断里面最低的那个里面切换的，还要注意一个概念可受系统控制的中断节点范围，里面是可以用rtos的系统函数的，其他的中断不受系统控制的是不能使用rtos的函数的，当成单片机的裸机开发就好了。
关于区域码：能够修改的有，服务器下发修改，默认值，仅此2种方式。
