OpenThread CLI support on Sleepy End Devices

[Nikhil Komalan]

Hello,

I would like to know is openthread CLI available on Sleepy End Devices. Because currently i was using nRF5 SDK for Thread and in there mqttsn sleepy example openthread cli port isn't initialized. So i would like to have some idea about that, is it possible or not ?

Also what are the techniques of commissioning SED, if CLI is not available than i only have option of scanning QR code keeping thread device in joiner state initially in code.

[Abtin Keshavarzian]

Short answer is yes, CLI can be enabled/used on FTD or MTD builds.

OpenThread is a networking library which provides public APIs and then need to be linked  with an app layer code (using the APIs to control the network) along with a platform layer code to form the device firmware. The CLI is an example app layer code which is provided in OpenThread repo and can be integrated into a product firmware. Whether/how it is integrated and is used is up to app layer code (project/products integrator).

How the device performs commissioning is again up to app layer code and what UX flow makes sense for the device. Some examples below:

• App code on a battery powered device may check if it is not already commissioned and then try to `otJoinerStart()` upon boot (and monitor  the join success/failure and handle however many retries if/when needed)
• Other behaviors may be added based on device HW capability and intended UX, e.g. if there is a button on device, app layer code may be written to retry joining upon user pressing the button, etc.
• If there is an out-of-band (not Thread) mechanism to connect to the joining device , it may be used to trigger and control the Thread commissioning process, e.g., if device has BLE, a vendor/product specific protocol/mechasnim may be used to establish a connection from a mobile phone to the new device (using BLE) and then trigger and control it for joining to the Thread network (and in general setting up and configuring of the device). 

Hope this helps,

Abtin.

[Nikhil Komalan]

okay. But what  happens to CLI in sleep mode in SEDs ? 

[Abtin Keshavarzian]

I am not sure about what you are asking here. Would be helpful if you can add a bit more detail.

If you mean how the CLI operates when the device is put to sleep.

• In general, in a radio SoC we have  MCU and radio components.
• MCU is running the firmware which consists of an OS (e.g. an RTOS), OpenThread stack, platform layer, drivers, app layer, etc.
• On an SED, OpenThread stack puts the "radio" to sleep. 
• Note that OpenThread does not directly control or manage power state of the MCU.
• The control of MCU (whether it stays on all the time, or put into low-power (sleep) states in idle mode and/or what signals awakens the MCU, etc), are all up to OS and app layer.
• So CLI along with rest of OT stack and device firmware can continue to run when the radio is in sleep.

Just to give you two simple examples of how OS may manage MCU power state:

• MCU can be always running and ready to receive CLI command (for example from a UART interface).
• An RTOS on MCU may be configured to put the MCU in low power state (from idle task, i.e. when there is no pending task to run), and then UART  can configured to awaken the MCU on a received bytes (which can then processed and handled as CLI command)