Separating code concerns for bluetooth mesh models

Hi,

I'm wondering if I'm missing something. I've been creating a bluetooth mesh light with hue, saturation, brightness, on/off, etc. models. However, my model_handler.c file is becoming huge!! I've based it on the nrf examples here, but since

static void led_set(struct bt_mesh_onoff_srv *srv, struct bt_mesh_msg_ctx *ctx,
		    const struct bt_mesh_onoff_set *set,
		    struct bt_mesh_onoff_status *rsp)
{
	struct led_ctx *led = CONTAINER_OF(srv, struct led_ctx, srv);
	int led_idx = led - &led_ctx[0];

....

the setters and getters depend on the led_ctx, and the led_ctx is a composition of the handlers (which contain the setters and getters), I can't seem to move anything out of this one file! Ideally, I'd move all the onoff logic into one file, the hue logic into another file, the context into another file, and the model_handling simply composes these. Am I missing the way to do this with macros I don't know about?

Thanks!

  • Hi, 

    struct led_ctx is specific to this sample, created for convenience, and does not require the use of Mesh APIs at all. If it doesn't fit your use case, you'll have to replace it with something else you wrote to fit your use case. The sample is, as the word suggests, a sample, not meant to be a drop-in application.

    The only thing you are required to do to accomplish "a Bluetooth mesh light with hue, saturation, brightness, on/off, etc.", is to have implementations for the relevant handler functions for the Hue Server, Saturation Server and Lightness Server, and then pass these handlers to BT_MESH_LIGHTNESS_SRV_INIT and BT_MESH_LIGHT_HSL_SRV_INIT. What these handlers do is completely up to the application author, and depends on the specific use-case. In this case, where they would like to handle hue logic in one file, onoff in another, etc., and don't like to have a huge model_handler.c, I'd suggest to keep the handler implementations in model_handler.c short, just containing calls to application-specific functions in other files exposed in application-specific headers.

    Regards,
    Amanda H.

  • Thanks a lot  , I'll give it a go and report back if there are any road blocks!

Related