赞
踩
本文主要实现基于 thingsboard+NodeRed+chirpstack 实现 lora设备的数据上下行通讯。
NodeRed作为mqtt桥接器,在开源的社区版 thingsboard上实现
Ø 【chirpstack中的mqtt消息】
以上信息重点关注框出的箭头指向的字段。我们需要将 object 字段下有物理含义的三个值发送给thingsboard 进行数据分析,其余的重要信息都是用于区分设备的信息,devEUI是设备的ID号,用于区分设备,其余字段用于进行设备管理。
Ø 【NodeRed中进行数据处理】
NodeRed
接收chirpstack
的mqtt消息,利用JSON解析脚本将数据完全还原出来,如下图:
我们将解析后的数据通过nodered 的mqtt out 控件将数据发送至thingsboard,在nodered
中顺便将thingsboard
需要的telemetry
和 attribute
作了组合,分别利用两个主题对数据发送:
msg.topic = "v1/devices/me/attributes"
;
msg.topic ="v1/devices/me/telemetry"
;
方案说明:
Thingsboard 端控制下行设备,利用 attribute update的方式,数据经过thingsboard中配置的规则链数据解析,解析为chripstack 需要的数据格式,然后发给chirpstack的mqtt端,完成设备的控制。
【通讯实例】
场景:通过客户端给chirpstack发送mqtt消息,从而实现对设备的控制。
实现:客户端连接chirpstack的mqtt broker之后发送的消息至少包含以下信息
描述:通过thingsboard更新relaySwitch 属性,完成数据的下发
Ø Mqtt_Topic
: application/11/device/88000111000200aa/command/down
n 11 :消息中的 applicatiID字段,是chirpstack应用分组号
n 88000111000200aa
:为消息中的devEUI字段,设备ID号,用于唯一区分设备节点
Ø Mqtt_message
: Json数据格式,且至少包含信息为,其中
{
"fPort": 2,
"object": {
"relaySwitch": 10
}
}
每一类lora产品:
对应在chirpstack服务器中有一个单独的 application 号
在tb中有一个专门的规则链配置
【思路分析】
对于灯控设备来说,在thingsboard一端只需要解析有物理含义的属性,如本灯控模块的雷达值、继电器状态、温度值。但是为了在thingsboard端进行更好的设备管理,除了这几个值以外,还将上传节点设备的其他信息,如 applicationID devEUI deviceName fPort等几个字段,含义分别如下:
Ø applicationID
:chirpstack
中的 application
分组的ID号,同一类产品在chirpstack中分为一组,有共同的ID号
Ø devEUI
:节点设备的ID号,在chirpstack中用于唯一区分设备。
Ø fPort
:LoRa发送数据的端口,这个值比较重要
Ø deviceName
:节点名称,该值为在chirpstack
中创建设备的设备命名
【规则链解释】
Ø 上行消息,post attribute
分别 post 至 客户属性 和 共享属性(原因见说明1)
Ø 下行消息,需要将 devEUI
和 fPort
这两个字段值,更新的设备属性值发送给chirpstack
上行通信的数据没什么可以解释的,数据从nodeRed解析出来之后,分别将不同的字段组合为 attribute
和telemery
发送至thingsboard
如图,利用这个控件将以上四个字段添加到元数据(*Metadata*)中。
因此就要求设备的客户端属性 client attribute
中包含以上几个字段。所以数据上行通信时,需要将以上几个字段作为 attribute
保存起来。
所以在创建设备时,要添加关联:
可以管理设备自己,也可以将所有的灯控模块利用 asset,组合为一个 assset Profile,添加关联的时候可添加asset。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。