Thingsboard 可视化 -- 按钮rpc和http rpc api接口实现双向rpc控制（tb网关mqtt方式）

Thingsboard网关可以支持多种常见协议，modbus、opc、mqtt等。很多人疑惑，为什么设备端不都用直连，还要用网关，我的理解是网关可以带多个设备，而连接tb核心服务就只有一路mqtt长连接，对资源也是一种节约，而且很多设备上报频率很低，用直连很浪费。我们公司目前使用的设备基本上都是mqtt连tb，这里就存在网关rpc双向通信问题，官网对通过网关双向rpc说的不是很清楚，参考价值不大。

先说下网关通信原理。采集数据，设备端数据 -->采集控制服务--> 第三方mqtt --> tb网关 --> tb核心服务，设备把采集数据发到一个旁路第三方mqtt上，网关会订阅这个旁路mqtt，在通过tb核心服务为网关创建的mqttserver，把数据转发到tb的核心服务上；

仪表板按钮实现rpc控制设备：tb核心服务（仪表板按钮）-->规则引擎 --> 网关 -->  第三方mqtt --> 采集控制服务 --> 设备。

rpc获取设备信息：暂未跑通（可以考虑使用api直接从tb核心服务获取，而不用走网关绕一圈，有跑通的朋友可以给我留言分享下）

server rpc图文说明如下。

先说下通过仪表板按钮 实现 控制设备

1，首先要保证设备在线，通过网关上报心跳遥感等数据正常。

2，应用程序订阅第三方mqtt消息topic

sensor/"deviceName"/request/"method"/"requestid"

这里我订阅的是通配符的topic ： sensor/chazuotest/# ,chazuotest是设备id。

3，配置网关，这里是官方python的，java版本网关也可以用

  "serverSideRpc": [
    {
      "deviceNameFilter": ".*",
      "methodFilter": ".*",
      "requestTopicExpression": "sensor/${deviceName}/request/${methodName}/${requestId}",
      "responseTopicExpression": "sensor/${deviceName}/response/${methodName}/${requestId}",
      "responseTimeout": 10000,
      "valueExpression": "${params}"
    },
    {
      "deviceNameFilter": ".*",
      "methodFilter": ".*",
      "requestTopicExpression": "sensor/${deviceName}/request/${methodName}/${requestId}",
      "valueExpression": "${params}"
    }
  ]

 

4，打开仪表板库创建开关按钮，绑定数据源，在高级中设置控制开关状态的key。以便从设备属性中实时获取，定义好setRpc的方法名。

、

5，创建规则引擎

此刻点击按钮开关，订阅的第三方mqtt将收到消息，实际上是通过网关下发出去的消息，然后我们就可以根据需要定制自己的业务，例如实现真实的开关操作等，再次强调，一定要保证设备在线，发送遥感消息即可，否则点击按钮提示设备不在线（Device is offline.）。

tb做的太灵活了，我们还可以通过http的rpc api控制设备，怎么玩怎么有。

http的rpc api控制设备

先找到http rpc的api  http://192.168.0.119:8080/api/plugins/rpc/oneway/deviceID

此刻是无法rpc下发到网关的应用层的，因为http rpc请求是通过rpc request from device上报上来的，需要在规则引擎做配置，转到rpc call device，我这里判断如果是get方法，就查询属性返回，如果是set方法，转到rpc call device中。

下面是核心的判断

此刻，我们的网关应用层订阅的第三方mqtt收到控制指令，我们就可以做控制设备的操作了。

设备如果掉线，该命令执行后就会报错，提示device is offline，所以要保证设备在线就得不断给tb发设备心跳或者更新属性、遥测。或者修改全局配置

如果想获取设备返回值，可以考虑使用rpc twoway，http://192.168.0.119:8080/api/plugins/rpc/twoway/deviceID，调用后会进入等待，如果设备端执行ok，再给边缘mqtt吐一个消息，api就拿到返回值

inactivity_timeout: "${TB_TRANSPORT_SESSIONS_INACTIVITY_TIMEOUT:120000}" 改一个大点的值，另外，设备服务端属性inactivityTimeout修改后在这里不起作用，感谢广州iot的提示，查阅源码发现rpc订阅的设备离线判断用的是全局变量而非设备服务端属性

 

如果想实现类似物模型的操作，我们可以在规则引擎中根据方法名称或者设备类型判断，定义相关数据结构，实现一个简单的物模式。