samples: matter: Unification of events, buttons and LEDs

[ArekBalysNordic]

This commit unifies events, buttons and LEDs for all Matter samples.

Changelog in this commit:

• Separated Events to the system-specific and application-specific.
• Created EventManager module which is responsible for posting and dispatching events.
• Created the common board configuration file (board_config.h) that contains all board definitions, which can be overwritten in the app_config.h file in the sample directory.
• Created the common board_const.h file that contains all constant definitions of timeouts and LED blinking intervals. Those definitions are the same for all samples and boards.
• Created the BoardInterface module in board_interface.c/.h files. The BoardInterface module:
  • Initializes LEDs and buttons on the DK, taking into account the number of LEDs and buttons on the DK.
  • Manages LEDs and buttons operations.
  • Manages Matter Identify service.
  • Manages to start Bluetooth LE Advertising using a button.
  • Exposes a button callback which can be used in the Application code. Users have 3 or 1 available buttons and LEDs depending on the availability on the DK.
  • Manages the factory reset service.
• Aligned Matter Lock sample to all changes.
  • Aligned Lock operations after clicking the button.
  • Aligned WiFi-Thread switching.
• Limitations:
  • Events cannot be called directly from the Timer timeout event context.

[markaj-nordic]

Suggested change

	BoardInterface() {}
	BoardInterface() = default;

or no explicit constructor at all I guess.

[markaj-nordic]

Do we actually need a static instance? It is only used internally in the class implementation, right? Is it only because some methods need to be static?

[ArekBalysNordic]

It is because we can use that static instance outside the class implementation, for example in AppTask to get LEDs,

[markaj-nordic]

Isn't it that in the current solution, the context must be exactly of AppEvent type?

[Damian-Nordic]

I wonder... is using the current Event structure that useful at all? It basically carries the handler function pointer and some extra context, but the event type is what makes the solution not generic enough and requires unsafe void* casts. What if we did something completely different like:

using Task = std::function<void()>;

class AppTaskExecutor
{
public:
    void PostTask(const Task& task) { /* add task to the queue */ }
    void DispatchNextTask() { auto task = /* dequeue task */; task(); }
    
    static AppTaskExecutor& Instance();
};

class CommonButtonModule
{
    void SomeDkButtonsAndLedCallback()
    {
        if (/* button 1 pressed */) {
            AppTaskExecutor::Instance().PostTask([this] { FactoryReset(); })
        }
    }

    void FactoryReset()
    {
        LOG_INF("Triggerring factory reset");
        Server::Instance().ScheduleFactoryReset();
    }
};

We could use Matter's LambdaBridge instead of std::function to keep it more lightweight. But the idea is to use lambdas instead of semi-polymorphic event type and unsafe casting to void*.

I haven't thought it through very much so just throwing an idea for now, but we can have a meeting and brainstorm on that if you believe it could simplify things.

[Damian-Nordic]

Note that DK buttons and LEDs module supports registering multiple handlers via https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/others/dk_buttons_and_leds.html#c.dk_button_handler_add, so an application could just register an extra handler to take care of app-specific buttons.

[ArekBalysNordic]

I wonder... is using the current Event structure that useful at all? It basically carries the handler function pointer and some extra context, but the event type is what makes the solution not generic enough and requires unsafe void* casts. What if we did something completely different like:

using Task = std::function<void()>;

class AppTaskExecutor
{
public:
    void PostTask(const Task& task) { /* add task to the queue */ }
    void DispatchNextTask() { auto task = /* dequeue task */; task(); }
    
    static AppTaskExecutor& Instance();
};

class CommonButtonModule
{
    void SomeDkButtonsAndLedCallback()
    {
        if (/* button 1 pressed */) {
            AppTaskExecutor::Instance().PostTask([this] { FactoryReset(); })
        }
    }

    void FactoryReset()
    {
        LOG_INF("Triggerring factory reset");
        Server::Instance().ScheduleFactoryReset();
    }
};

We could use Matter's LambdaBridge instead of std::function to keep it more lightweight. But the idea is to use lambdas instead of semi-polymorphic event type and unsafe casting to void*.

I haven't thought it through very much so just throwing an idea for now, but we can have a meeting and brainstorm on that if you believe it could simplify things.

It looks great, and is so simple... :) I will try to add it to the code and then we can discuss it as you mentioned.

[ArekBalysNordic]

I've refactored the event management system as Damian suggested and now it looks much better! Please take a look @kkasperczyk-no @markaj-nordic @Damian-Nordic. It requires fewer lines of code and is much less unsafe now. Thanks @Damian-Nordic!

The next step is to consider LambdaBridge, but @markaj-nordic do we want the Matter core code there? What do you think?

[ArekBalysNordic]

I've addressed part of the @markaj-nordic comments, but not all yet.