Please don't use the generated structure "ConfigureReportingRecord ". There is a   pointer inside it. This is not correct.

Besides that, according to ZCL spec, 

1. When the direction is 0, the timeout period field is omitted.
2. When the attribute is a discrete value, the reportable change field should be omitted.

I suggest you define a structure to fill the payload by yourself. Below is an example:

#pragma pack(1)
typedef struct
{
  uint8_t   direction;
  uint16_t  attributeID;
  uint8_t   attributeType;
  uint16_t  minInterval;
  uint16_t  maxInterval;
}MyReportingRecord;
#pragma pack()

void custom_cmd_cfgreport()
{
  EmberStatus status;

  MyReportingRecord stRecord = {0};

  stRecord.direction = 0;
  stRecord.attributeID = ZCL_ON_OFF_ATTRIBUTE_ID;
  stRecord.attributeType = ZCL_BOOLEAN_ATTRIBUTE_TYPE;
  stRecord.minInterval = 0;
  stRecord.maxInterval = 1;

  uint16_t nodeID = (uint16_t)emberSignedCommandArgument(0);

  emberAfSetCommandEndpoints(1, 1);
  emberAfFillCommandGlobalClientToServerConfigureReporting(ZCL_ON_OFF_CLUSTER_ID, &stRecord, sizeof(stRecord));
  status = emberAfSendCommandUnicast(EMBER_OUTGOING_DIRECT, nodeID);
  emberAfCorePrintln("status=0x%X", status);
}

It works fine on my side:

Hi Vihang Jani, 

So far as I know, we don't have a public document about it. Please contact your local sales to check if it is possible to provide the document if you really want it. 

Thanks,

Jim

Hi YK, I think the command ID "11" is a decimal value, not hexadecimal.  

Like below: 

Hi wang chaoqun ,

It's a typical issue we usually met when developing Zigbee gateways.  When the gateway reset, the routing table will get lost. As the gateway will send MTORR (Man-To-One Route Request) periodically,  the route will be repaired after a short time. However, if you want to send messages from the gateway to other devices before the route is repaired, the message won't be delivered. 

To accelerate the route repairing, you can send a MTORR immediately after the gateway starts up.  This can be done by calling emberSendManyToOneRouteRequest .

And you still need to make the other devices send a route record to the gateway, so that the routing table can be repaired. To achieve that, you can broadcast a message to query an attribute which all devices support, so that they can send back an unicast response. I suggest you query the attribute "ZCL Version" of the "Basic" cluster. When the other devices received this query, they will send an unicast response. Before sending the unicast response, they will send a route record, so that the routing table will be repaired very quickly.

To understand more details about the Many-To-One routing mechanism, you can refer to the following KBA:

https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/12/18/_many-to-one_source-JRvm

Please let me know if you have any further questions.

Thanks,

Jim

If it's not sent out, most likely it's because there is no route towards the destination or there is CCA failures.

You can use the following command to check if there is CCA failures (Must enable plugin "Counters" first).

plugin counters simple-print

• Print all counter values.

You can use the following command to check the routing table:

If plugin "concentrator" is enabled,

plugin concentrator print-table

• Print the SOC/NCP source route table.

Otherwise, use:   (Must enable "Stack Diagnostics" plugin first)

plugin stack-diagnostics route-table

• Prints out the entries in the stack's route table.

If your gateway has enabled plugin "concentrator" and just recovered from reset, please check my reply in https://www.silabs.com/community/wireless/zigbee-and-thread/forum.topic.html/z3gatewayhost_cantsendmtorr-ofEi to accelerate the route repairing.

Please let me know if you have any further questions.

Thanks,

Jim

If your gateway is based on host+NCP architecture, please refer to https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2018/03/28/how_to_upgrade_downg-kocV

1. Sorry, it's not possible at this moment.

2. The SimEE only provides a non-volatile data storage mechanism. It's the application which determine the access frequency of the data. Zigbee stack will only store some network parameters, like PAN ID, Node ID, Security Keys, Child table etc. They will be written only when they are changed. I don't think you need to care about the read frequency. Reading has no impact on the flash life.

3. They will be kept in the flash. No need to copy them to RAM.

For new designs, it's recommended to use NVM3 instead SimEE as it's more reliable and configurable.