This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530 - newer finishes Commisioning in Power Saving mode

Other Parts Discussed in Thread: CC2530, Z-STACK, CC2531

HW: CC2530
SW: Z-Stack 3.0.2
Compiler: IAR 10.30
Coordinator: Zigbee2MQTT

I am working with some CC2530 devices that act as End Devices and connect to a network provided by Zigbee2MQTT. They are simple switches with two buttons:

P2.0 is used for Commissioning.
P0.1 is used as a switch.
Both pins use interrupts.

I used the GenericApp as the foundation for the project and then incorporated parts from the SampleSwitch to enable the switch function. It works perfectly. After a fresh flash and when I start the Commissioning process, the device successfully joins the network, is interviewed, and paired. It also sends the on/off commands - everything is good.

static void zclGenericApp_HandleKeys( byte shift, byte keys )
  if ( keys & HAL_KEY_SW_1 )
  if ( keys & HAL_KEY_SW_6 )
    if (isToggleSet1) {
        zclGeneral_SendOnOff_CmdOn( GENERICAPP_ENDPOINT, &zclGenericApp_DstAddr, FALSE, bdb_getZCLFrameCounter() );
    } else {
        zclGeneral_SendOnOff_CmdOff( GENERICAPP_ENDPOINT, &zclGenericApp_DstAddr, FALSE, bdb_getZCLFrameCounter() );
    isToggleSet1 = !isToggleSet1;

  if ( keys & HAL_KEY_SW_5 )

However, the End Devices are battery-powered and need to go into Power Saving mode. To achieve this, I did the following:

Enabled POWER_SAVING as a compiler option.
In f8wConfig.cfg, the setting RFD_RCVC_ALWAYS_ON is set to FALSE.

After flashing the device with these settings and initiating the Commissioning process, the process starts but suddenly stops. According to the logs, the device joins the network but fails the interview:

2023-10-24 19:38:15 Zigbee2MQTT started!
2023-10-24 19:38:36 Device '0x00124b00279e698d' joined
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00279e698d","ieee_address":"0x00124b00279e698d"},"type":"device_joined"}'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x00124b00279e698d"},"type":"device_connected"}'
2023-10-24 19:38:36 Starting interview of '0x00124b00279e698d'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00279e698d","ieee_address":"0x00124b00279e698d","status":"started"},"type":"device_interview"}'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x00124b00279e698d"},"type":"pairing"}'
2023-10-24 19:40:54 Failed to interview '0x00124b00279e698d', the device has not been successfully paired.

I doubt the problem is related to Zigbee2MQTT, as it functions perfectly without Power Saving. The issue must be related to my code somewhere, even though I used the standard sample applications with minimal customization.

I suspect the device goes into power saving mode before the Commissioning process is finished. However, I have no idea why this is happening. I am completely stuck.

As a last resort, I kindly ask for your help.
Please ask for any code snippets, files, etc., that could help identify the problem. Just to clarify, I don't have access to a sniffer.

A link to where the source files can be seen:!AtnMB8Vx3S_EhdcPuJy_ROEDifG8hw?e=1WZf66

  • I would suggest you to use sniffer to check what exactly happens over the air.

  • Hi YiKai

    Thank you for your response.

    I will try to get a sniffer up and running. Stay tuned! 

  • Hi YiKai

    I have now purchased a CC2531 USB Dongle as sniffer. And plan to use Wireshark.
    Unfortunately, the delivery will take about 3 weeks.

    For how long time will this thread be open without activity? Will it be closed automatically within the 3-4 weeks?
    If yes - do I 'just' have to place a comment once in a while to keep it alive?

  • Hi Flemming,

    As it appears that the device has joined and connected properly, it is possible that the sleepy ZED is operating as intended but the ZC Zigbee2MQTT is not expecting to communicate with a polling device.  If the interview process communicates through broadcast messages or direct messages without waiting for Data Requests from the ZED, then communication will fail.  This may have been avoided during device joining since several messages are so quite consecutively, but then does slow down after the ZED has fully joined and reduced its poll rate.  You can review the Z-Stack 3.0.2\Documents\CC2530\Power Management For The CC2530.pdf documentation and contact the zigbee2mqtt team for additional thoughts (I'm aware that has involvement and is sometimes active on the E2E).

    E2E threads are automatically closed after four weeks of inactivity (i.e. no new replies).


  • Hi Ryan

    Thank you for your feedback!

    This actually makes good sense. I looked through the Power Management document as you suggested, and it gave me some ideas to work with first.

    If that fails I will try to reach out to the Zigbee2MQTT team to get their point of view.

    Best regards


  • Hi Ryan

    As mentioned, I wanted to conduct some more tests before reaching out to the Zigbee2MQTT team. I aim to gather as much information as possible for them.

    I planned to test what would happen if the device was configured correctly as a sleeping device but never actually entered sleep mode. The idea was to see if the power-down somehow impacted the Commissioning communication with Zigbee2MQTT, as if the device was simply shutting down during the Commissioning process.

    The way I tested it was by forcing the device not to enter sleep mode, achieved by commenting out 'osal_pwrmgr_powerconserve()' in OSAL.c.


    #if defined( POWER_SAVING ) && !defined(USE_ICALL)
      else  // Complete pass through all task events with no activity?
        //osal_pwrmgr_powerconserve();  // Put the processor/system into sleep

    Now the device does not enter sleep mode, but the problem with Commissioning still persists.

    Does this behavior change your view of your suggestion regarding the poll rate?

  • The commissioning process is assumed to be successful and completed given that device_joined and device_completed are shown on the ZC Zigbee2MQTT log.  Since your workaround has not been tested internally by TI, you would need to verify that the device_interview and pairing messages are being received and processed by the ZED.  This can be accomplished through a sniffer log comparison or by further debugging incoming messages through zcl_ProcessMessageMSG.  


  • OK - thanks.

    I will wait for the sniffer to arrive. Anything else now will just be guess work.

  • While I wait for the sniffer... I looked into zcl_ProcessMessageMSG as you suggested, to see if I could figure something out in the meantime.
    And the thing is, I actually got it to work!

    The device starts the commissioning, and I get these responses AF_INCOMING_MSG_CMD / ZCL_PROC_SUCCESS during the process, and the device then goes to sleep. Big success!

    For now I just use these conservative settings:

    But this is working in debug mode only. When I create the HEX file and upload it to the device, it does not work. The device starts the commissioning, but there is no AF_INCOMING_MSG_CMD / ZCL_PROC_SUCCESS responses (I made some checks with LED's).

    What could cause this different behavior between debug mode and programming the chip? Any suggestions on what to look for?

  • I appreciate the update.  Does your CC2530 device have a working, reliable external LF crystal attached?  This may be necessary for low-power standby operation, and without it the device fails when attempting to enter a sleep state.  The difference with debug mode could be that the JTAG forces the device to stay active, thus it continues to operate as before.

    Also, would you consider upgrading to the CC2652RX or other similar device on the SIMPLELINK-LOWPOWER-SDK?  This would give you the latest and most reliable Z-Stack solutions which are capable of accomplishing far more than the CC2530.


  • Thanks for swift reply.

    Unfortunately, at the moment, an alternative to CC2530 like the CC2652RX is not an option.

    The device is based on the E18-MS1-PCB module from EBYTE. This module is well-known and can enter sleep mode in other applications. So, I do not
    suspect the crystal to be the problem. That would be highly unlikely with this well-proven module.

    JTAG: (I debug using the 'CC Debugger')
    I am not quite sure what you mean. Do you mean it's forced to stay active during the commissioning only? Because the device actually enters sleep mode after successfull commissioning using the 'CC Debugger'. I can see that from the LED turning off and the reduced power consumption. Something else must be going on.

  • Have you tested on multiple EBYTE modules?  It may be possible that the crystal is failing on this specific board, perhaps even due to outside factors such as ESD or over-voltage situations.  Also, do you have any method, through user interface (it appears you may have an accessible LED) or Zigbee messages, to confirm that the CC2530 device is still actively  processing application and network information as compared to being trapped in a HAL assert or frozen?  It would also be helpful to further evaluate device behavior if the ZED is connected to a TI ZC, such as SampleLight or a ZNP + Z-Tool, to compare behavior.


  • Hi Ryan,

    I finally got it working!

    In the end, I ended up with this solution:

    I initiated the commissioning with these settings in f8wConfig.cfg:


    This will make the device do a successful joining/interview with Zigbee2MQTT. But with these settings, the device does not go into a deep sleep. So I added this timer event in zcl_genericapp.c that triggers after successful commissioning:

      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
        osal_start_timerEx(zclGenericApp_TaskID, GENERICAPP_EVT_1, 5000);

    After 5 seconds, the poll rates are set to 0, and the device can enter deep sleep.

    if (events & GENERICAPP_EVT_1)
      return (events ^ GENERICAPP_EVT_1);

    Thank you for your help and very useful suggestions. This is much appreciated.

    Best regards,