Home/Support/Support Forum/XBee3 likely crashed/froze up, is there a method to remotely hard reset it?

XBee3 likely crashed/froze up, is there a method to remotely hard reset it?

+1 vote
I keep having a few devices that die for some reason that I have not diagnosed yet. Is there a way to remotely reset the device? Can that be done through Digi Remote Manager?

For my crashing XBee3's, is there an easy way to log what went wrong? In the office, I had an XBee connected to a PC and left XCTU record function on to try and determine what was causing the XBee to crash. That works well. What I find many times is that the MicroPython program crashes and the device is connected and operational, but sitting at the MicroPython Terminal. A simple reset would do the trick...but how can this be accomplished?

Thanks
asked Sep 5 in XBee3 Cellular by Larry_Sellers New to the Community (4 points)

Please log in or register to answer this question.

1 Answer

+1 vote
You'll need to send remote AT command FR (Force Reset). According to the manual, it's best to send remote AT SD (Shutdown) before sending FR and wait for it to return OK which can take up to 2 minutes.

I'm only familiar with XBee Zigbee modules so I don't know for sure, but I assume you can use XCTU to send remote AT commands from one locally connected XBee Cellular devices to a remote one? Otherwise, Digi Remote Manager might be able to as well.

You might also try surrounding all of your MicroPython code with:
try:
<code>
except Exception as e:
<log or sys.print_exception(e)>

This should prevent ever crashing to the REPL MicroPython prompt.
answered Oct 7 by Janala New to the Community (6 points)
Thanks.  I believe sending remote AT commands (at least from what I have found) is not easily done on the cellular units. I do believe they can be reset through Remote Manager, but if the device has not been seen in a while - it usually means the cell link is down too...sooo sending a FR might be impossible.  

I did have the idea of surrounding all the code with a try..except, but I figured there was some existential programming rule against doing that.  I have put try..except blocks around pretty much every method at this point and log it locally on the device.  I will try to one last try..except around the whole smash and see what happens.  It would be good to have a final "I don't know what happened, but let's give the unit some shutdown time and then restart" process.  

I am having great success with the cell units in locations with good cell signal.  I am now toiling with a bad cell signal scenario...I figure it will eventually plague us at some point so I'd rather be prepared.  

Thanks for the info!
...