电子发烧友App
上一章节介绍，实现了串口与MQTT服务器间的数据透明传输，本章节将在原有的基础上，增加 LED 控制业务，以此为例来介绍如何在透传数据流中增加必要的扩展业务。
简介
常见的串口服务器产品，在实现了数据透传业务的同时，会根据不同的应用场景扩展一些额外的辅助业务，如DI/DO、ADC采集等。
通过EsDA MPC-ZC1应用——串口服务器（一）章节，完成了串口MQTT服务器的核心业务，实现了串口与MQTT服务器间的数据透明传输。 根据项目需求，本章节将在原有的基础上，增加 LED 控制业务。以此为例来介绍如何在透传数据流中增加必要的扩展业务。
业务扩展
一、数据解析 增加系统控制业务，需要在流图中，对数据流进行数据解析，解析出系统所支持的控制命令和参数。
1. 命令格式
扩展控制命令前，先制定出命令格式，本示例以较为简易的方式实现了命令和参数的组合，如下所示。 [command]@[parameter] 以 @ 作为分隔符， 组合命令（command） 和 参数（parameter），均为字符串类型。 2. 节点介绍 实现自定义的数据解析功能，通常需要开发符合需求的节点，或是直接通过脚本节点来实现。当功能比较简单的时，建议直接使用脚本节点（fscript）来实现。 2.1 fscript fscript 节点，支持用户自定义编辑一段可执行脚本，可以很灵活的完成一些简单的定制化业务。 *关于 fscript 脚本教学可参考《FScript 脚本引擎》：
https://awtk.zlg.cn/pro/docs/awtk_docs/FScript/fscript.html
2.11 属性
名称（name）： 节点名称，用于索引查找本节点；
显示名称（displayName）： 用于画布上显示的名称；
加载时（Initialize）： 节点加载时运行的脚本；
运行时（Function）： 节点每次运行时的脚本；
销毁时（Finalize）： 节点销毁时运行的脚。
fscript 节点支持输入3段脚本，分别在节点加载、运行、销毁时进行调用，其中加载、销毁阶段的脚本仅被调用一次。
2.2 log
log 节点可以将数据流中的数据打印到调试接口上，方便用户观察数据流中的数据。 2.2.1 属性
名称（name）： 节点名称，用于索引查找本节点；
显示名称（displayName）： 用于画布上显示的名称；
控制台（log_to_console）： 输出到系统控制台；
客户端（log_to_client）： 输出到AWFlow Designer客户端。
2.2.2 输入
payload： 需要打印的数据；
payloadLength： 数据长度，uint32_t类型；
payloadType： 指示payload的数据类型。
3. 流图实践
3.1 添加 log 节点 在原有的串口MQTT透传流图上，并入log节点，观察串口上报至MQTT服务的数据。 
3.2 下载并在线运行
选择下载流图，并保持在线运行，这样可以通过AWFlow Designer 客户端接收到 log 节点的消息。
通过串口助手，发送数据。
可以通过 AWFlow Designer 的调试窗口观察到串口发送的数据。
3.3 添加命令解析脚本
在 log 和 串口输入数据流中，添加 fscript 节点。 
仅在 Function 阶段输入命令解析脚本。 
脚本先将输入的数据 msg.payload 转换成字符串类型，再通过 one_of 函数，以 @ 分隔符，将字串分隔成2段，并分别赋值给 msg 的 cmd 和 arg 属性。
/* MQTT和串口节点输出为pointer类型，转换为string */
rbuf = rbuffer_create(msg.payload, msg.payloadLength)
s_payload = rbuffer_read_string(rbuf)
/* 以 @ 分隔符，获取第一段字符串作为命令 */
msg.cmd = one_of(s_payload, 0, "@")
/* 以 @ 分隔符，获取第二段字符串作为参数 */
msg.arg = one_of(s_payload, 1, "@")
至此，实现了从字符串中解析出命令和参数的功能。
二、系统控制
系统控制模块，负责响应解析模块解析出来的命令，根据获得的命令和参数，执行响应的业务。 本小节，以LED控制作为系统控制业务，实际应用可根据项目需求进行扩展。 *本小节主要使用 fscript 来完成 LED 的控制业务，LED 节点的使用可参考 EsDA MPC-ZC1入门（二）—— LED控制。
1. LED控制业务
1.1 添加控制脚本 在数据解析脚本节点与log节点之间，并入一个新的 fscript 节点，用于执行LED控制业务。
LED 支持3路LED的控制命令，如下所示：
led_red@on / off，点亮/熄灭红灯；
blue_red@on / off，点亮/熄灭蓝灯；
green_red@on / off，点亮/熄灭绿灯。
通过控制命令 msg.cmd 来指定所需要控制LED设备，msg.arg 转换为LED控制参数。
/* LED 控制命令作为设备名称，如 led_red@on */
output.device_name = msg.cmd
if (msg.arg == "on") {
/* 点亮LED */
output.payload = 1
} else if (msg.arg == "off") {
/* 熄灭LED */
output.payload = 0
} else {
/* 终止数据流 */
aborted = 1
}
1.2 添加LED节点 继控制脚本之后，串接3个LED节点。 
分别绑定了 led_red、led_blue、led_green。 
1.3 下载验证
下载流图。 
通过串口助手，发送控制命令。
可以看到，板载的 LED 已经能够正确响应串口的控制命令。
*注意：控制命令为字符串类型，所以命令需包含字符结束符 '�’。
三、数据分发
系统控制小节中，在完成LED控制的同时，可以观察到，MQTT服务器同样接收到了控制命令，但这并非所期望的效果。
为了解决这个问题，需要实现数据分发功能，对数据进行选择。可以通过 aswitch 节点实现数据流的流向选择。
1. 节点介绍
1.1 aswitch
1.1.1 属性
名称（name）： 节点名称，用于索引查找本节点；
显示名称（displayName）： 用于画布上显示的名称；
检查全部（check_all）： 检查所有条件；
规则表达式（rules）： 数据分发依据的逻辑表达式；
输出数量（outputs）： 数据分发路径数量。
2. 分发规则
2.1 添加 aswitch 节点，并进行如下配置。 
禁止检查所有条件，即当遇到条件满足时，则不继续检查；
输出路径数配置与逻辑条件一致为 4。
msg.cmd == "led_red"
msg.cmd == "led_green"
msg.cmd == "led_blue"
msg.payloadLength > 0
前3个逻辑条件，通过 msg.cmd 进行判断，区分控制命令，如果遇到符合的控制命令，则不会继续匹配，后续的路径则不会被触发。
可以看到，在最后一条规则中，通过 msg.payloadLength 来匹配透传数据。
2.2 接入数据分发节点
将 aswitch 串进数据分析 和 LED控制脚本节点之间，同时将MQTT上报的数据路径修改为 aswitch 的透传数据输出口上，如下所示。 
2.3 下载验证
下载流图。
通过串口助手，分别发送控制命令和透传数据。
可以看到，此时MQTT服务器不会再接收到串口端的系统控制命令。 
至此，完成了数据分发模块。
四、远程控制
前面完成了 数据解析 、系统控制、数据分发 等3大扩展业务模块，但是都是基于串口来实现，是否可以同时支持MQTT远程控制业务呢？
很显然，是可以的，而且通过复用前面的模块，可以很简单的实现远程控制功能。
1. 扩展数据分发条件
利用 msg.topic 属性来判断是否有来源于MQTT服务器的透传数据，将数据分发数量扩充到 5。
2. 调整MQTT下发数据流
将MQTT下发的数据接入到 数据解析 模块，同时将串口输出连接到数据分发的MQTT透传输出口上，如下所示进行调整。
3. 下载验证
下载流图。
通过MQTTX，分别发布LED控制命令和透传数据。
可以看到，板载的 LED 已经能够正确响应串口的控制命令。
同时串口端，仅收到透传数据。
至此，完成了远程控制功能。
五、整理流图 至此，完成了EsDA MPC-ZC1应用——串口服务器（一） 计划的所有需求。后续根据实际需求，在现有的流图基础上，继续扩展更多的控制命令能，将会十分简单。 将流图进行整理，最终效果如下。 
工商网监
评论