2017-11-12 19:33:26 +08:00
|
|
|
/** @file
|
|
|
|
* @brief Bluetooth Mesh Health Server Model APIs.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright (c) 2017 Intel Corporation
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
|
|
*/
|
2018-09-15 01:43:44 +08:00
|
|
|
#ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_
|
|
|
|
#define ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_
|
2017-11-12 19:33:26 +08:00
|
|
|
|
|
|
|
/**
|
2017-11-15 06:15:13 +08:00
|
|
|
* @brief Bluetooth Mesh Health Server Model
|
|
|
|
* @defgroup bt_mesh_health_srv Bluetooth Mesh Health Server Model
|
2017-11-12 19:33:26 +08:00
|
|
|
* @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 {
|
2017-11-12 19:33:26 +08:00
|
|
|
/* 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);
|
|
|
|
};
|
|
|
|
|
2018-02-10 16:32:58 +08:00
|
|
|
/** @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
|
|
|
*
|
2018-02-10 16:32:58 +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
|
|
|
*
|
2018-02-10 16:32:58 +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
|
|
|
*/
|
2018-02-10 16:32:58 +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;
|
|
|
|
|
2017-11-12 19:33:26 +08:00
|
|
|
/* 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;
|
2017-11-12 19:33:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
int bt_mesh_fault_update(struct bt_mesh_elem *elem);
|
|
|
|
|
2017-11-14 03:38:52 +08:00
|
|
|
extern const struct bt_mesh_model_op bt_mesh_health_srv_op[];
|
2017-11-12 19:33:26 +08:00
|
|
|
|
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) \
|
2017-11-12 19:33:26 +08:00
|
|
|
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)
|
2017-11-12 19:33:26 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @}
|
|
|
|
*/
|
|
|
|
|
2018-09-15 01:43:44 +08:00
|
|
|
#endif /* ZEPHYR_INCLUDE_BLUETOOTH_MESH_HEALTH_SRV_H_ */
|