ZigPC Gateway Request Queue

Request Queue API to send messages to EmberAf/ZigbeeHost layer. More...

Namespaces
namespace	zigpc
namespace	zigpc::gateway

Detailed Description

Request Queue API to send messages to EmberAf/ZigbeeHost layer.

The public API available to send messages to the ZigbeeHost API via ZigPC Gateway is redirected to the below asynchronous Request Queue (zigpc::gateway::RequestQueue).

RequestQueue Storage

The RequestQueue uses the virtual base class to store API call (zigpc::gateway::Entry). This class provides one virtual function invoke() that must be overridden by derived classes. Each ZigbeeHost API call should be wrapped in a separate derived class.

For example, the derived class DiscoverDeviceRequest uses the invoke function to call the zigbeeHostZdoActiveEndpointsRequest APIs using the information persisted in the object in its constructor.

RequestQueue Behaviour

The RequestQueue is initialized as a singleton and is accessible using the static getInstance() function.

The ZigPC Gateway public API handlers in src/zigpc_gateway.cpp calls the appropriate derived class constructor and creates a shared_ptr instance of that object. This object is passed to the enqueue function in the RequestQueue singleton.

The dispatch/dequeuing of the RequestQueue is triggered by the internal Contiki process in response to a ZigbeeHostTick timer used to periodically call the emberAf stack.

NOTE: In the dispatch procedure, the member variable RequestQueue::defer_cycles is used to prevent invoking any API calls for the following reasons:

• To proportionately call the ZigbeeHostTick() routine for every 1 API call dispatched (i.e. currently the RequestQueue is setup to call ZigbeeHostTick() x2 per RequestQueue::Entry dispatched).
• To prevent sending any RequestQueue::Entry after getting network saturation errors; In this case, the call data is not popped from the stack and a retry of the call will be performed.

See constants in zigpc::gateway::RequestQueue for these defer cycle defaults.