OpenThread_app
Loading...
Searching...
No Matches

High‑level OpenThread RGB light device implementation. More...

Topics

 Light Device Control
 Low‑level RGB light control for WS2812B LEDs.
 Light Device URIs
 CoAP URI definitions for the light device.

Functions

void ad_light_init (char *deviceNameGroup)
 Initialize the RGB light device and register it in the framework.

Detailed Description

High‑level OpenThread RGB light device implementation.

Overview

The Light Device module turns the OpenThread Application Framework driver (main API for OpenThread hardware application) into a concrete RGB light node.

Responsibilities:

  • Owns the device name group used for pairing (room / zone identifier).
  • Configures the driver instance with:
    • Light device type (OTAPP_LIGHTING family),
    • Pairing rules (which remote devices are allowed),
    • Observer callbacks for paired devices and subscribed URIs,
    • URI list and URI count for this device.
  • Initializes the URI layer (Light Device URIs) and hardware layer (Light Device Control).
  • Exposes a main task function (in ad_light.c) that is called from ot_app_drv_task() to process device‑specific logic.

Typical lifecycle:

  • ad_light_init() is called once from app_main() with a device name group string (for example "kitchen" or "device1").
  • The function obtains the singleton driver, initializes NVS and URIs, and registers callbacks.
  • The application main loop periodically calls ot_app_drv_task(), which in turn calls the light device task.

Integration points:

Version
0.1
Date
06-09-2025
Author
Jan Łukaszewicz (plhar.nosp@m.eo@g.nosp@m.mail..nosp@m.com)

Function Documentation

◆ ad_light_init()

void ad_light_init ( char * deviceNameGroup)

Initialize the RGB light device and register it in the framework.

This function performs all one‑time initialization required to run the light device as an OpenThread application node:

  • Validates and stores the deviceNameGroup string in an internal buffer. This string defines the device name group used for pairing and must match the group used by controller devices that are allowed to control this light.
  • Obtains the singleton driver instance via ot_app_drv_getInstance().
  • Ensures that the NVS subsystem is initialized by calling drv->api.nvs.init(). Without this step, pairing data and other persistent state cannot be stored.
  • Initializes the light URI table by calling ad_light_uri_init(), then assigns:
    • drv->uriGetList_clb – returns the URI list,
    • drv->uriGetListSize – returns the URI count.
  • Configures pairing behavior by setting drv->pairRuleGetList_clb to one of the light‑specific rule providers (all allowed / blocked / filtered).
  • Registers observer callbacks:
    • drv->obs_pairedDevice_clb – called when a new device is paired,
    • drv->obs_subscribedUri_clb – called when a subscribed URI changes.
  • Sets:
    • drv->deviceName to point to the internal name‑group buffer,
    • drv->deviceType to the constant light device type,
    • drv->task to the light main task function.
Parameters
deviceNameGroupPointer to a null‑terminated string containing the device name group identifier (max 9 characters).
Note
Must be called exactly once before the main loop starts.
Pointer deviceNameGroup must not be NULL.
The same group string must be used on controller devices to allow automatic pairing with this light.