Thingsboard中Knob控件RPC调用报Request Timeout问题咨询

这个功能我在ThingsBoard 3.4.2、3.5.1两个社区版版本上都落地过，报Request Timeout全是链路配置不对，按下面顺序排查就能通：

• 设备端逻辑对齐
  不管你用MQTT、CoAP还是HTTP连的温度计，首先要保证设备端正确订阅RPC请求，且在超时窗口内返回响应。以最常用的MQTT协议为例：
  1. 设备必须提前订阅v1/devices/me/rpc/request/+主题，才能收到服务端下发的RPC请求
  2. 收到请求后，解析主题里的requestId，必须在超时时间内往v1/devices/me/rpc/response/{requestId}主题回包，哪怕没有业务返回值，也要回个空结构{}，服务端等不到回包就会直接抛超时错误。
     绝大多数人第一次做都是只处理了下发的数值逻辑，忘了回响应，卡在这里卡很久。
• Knob控件配置核对
  1. 控件动作选「Custom action」-「RPC call to device」，不要选成服务端RPC或者控件自身赋值的动作
  2. 目标设备要选对对应的温度计实体，别误选同资产下其他离线设备
  3. RPC方法名不要带特殊字符、空格，用简单的驼峰命名比如setAlarmTemp即可，参数模板直接绑定Knob输出值，不要套多余JSON层级，参考模板：

  {
    "targetTemp": $value
  }
  

  4. 弱网设备（比如NB-IoT连接的电池供电温度计）直接把动作高级设置里的RPC超时从默认10000ms调到30000ms，默认超时对弱网设备太短。
• 权限配置核对
  仪表盘关联的访问用户/客户角色，必须给对应温度计设备开放RPC_CALL操作权限，只给读权限的话，RPC请求会在权限层被拦截，前端等不到响应最后就会抛超时。
• 前置连通性校验
  不要一开始就绑控件测，先打开温度计的设备详情页，找到「RPC调试」控制台，发个最简单的无参数RPC请求：

  {
    "method": "ping",
    "params": {}
  }
  

  如果调试控制台发请求都超时，说明是设备端连接、订阅逻辑的问题，和控件配置无关；如果调试控制台能正常收到设备回包，那问题一定出在Knob控件的配置上，回去核对目标设备、参数模板即可。

我自己之前踩过的低级坑：Knob绑定的设备组选了全部设备，RPC请求随机发到同组离线的设备上，查了快四十分钟才发现规则配错。

内容的提问来源于stack exchange，提问作者Olsson