Timout from coordinator sending to a sleeping end node (micropython transmit) and blocking

I have an XBee3 as a Zigbee coordinator and another XBee3 as a Zigbee end node. Both are running Micropython code.

The end node sleeps for about 5 minutes between sampling various sensors and then creating a packet that is sent to the coordinator - all that works nicely.

I also want to have the coordinator pass a custom packet to the end node (providing commands to adjust the settings etc).

My understanding is that the coordinator will accept the ‘xbee.transmit()’ function call and queue up the message until the end node wakes up when it will pass the message on to the end node.

I have two problems:

  1. if I send the command to the end node more than about 2 minutes before the end node wakes up, I get a ‘ENOCONN’ error back from the ‘xbee.transmit()’ function. (Less than about 2 minutes then it goers through as expected). How to I extend the timeout (if that is what it is) in the coordinator to allow for the end node to sleep for 5 (or more) minutes?
  2. the ‘xbee.transmit()’ function seems to block until the message is sent. This stops the other operations that the coordinator is supposed to be doing and also seems to go against my understanding that the coordinator can queue up to 8 packets - if it blocks on the first one then how can it queue the others!. How can the ‘xbee.transmit’ function be made to no block but queue the packet?


Or is this something that needs to have a support ticket raised?

Hi Susan,

  1. You could try winding out the extended timeout. Digi XBee® 3 Zigbee® RF Module . Personally, I would suggest you queue the end node commands into a python list and then in your receive function have it check the list and push any changes. This would obviously take one sleep cycle to set the change but at least you know the device is online (assuming you push out the sleep command enough to process the return message).

  2. xbee.transmit() is blocking Async transmit from MicroPython the queueing of packets is on the RF side not in micropython.

Nicholas Wilson
Your IoT

@NicholasYourIoT - Thank you for the suggestions. I had been considering your #1 but I was hoping that there was a way to extend the timeout beyond about 46 seconds (NH max is 255, SP max is 0xAF0 or 2,800 or 28sec; therefore 50NH + 1.2SP = 50*255 +1.2 * 2,800 = 12,750 + 33,600 = 46,350 ms or 46.3sec).
For IoT end nodes that seems to require a very frequent ‘sleep/wake’ cycle.
I was hoping that I had overlooked some other parameter that would extend this to something a bit more in the 5+ minutes range.
However the internal queueing of the messages is working well.

You need to understand that the timeout for data TX is limited to either 2 RF packets, 120 bytes, or within Digi XBee® 3 Zigbee® RF Module time frame. So your code needs to pay attention as to when the module has sent the data. I would suggest that you send some sort of response from the End Device. You can then use a timer function to account for the sleep cycle.