Yep, you got it. The XBee user manual calls this the Child Poll Timeout:
Child poll timeout
Router and coordinator devices maintain a timestamp for each end device child indicating when the end device sent its last poll request to check for buffered data packets. If an end device does not send a poll request to its parent for a certain period of time, the parent will assume the end device has moved out of range and will remove the end device from its child table. This allows routers and coordinators to be responsive to changing network conditions. The NC command can be issued at any time to read the number of remaining (unused) child table entries on a router or coordinator.
The child poll timeout is settable with the SP and SN commands. SP and SN should be set such that SP * SN matches the longest expected sleep time of any end devices in the network. The actual timeout is calculated as (3 * SP * SN), with a minimum of 5 seconds. For networks consisting of pin sleep end devices, the SP and SN values on the coordinator and routers should be set such that SP * SN matches the longest expected sleep period of any pin sleep device. The 3 multiplier ensures the end device will not be removed unless 3 sleep cycles pass without receiving a poll request. The poll timeout is settable up to a couple of months.
The part you quoted describes how those parameters work for an end device which is a little different than for a router or coordinator.
As it happens, we were just discussing exactly this process in a different thread earlier today. The following is a good article on the distinction between parent behavior and child behavior when the handshake doesn’t complete.
Ok - well - will wonders never cease - so far with an Aqara motion sensor connected to one of my Xbees) it’s been on 4 hours and I just got my first battery report (which w/ Xiaomi’s generally imply a solid connection)!!! (I think battery report delayed from from the usual timing because I think I kept it in test a long time by frequent motion tests).
One further factor. If i introduce the xiaomi temperature sensor, basically i can be fairly sure bad things will happen to my network. I have eliminated it as it introduces instability.
Not sure if placebo, but back in the testing days…the 3 times i introduced it to the network, things got bad, and when removed, things got better. The engineer in my knows the isnt statistically significant…but i like my stable smarthome.
@adam_walker - sorry if I missed SN and SP in your original profile - could have been something when I was viewing them in the XCTU profile viewer or whatever it’s called (don’t have in front of me) - in any case it’s still working for me with these new settings - and doing even better with the Trippers (actually showing them connected - in the past they were connected but only showed in scan if I activated them during the scan). Thanks again for the original article that got this started! Maybe worth updating your guide with specific settings if you feel like it?
I have two of the old and two of the new operating w/o any trouble (all connected to hub for now) - you may just have a rogue device or the walls of our house are different (lathe and plaster can be a bit challenging) or who knows what. This stuff is fun to troubleshoot isn’t it? Anyhow, you may just have a sample of 1 but, hey, statistics or not, agree it makes total sense to keep it out of your system if you think it gives you trouble.
BTW, your tradfris - are they connected to ST or to a Hue Hub? (Mine are connected to Hue - so I’m guessing they wouldn’t influence my main Zigbee net, just the Hue’s).
I have about 10 of the GU10 £7 tradfris connected to the ST hub , with a couple of the e27 bulbs. I also have a few connected to hue.
With the new “mirror” function and virtual switches (and the fact you can use the zll dimmer bulb DH which is local) I am tempted to ditch hue and put everything on smartthings
Can you (@adam_walker) advise where you find those devices at those prices(orig post etc) ? I am looking at £20+ mostly 25+ for xbee and £7+ for the usb board, Have looked on ebay, amazon plus banggood & gearbest - am I looking for hte wrong things ?
So last weekend I finally had a chance to start testing my XBee S2 (model XB24-Z7WIT-004) as a router (repeater) for a bunch of Xiaomi devices, with the Child Poll Timeout (SN and SP parameters) adjusted as @tpmanleyrecommended.
And - with my Hubitat hub at least - the XBee is working great as a repeater for range of. Xiaomi devices! I’ve had six devices connected since Sunday, three via “healing” the mesh, and three paired via the XBee, and they have kept their connections just fine, with no issues.
It seems safe to assume the same luck will be had when using XBees as repeaters for Xiaomi devices on a SmartThings hub as well, especially with @AlecM’s positive report from some weeks ago.
So as far as I’m concerned there’s just one shortcoming to using the XBee as a router / repeater, which is that it seems to be completely “silent” as an end device, and so there appears to be no way to check that it’s still connected and “active”. In fact, on the Habitat, the lack of device events led it to decide the XBee is “inactive”, although it’s still performing dutifully as a repeater.
All I saw was a couple of catchall messages when I first paired it, and then nothing after that. So I am wondering if there’s any way to create a device handler that would send a configuration to the XBee to ask it to send “check in” messages to the hub, which could in turn be sent as events, even for a custom attribute, so the hub continues to consider the XBee to be connected.
I’ve searched through a bunch of forum threads, but turned up nothing but device handlers for custom Arduino/RaspPi+XBee device projects. Has anyone seen a device handler for an XBee module simply being used as a repeater?
Just to confirm - I have three XBees repeating xiaomi and other devices solidly on my SmartThings v2 hub - @tpmanley’s suggestion (along with @adam_walker’s excellent guide) was definitely the breakthrough for me . It’s been a few weeks and I’d say that using them has made me able to go beyond the zigbee 32-device limitation when using Xiaomi’s. Agree, @veeceeoh, it would be nice to have some kind of “indication of life” - I just use XCTU to check in on them occasionally.
Heck, I’ve got an XBee already with two more on the way - I’m just busy / being lazy. If there’s no DH already out there, I’ll see what I can do to make one (that works on SmartThings too!)
That’s great news! Finally hitting the “golden age” of Xiaomi device use on ST!
The following is a good article on the distinction between parent behavior and child behavior when the handshake doesn’t complete.
If there’s no DH already out there, I’ll see what I can do to make one (that works on SmartThings too!)