Re: BT Mesh Health Server Fault PeriodicPublication#bluetoothmesh #zephyrbluetoothmesh

William Fish


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.