I have a network consisting of the coordinator, two routers under the coordinator and 9 endpoints under each router. The coordinator and endpoints have been programmed with pycharm, so they run my micropython code, while the routers function in the default mode with no custom programs.
The endpoints consist of an Xbee 3 Zigbee that is connected to a SHTC3 temperature and humidity sensor. The role of the endpoints is to send the measured temperature and humidity value to the coordinator once every minute.
The code on the coordinator is simply polling and checking if there are any packets to be received on the RF, while the endpoint code is comunicating with the sensor, reading the temperature and humidity values and sending them to the coordinator, after which it sleeps for 1 minute and then begins the cycle again.
The problem is that after 3 days of running, the endpoints under one of the routers stop transmitting, while the ones under the other router are fine, even if the routers are identically configured.
I can’t figure out why this might be so any help will be greatly apreciated.
What firmware version are you working with?
Are you able to query any settings from the radio via a different radio?
The firmware version is 100B. I have never thought of query over RF, usually I just do it by manually inserting the xbee into the programmer and reading the parameters with xctu.
Doing so can tell you a great deal of what is going on. That is, is it an RF issue where you can’t reach the node or is it with the device connected to the XBee?
Which of the parameters would be of importance? I can read them at the endpoint and attach them to the payload alongside the temperature and humidity data.
Frankly any of the commands would work. The point being, that you can talk to the radio over the air. So while it may be possible to modify your Python code to read an AT command and include it in your response, it defeats the purpose.
After the problematic endpoints stop transmiting, they wont connect to the coordinator again. Only if I put each one of them in the Xbee Explorer and flash the AT parameters and the program again, only then will they connect again and transmit.
do they respond to a Node Discovery or to the ATDN command?
I reflashed the program on the coordinator so that it does a discovery, and after I did this the nodes that stopped transmitting did connect to the network, even if their programs were not changed, this makes me think the problem lies with the coordinator…
Actually it sounds more like a broken RF path or something to that nature. You might want to adjust your code to do a DN from the node to the coordinator also if this issue occurs again.
How long are the endpoints awake? They need to be awake long enough to perform a route discovery to the coordinator if they lose connection.
Digi Technical Support
For the sleep I used the default python sleep function which to my knowledge does not really put the xbee in sleep. I want to replace it with the proper function (sleep_now) in the future, but for now I dont think the XBee ever properly sleeps.
You mean to call xbee.discover() from the endpoints?
Yes I was referring to the sleeping end device to run the discovery.
Yes, the function you linked is correct and is sleep_now. What I used, on the other hand, is sleep, which as far as I know is not initiating a ‘real’ sleep.
As the endpoints are not connected to any PC, I can’t really see the result of the discovery function after it’s called. I doubt just calling it will solve the problem so I suppose you are you suggesting to call it for debugging purposes to see if it sees the coordinator? In that case is it possible to save the output in file on the endpoint or something like that?
This is to determine where the actual issue is. Or if it is a broken link.
An interesting situation, I want to model it for myself and check everything, then I can write a comment!
From what I talked to support it seems that my micropython code on the endpoints is the cause, I will try to monitor it to see the error when it occurs.