<< 点击显示目录 >> 主页  MQTT使用助手 > 20_贝加莱AR作为订阅者与发布者 > 22_基于paho.mqtt.c的客户端 > 40_使用注意事项

 

•使用之前请先查看一下相应的功能说明文档，了解一些相应的使用的限制。

 

•使用 IotMqtt 库时如果通过域名去连接 MQTT Server，则控制器上需要去配置  DNS 解析的，否则 IotMqttClient 无法连接成功；如果 MQTT Server 支持直接 IP 地址访问，那么就无需配置 DNS ，直接配置 ServerUri 为 IP 地址即可。

 

•TCP 程序调用 IotMqttPublish 功能块 Publish 数据，IotMqttSubscribe 功能块来 Subscribe 数据；测试中遇到过一个偶发 bug，在连续长时间测试 Publish 数据时， IotMqttPublish 功能块的输出 Busy 为 True 导致数据推送异常停止的问题，这个问题只能通过重启控制器才能解决。在 GutHub 上有其它同事也遇到过同样的问题，开发人员还在分析查找问题中。

 

•RegParPub 程序则调用 IotMqttRegParPublish 功能块 Publish 数据，IotMqttRegParSubscribe 功能块来 Subscribe 数据，测试都可以正常 Publish 和 Subscribe 数据，测试中没有遇到问题。 IotMqttRegParPublish 是在 IotMqttPublish 基础上再进行封装的，和 IotMqttPublish 功能块相比会少一些输出变量，可能在一些情况下不是很方便。

 

•IotMqtt 库 ver05 虽然没有对 AR 版本有严格依赖，推荐尽量和库生成时的 AR 版本接近。相应的生成的 AR 版本有 A4.73 Intel / ARM、C4.63 Intel / ARM5、D4.53 Intel / ARM、N4.34 Intel / ARM、M4.26 Intel 和 H3.10 Intel 。

 

• 使用 IotMqtt 库，注意在同一个 IotMqttClient 实例下， 调用的  IotMqttPublish 、IotMqttSubscribe 或者   IotMqttRegParPublish、IotMqttRegParSubscribe 的总个数不能超过 50 个，这个是文档里面列出的。如需要调用更多的功能块，可以新增调用  IotMqttClient 实例，注意不同的 IotMqttClient 实例连接的参数 IotMqttParameters.ClientIDClientID 必须是唯一的，不能相同。

 

•经过实际的测试，同一个 IotMqttClient 实例下调用的  IotMqttPublish 、IotMqttSubscribe 或者   IotMqttRegParPublish、IotMqttRegParSubscribe 的总个数是可以超过 50 个，测试过调用了一百多个  IotMqttRegParPublish 实例也可以正常运行；和开发人员沟通的结果是，他认为 IotMqtt 的限制更多的是在订阅功能块上，因为订阅功能需要分配资源来接收和转发传入的流量，所以它目前有一个固定的限制，但具体限制没有明确说明。

 

•推送或者订阅的数据格式要求为 Json 格式时，需要调用 IotMqttRegParPublish 或者 IotMqttRegParSubscribe  功能块。

 

•推送或者订阅的数据应该是全局变量，不能是局部变量。

 

•推送或者订阅数据的 Qos （Quality of Service），消息服务质量，需要根据客户的需求进行不同值的设置。 Qos 不同值的说明如下：

1）Qos=0，"至多一次"，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通A叩的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。

2）Qos=1，至少一次，确保消息到达，但消息重复可能会发生。

3）Qos=2，”只有一次"，确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的A叩的推送，确保用户收到且只会收到一次。

 

•使用 IotMqttRegParPublish 功能块时，PublishMode 有基于时间、触发信号和值变化三种方式组合起来的不同模式可供设置，需要根据实际的客户需求来选择合适的推送模式。下面是对几种常用推送模式的总结：

▪1）time 模式， 为通常选择的模式，居于内部固定的时间进行数据的推送；根据当前 Qos 的设置 和 SendTimeout 设置，超时没有推送完成，则 IotMqttRegParPublish 会报错 -10015。

▪2）trigger 模式， 适用于对推送时间要求更快的场合；注意触发的 Trigger 管脚是需要有上升沿变化时才生效，程序里面需要注意在 IotMqttRegParPublish 执行后对  Trigger 信号进行相应的复位，否则会导致下一次数据无法推送的情况发生；另外就是选择 trigger 模式，需要同时把 Update 输入一起配合使用，Update 和 Trigger 一样同时去设置使能和复位。

▪3）value 模式， 适用于变化缓慢或者基本不太变化的数据的推送，避免无效的数据推送，节约传输带宽。value 模式是只有判断需要推送的变量或者结构体里面至少有一个成员值发送变化时，才会执行一次推送；值不变化是不执行推送的。

▪4）另外的推送模式是上面 time、trigge 和 value 三种模式的两两组合的其它模式，参照上面三种模式的说明来合理设置。

 

•使用 IotMqttRegParSubscribe 功能块，需要注意以下几点：

▪1）IotMqttRegParSubscribe 功能块的 QueueSize， 定义订阅数据的缓存队列的大小，测试下来该值最大为 255。

▪2）IotMqttRegParSubscribe 功能块的 ReceiveBufferSize，定义每一条订阅的数据的长度，需要注意实际订阅的数据是否会超过，超过是相应要调整。