Re: BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

William Fish

I have looked into the health_svr.h  and found that the “helper” does not have an update callback. Maybe in might be worth adding to allow periodic updates. I will change my app to use the generic define rather than the “helper”




*  A helper to define a health publication context


*  @param _name Name given to the publication context variable.

*  @param _max_faults Maximum number of faults the element can have.


#define BT_MESH_HEALTH_PUB_DEFINE(_name, _max_faults) \

    BT_MESH_MODEL_PUB_DEFINE(_name, NULL, (1 + 3 + (_max_faults)))



From: William Fish
Sent: 09 April 2019 12:57
To: Hedberg, Johan
Cc: users@...
Subject: RE: [Zephyr-users] BT Mesh Health Server FaultPeriodicPublication#bluetoothmesh #zephyrbluetoothmesh



Fantastic, thanks.


  1. I am using the  BT_SETTINGS and calling settings_load(). I use this as a short cut for development purposes.
  2. The Update callback well spotted many thanks.
  3. The lack of message (pub->msg) creation was why I was so confused


Thanks for the advice/input I’ll get busy fixing these.



From: Hedberg, Johan
Sent: 09 April 2019 12:48
To: William Fish
Cc: users@...
Subject: Re: [Zephyr-users] BT Mesh Health Server Fault PeriodicPublication#bluetoothmesh #zephyrbluetoothmesh


Hi Billy,


(added zephyr-users back to CC - please don’t drop it since others may benefit from this information as well)


On 9 Apr 2019, at 14.28, William Fish <> wrote:

>     /* Health SVR: publish periodicaly to a remote address */

>     struct bt_mesh_cfg_mod_pub health_svr_pub = {

>         .addr = GROUP_ADDR, /*GROUP_ADDR or Node addr */

>         .app_idx = app_idx,

>         .ttl = 0x07,

>         .period = HEALTH_SVR_UPDATE_PERIOD,

>         .transmit=BT_MESH_TRANSMIT(1, 20),

>     };


There are a many problems with the above:


1. The model publication is expected to be configured by a configuration client - not statically like this. If everything else is initialised correctly (it’s not - see my other points) it *might* work if you’re also using BT_SETTINGS and calling settings_load() from your application, but I’ve never tested it.


2. You’re missing an update callback. This is mandatory for periodic publication.


3. You’re missing a pub->msg where the publication message is expected to be encoded by your app.


The two last issues will likely cause unexpected behaviour and faults. If you had asserts enabled than issue 2 should trigger an assert (see access.c line 216).


In general, it’s recommended to use the BT_MESH_MODEL_PUB_DEFINE() macro for defining the publication context.







Join to automatically receive all group messages.