Green Power Operational Model#

A GPD is said to be operational when it sends application control commands such as on/off. Typically, such operational commands are useful after the GPD is commissioned to a Zigbee network after the commissioning process. Like commissioning, a GPD can have two operational modes.

• Unidirectional Operation: Sends commands to the Zigbee network and requires a minimum energy budget.

• Bidirectional Operation: Sends commands and receives a response back; for example, reading an attribute from the network. Because this mode sends data to the Zigbee network and receives data back from the network, it uses more energy.

Green Power Command Transport#

The following figure illustrates a high-level typical GP operational command transport with four GP devices.

These are the general steps in the Green Power command transport in the above figure.

1. GPDm (a GPD with Source Id = m) sends a command N (a GPDF frame) to GPPB1.

2. GPPB1 receives the command N.

3. GPPB1 looks up GPDm in its proxy table to determine whether GPDm has an entry paired with a Sink. If it does, GPPB1 forwards command N as a Zigbee Cluster Library (ZCL) notification to GPPB2. If it does not recognize GPDm after the proxy table lookup, GPPB1 drops the packet.

4. Once GPPB2 receives the notification, it forwards the command further as a ZCL command, as it would do for any other ZCL commands in the Zigbee network. (Any router in the Zigbee network would do the same because in Z3, all routers are GPPBs.)

5. The GPCB receives the ZCL notification and processes it by looking up its Sink table to obtain the required information. If all the information is correct and the GPDm is paired to this GPCB, the GPCB processes the command as follows:

   1. Looks up command N in its translation table to attempt to translate it.

   2. Translates command N to an equivalent Zigbee command (which includes interpreting the command payload) and finds one or more paired application endpoints (which are in the translation table). Refer to the translation table in Default Translation Table No Payload for the Zigbee Commands.

   3. Pushes the Zigbee packet to the identified application endpoint on the node.

Frame Format#

The following figures illustrate the standard format of a Zigbee frame and the format of a generic GP frame. The size difference is be- cause the entire GP frame must fit into the ZCL payload (or addressing).

Most of the information contained in the Zigbee NWK header and all the information in the APS headers is not relevant for GP operation. As a result, the GP frame contains a modified NWK header and no APS header, followed by a dedicated application payload. GP frames are compact and shorter, but they contain all the necessary information required for addressing and security.

Green Power Device Tables#

The table sizes (sink and proxy tables) are configured using the configurations in green-power-translation-table-config.h. The translation table is to support configurable translation for compact attribute reporting and multi-sensor **CJO multi-sensor operation?**. Compact attribute reporting is supported in the EmberZNet stack as part of supporting the translation table.

To support the Green Power feature, the following tables are maintained on the sink and/or proxy nodes:

• Proxy Table: This table holds pairing information about the paired GPDs and the corresponding Sink. An entry to the proxy table is automatically activated during the commission process. The application can access the proxy table entries with the following APIs:

• emberGpProxyTableLookup(EmberGpAddress \*addr): Look up a specific GPD source id in the Proxy table.

• emberAfPluginGreenPowerClientClearProxyTable(): Clear the Proxy table of all stored GPD pairings.

• Sink Table: This table holds information about local bindings between a particular GPD and the target‘s local endpoints in the GPS. An entry to the sink table is automatically activated during the commission process. The application can access sink table entries with the following APIs:

  • uint16_t emberAfFillCommandGreenPowerClusterGpSinkTableRequestSmart (uint8_t options, uint32_t gpdSrcId, uint8_t \*gpdIeee, uint8_t gpdEndpoint, uint8_t index): This function prepares an application framework ZCL com- mand buffer for the GP sink table request command with supplied arguments and returns the buffer length.

  • bool emberAfPluginGreenPowerServerSinkTableAccessNotificationCallback(void\* data, EmberAfGpServerSinkTableAccessType accessType): This function is called by the green power server plugin to notify the ap- plication about a GPD addition or removal by the GPS to the Sink table.

• Translation Table: Holds translations for GPD command into a command from the Zigbee application profile supported on the node:

  • The commands from the source (GPD) node do not come from a standard Zigbee command set. A sink node for GP commands interprets the commands received from the GPD and performs the required action. The sink node must translate the received command into a command from the Zigbee Application profile supported on the node (for example, Home Automation).

  • A Translation table entry is derived from the Default or Customized table.

• The Default Table: Stores the predefined translations as per GP specification. By default, the GPD Command Translation Table contains the generic translations (mapping the GPD commands to their ZCL equivalents).

• Customized Table: Contains specific command translations defined for a given GPD device. Creating a customized table is outside the scope of this guide.

  • If both default and customized translation are applicable to a particular GPD command, the customized translation supersedes the default translation.

  • The translation table is created during commissioning and later used to the interpret the command received from GPD.