LT sensor in sleep mode: Out of the network

XBee & XBee Gateway ZNet 2.5
,
1

I manage a Xbee network with 30 end devices, two routers and one coordinator.

Six of these 30 end devices are LT sensors working in extended sleep mode: They sleep for five minutes and then wake up for sending one sample of temperature.

Some weeks ago I replaced one of them because each certain time it was not able to send data, even being at the side of another LT sensor working right, so I discarded out-of-range problems.

After installing the new one and configuring it according to the Digi wiki, and after being working right for some days, now the device is unable to send data. If I open the coordinator interface I can see how the device is added to the list in two minutes aprox. (it wakes up every two minutes), but I’m not able to get any data from it both by clicking on in in the coordinator interface or by resetting the coordinator.

The sensor configuration is:

SC 0x3fff
DH,DL: Coordinator address
IR: 0xFFFF
WH: 125
SP: 1000
SN: 12
SM: 4
SO: 4
SP: 500

Special care has been taken when configuring coordinator and routers:

SC 0x3fff
SP:1000
SN: 90
NJ: 255

Firmware in the coordinator and routers is version a7, firmware in this end device is 2ca7.

I am really tired and frustrated with LT sensors in sleep mode. After one year fighting with this network I’ve not been able of keeping all the LT sensors working joined for more than one month.

Please, what I’m doing wrong?

2

what are you running for a python application on your gateway? Dia? If so, what is the configuration file (dia.yml)?

3

I think there is a limit for the end device to sleep, else it will loose its parent. I m not sure about the exact figures, Digi people can help you in this.
Coming to module settings, You will have a better performance if sleep settings on the Coordinator is same as sleep settings on end device.

1 Like
4

Thanks both kjensen and ksa for your answers. Gateway is running in legacy mode, ie, it forwards all xbee network traffic to its serial port that is forwarded to a tcp socket, and all the traffic sent to the tcp socket is forwarded to the serial port and then to the xbee network.

On the other tcp socket side there are a set of scripts that manage the data coming and going to the network. Very similar to the python running in the coordinator model, but in my case running in other host.

And I’m pretty sure that the fact that being in legacy mode is related to the error. From six devices in sleep mode, there’s one that always falls from the network, it can last one day or one month, but finally it becomes down. If, in this situation, I reboot the coordinator nothing happens, ie, the end-device keeps on out of the network. But if I reboot the device in non-legacy mode, coordinator sees the end-device as soon it send the first read. Once added to the end-devices list I reboot the coordinator in legacy mode again and it is running well from days.

I post this matter some time ago in this forum, but I didn’t get any help. I’m quite sure that it must be a bug, ie, something that the coordinator performs in normal mode is not performed in legacy mode.

It’s important to state that the other five end devices work perfect and that all share the same firmware and configuration. It’s important to state too that this end-device is located at the side that other end-device working fantastic.

Finally I changed the end-device. I was pretty sure that the cause was not the whole device, but anyway…

I’ve read many times the manual (XBee - xBeePro ZB RF Modules), some books (Building Wireless Sensor Networks) and this forum, but it seems that the configuration is right. It’s true that the attached configuration was a late modification where I increased the node timeout (SN: 90 in coordinator/routers intead of SN:30), but before this change the SN was 30 in coordinator/routers and the problem remained.

Very boring story, I have to admit. But any help or experience in similar environments would be really apprecianted.