振南技术干货集：制冷设备大型IoT监测项目研发纪实（3）

注解目录

1.制冷设备的监测迫在眉睫

1.1 冷食的利润贡献

1.2 冷设监测系统的困难

（制冷设备对于便利店为何如何重要？了解一下你所不知道的便利店和新零售行业。关

于电力线载波通信的论战。）

2、电路设计

2.1 防护电路

2.1.1 强电防护

2.1.2 弱电防护

（浪涌、脉冲群、静电、过压、雷击，你的电路扛得住吗？加些防护吧。）

2.2 电路复用（电路设计，仔细思考一下，不要作重复劳动。）

3、协议设计

3.1 内外机通信协议

（电力线通信环境是复杂而恶劣的。振南设计的时分复用与冗余编码协议，了解一下。）

3.2 主机与 WIFI Agent 通信协议

（乐鑫 ESP8266 连接 WIFI，数据上私有云。Json 了解一下。）

4、自动化生产与测试

4.1 自动化烧录

4.2 自动化测试

（芯片预处理、自动化烧录和测试，半个月生产 9000 套硬件，看看我是如何作到的。）

5、工程测试与安装

5.1 工程测试（手机蓝牙远程调试）

5.2 工程安装

（看我们上天入地安装设备。蓝牙调试，几十米外无线烧录，一部手机全搞定。）

6、冷设监测数据分析

（开放一些内部数据，看看实际效果。）

7、冷设监测故障预判作用评估

7.1 故障预判时效

7.2 对维修保养的验收指导作用

7.3 故障报警受气温的影响

（努力没有白费，省下的是实实在在的真金白银。）

8、冷设预警的典型案例

1）申虹路某店

2）恒通商务园某店

（这里有 ABC IOT 系统的内部监测数据，一切的努力都归结于这些曲线上。）

3

协议设计

3.1 内外机通信协议

先说一下电力线载波通信机制背景:

电力线载波通信硬件层面没有主从与寻址过滤机制,某一个节点发送数据，同一电力线网络下(同相,无变压器隔离),所有其他节点均可接收到数据(排除电力线干扰的理想情况下)如图 8.16 所示。

图 8.16 一个内机 +N 个外机的电力载波通信模型

即电力线载波通信仅工作在广播通信方式。

电力线载波通信的特点:带宽较小，即每次传输数据量较小;干扰大,可能导致数据通信失败率较高。

制定协议的原则:

(1)防止外机与内机通信时对电力线的争抢,即实现有序的无冲突的通信;

(2)外机与内机自 身通信故障 诊断,以便从通信故障中恢复;

(3) 容忍恶劣的干扰因素，保障最大限度数据传输;

(4)在有限的数据带宽下,尽量多的传输更多信息。

内外机之间的通信采用电力线载波通信,经过多次的筛选测试,最终振南选定了 ZBKJ的模块,如图 8.17 所示。

图 8.17 ZBKJ 的电力载波通信模块

这是一家实力蛮强的公司,模块上所使用的芯片是他们自主研发的,如图 8.18 所示

主机(内机)请求帧如下:

图 8.18 ZBKJ 自主研发的电力载波通信芯片

电力载波模块每次发送接收固定 20 字节数据,不足部分补 0。

请求帧为了防止数据丢失,采用重复编码,即 10 个 AA55BB66,从机只要接收到至少1个AA55BB66 则认为接收到请求。

外机回传数据帧:

外机回传一次数据长度固定为 40 字节,即两次电力线通信。采用 4 字节反码配对编码共可传输 10 组信息。

4 字节前 2 字节与后 2 字节可反码配对,则说明此组数据有效,进而进行解析。

这种方式在传输过程中就算有个别字节丢失,它也能最大限度的解析到足够的信息。

我们不光关心外机回传的采样数据,同时我们也很关心外机自身工作是否正常,所以我们继续做出了如下定义:

4 字节反码配对编码数据还可以表达更丰富的信息:

一共是 40 个字节,就可以将从机(外机)的采集数据、电路诊断信息、固件版本以及人机监控属性描述清楚了,而且任何字节的丢失并不影响其他数据的解析。

有人可能会问一个问题。“我看这套系统是采用主机主动广播请求。从机来回复的方式工作,如何解决数据在电力线上碰撞的问题?”其实,这个问题就如同 RS485 总线的广播一样,从机接收到广播请求帧之后,并不能立即将数据进行回应。振南的做法是各自延时各自的ID值后再回应,如图 8.19 所示。

图 8.19 内机一次广播请求各从机延时发送回应

这样,主机(内机)在广播请求之后,等待约 10s,即可接收到来自各从机(外机)的数据了。

3.2主机与WiFi Agent 通信协议

主机获取到各个从机的数据并解析之后,最终需要将结果上传到云平台,以便进行进一步的展示或数据分析,在这套系统中主机通过 WiFi Agent 实现数据上传。WiFi Agent 是基于乐鑫ESP8266 进行单独开发的，这个由专门的嵌人式工程师来负责(它一方面对 8266 的开发方法比较了解,另一方面对 ABC IOT 云平台的数据接人也比较有经验),基本的示意如图 8.20 所示。

图 8.20 主机接收从机数据解析后通过 WiFi Agent 上传平台

所以这就涉及主机与 WiFi Agent 之间的协议设计,通过与开发人员商议,最终确定使用json 来进行传输。

json 来对数据进行编码,我们来举个例子:

json 实质上是一个字符串,其中包含了各分机的采集、诊断等信息,同时还有主机的相关信息，比如主机所在店的店号,这样将更加方便管理。主机将其通过串口发送给 WiFi Agent，然后它再将其处理为它与云平台之间的格式,进而上传。