zephyr/include/bluetooth/mesh/health_srv.h

91 lines
2.5 KiB
C
Raw Normal View History

/** @file
* @brief Bluetooth Mesh Health Server Model APIs.
*/
/*
* Copyright (c) 2017 Intel Corporation
*
* SPDX-License-Identifier: Apache-2.0
*/
#ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_
#define ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_
/**
* @brief Bluetooth Mesh Health Server Model
* @defgroup bt_mesh_health_srv Bluetooth Mesh Health Server Model
* @ingroup bt_mesh
* @{
*/
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
struct bt_mesh_health_srv_cb {
/* Fetch current faults */
int (*fault_get_cur)(struct bt_mesh_model *model, u8_t *test_id,
u16_t *company_id, u8_t *faults,
u8_t *fault_count);
/* Fetch registered faults */
int (*fault_get_reg)(struct bt_mesh_model *model, u16_t company_id,
u8_t *test_id, u8_t *faults,
u8_t *fault_count);
/* Clear registered faults */
int (*fault_clear)(struct bt_mesh_model *model, u16_t company_id);
/* Run a specific test */
int (*fault_test)(struct bt_mesh_model *model, u8_t test_id,
u16_t company_id);
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
/* Attention on */
void (*attn_on)(struct bt_mesh_model *model);
/* Attention off */
void (*attn_off)(struct bt_mesh_model *model);
};
/** @def BT_MESH_HEALTH_PUB_DEFINE
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
*
* A helper to define a health publication context
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
*
* @param _name Name given to the publication context variable.
* @param _max_faults Maximum number of faults the element can have.
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
*/
#define BT_MESH_HEALTH_PUB_DEFINE(_name, _max_faults) \
BT_MESH_MODEL_PUB_DEFINE(_name, NULL, (1 + 3 + (_max_faults)))
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
/** Mesh Health Server Model Context */
struct bt_mesh_health_srv {
struct bt_mesh_model *model;
/* Optional callback struct */
const struct bt_mesh_health_srv_cb *cb;
/* Attention Timer state */
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
struct k_delayed_work attn_timer;
};
int bt_mesh_fault_update(struct bt_mesh_elem *elem);
extern const struct bt_mesh_model_op bt_mesh_health_srv_op[];
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
/** @def BT_MESH_MODEL_HEALTH_SRV
*
* Define a new health server model. Note that this API needs to be
* repeated for each element that the application wants to have a
* health server model on. Each instance also needs a unique
* bt_mesh_health_srv and bt_mesh_model_pub context.
*
* @param srv Pointer to a unique struct bt_mesh_health_srv.
* @param pub Pointer to a unique struct bt_mesh_model_pub.
*
* @return New mesh model instance.
*/
#define BT_MESH_MODEL_HEALTH_SRV(srv, pub) \
BT_MESH_MODEL(BT_MESH_MODEL_ID_HEALTH_SRV, \
Bluetooth: Mesh: Fix model publication Model publication was broken in a couple of ways: - The Publish Retransmit State was not taken into account at all - Health Server used a single publish state for all elements To implement Publish Retransmit properly, one has to use a callback to track when the message has been sent. The problem with the transport layer sending APIs was that giving a callback would cause the transport layer to assume that segmentation (with acks) is desired, which is not the case for Model Publication (unless the message itself is too large, of course). Because of this, the message sending context receives a new send_rel ("Send Reliable") boolean member that an app can use to force reliable sending. Another challenge with the Publish Retransmit state is that a buffer is needed for storing the AppKey-encrypted SDU once it has been sent out for the first time.To solve this, a new new net_buf_simple member is added to the model publication context. The separate 'msg' input parameter of the bt_mesh_model_publish() API is removed, since the application is now expected to pre-fill pub->msg instead. To help with the publishing API change, the Health Server model gets a new helper macro for initializing the publishing context with a right-sized publishing message. The API for creating Health Server instances is also redesigned since it was so far using a single model publishing state, which would result in erratic behavior in case of multiple elements with the Health Server Model. Now, the application needs to provide a unique publishing context for each Health Server instance. The changes are heavily intertwined, so it's not easily possible to split them into multiple patches, hence the large(ish) patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-11-18 16:24:18 +08:00
bt_mesh_health_srv_op, pub, srv)
/**
* @}
*/
#endif /* ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_ */