On 3 Apr 2019, at 19.44, William Fish <William.fish@...> wrote:
Thanks, I've had a look but I still need to understand how to register the faults, via application. Any hint would be appreciated.That depends on your application and the source of the faults. All the stack requires is for you to keep track of the fault history. You could do that e.g. with a simple u8_t array like the mesh shell does.
In the case of the mesh shell it has arrays for current and registered faults, with the assumption that there can be up to CUR_FAULTS_MAX different faults. There are also fault-add and fault-del commands to artificially introduce faults (the shell is a testing program - for a real device you’d have the faults coming from some real source). Take a look at how the command handlers for add-fault and del-fault behave, i.e. the cmd_add_fault() and cmd_del_fault() functions. Any time a fault appears or goes away you’re expected to call the bt_mesh_fault_update() API so that the right message gets sent out to the network (if the node is configured to do publication through its health server).
The difference between the two types fault arrays (if it’s unclear from the mesh spec): registered faults is the history of faults that your device has experienced at some point in its history, whereas current faults is the set of faults that is currently experiencing. That’s why the add-fault shell command adds to both arrays but the del-fault only removes from the current faults array.