资料里提到:节点会定时发出「心跳」讯息,每一次的心跳讯息,都是告知网络内的其他节点,自己仍然在正常运作。
这个心跳详细是怎么实现的?
BLE mesh的内部心跳机制是如何实现的?是通过health model吗?
首先要清楚心跳消息是一种控制消息类型(control message),而不是访问消息类型(access message),它在两个节点之间上层传输层之间传输,为了能够让两个节点之间发送心跳消息,必须首先对每个节点的心跳状态进行配置,共有6个相关消息,在配置模块客户端和服务器之间通信,完成节点的心跳状态的配置
Config Heartbeat Publication Set
Config Heartbeat Publication Get
Config Heartbeat Publication Status
Config Heartbeat Subscription Set
Config Heartbeat Subscription Get
Config Heartbeat Subscription Status
重点就是,当配置好节点的心态状态之后,心跳消息就在两个节点的上层传输层之间传输,自动的接收和发送心跳消息
不需要应用程序参与,应用程序可以访问心跳的状态获得有用的信息
心跳消息设计的目的之一是让订阅心跳信息的节点知道你离我有多远(hop)
心跳消息中的有效字段
心跳消息包含心跳消息的初始TTL和节点的功能标志位feature
1 订阅节点获得心跳消息后可以根据初始TTL的值计算hop(跳数),在整个消息的订阅时间内
可以获得最大的hop和最小的hop,让订阅节点分析通讯的可靠性,并选择 最佳的发布TTL
2 当节点的relay,proxy,friend,lpn功能因为配置而改变的时候,它会通知监听 的模块,则节点的功能改变的信息
可以通过心跳消息发布出去
总之 ,为什么mesh网络需要心跳?
在mesh1.0中设计心跳机制的本质需求是,当一个网络开始工作了,我们想知道网络中 节点之间传输消息的可靠性
和它们之间的跳数,或整个网络节点构成拓扑,用来优化TTL值,减少网络消息的拥堵
这个功能,就是通过心跳消息完成的
- 已编辑
jxingl 感谢回复,对于心跳,我这边主要是检测,网内的节点是否离线(比如超出蓝牙连接范围),如果某个节点离线了,有一个专门节点需要获取到此信息并记录。对跳数和监测距离暂时没有要求。那我的这种需求是不是不适用内部的心跳机制?
你的这个需求是适合用心跳机制的,你配置被监视的节点周期性发出心跳消息,监视节点配置为订阅这个心跳消息,这样,监视节点通过对心跳消息在一个时间段内的计数分析就就知道被监视的节点是不是离线了,正常情况下,监视节点应该以一定的速率接收到心跳消息,心跳计数/单位时间,如果这个值不对了
就说明节点没有收到心跳消息 ,可能就是离线了
health model 主要是监视节点自身是不是出现故障了,如果出现故障,向指定的节点报告故障状态
jxingl
(1)监视节点配置为订阅这个心跳消息
监视的节点如何订阅这个消息呢?通过APP里的health model吗?
通过foundation model配置
jxingl
您说的是App这里的基础模型吗?
是的
jxingl 具体要点开什么,选择什么呢?不太理解
chenluhui2019 你点进去Model里不是有个Subscribe address和 Public Adress,分别填充你要订阅的地址和发布的地址即可
他问的是心跳发布状态和订阅状态的设置,可能手机上的基础模型客户端还没有实现这个功能,我看了下
nordic提供的app,就没有实现,实现的是模型的发布和订阅状态的配置
所以,节点的心跳状态的配置,目前nordic还没有实现,看看哪家实现了,就用他们的去试试
jxingl 真大佬
Wireless-Tech jxingl
我这边对health model做了如下订阅发布操作,但是没有看到UART LOG周期性的打印跟心跳有关的信息
心跳机制跟health model 没有半毛钱关系
jxingl 那?能具体一点吗?
去看下Bluetooth mesh1.0吧
jxingl mesh profile我有看,但是具体在开发中。如果用app作为provisioner,目前是否可以实现心跳?
你用的哪家的APP?还是你们自己设计的APP?如果你们自己设计的要问下相关的开发人员是不是怎么配置心跳状态?如果不是你们编写的APP,你问下,你们的SOC供应商,他们的APP是不是支持心跳状态配置功能?前面不是也提到这一点了吗
jxingl 我们自己基于Nordic的app开发的,我们IC的FAE关于provisioner使用的是一块dongle接电脑当上位机