Zigbee - from flakey to stable

When I get home I will take a picture of my 4 devices. I actually used old ADT security contact boxes. Kind of hide all the lights so as not to be too noticeable.

They will not repeat. That is why I no longer have any Xiaomi sensors in my network. I also use the Visonic for temperature with my own DTH.

Just want to chime in here and say that with inspiration and information on this thread, I got an XBee S2 (eBay US $16) / Waveshare USB Adapter (Amazon US $14) connected to my Mac and mapping my SmartThings & Hubitat Zigbee mesh just great.

For some reason I had to use a baud rate of 9600 to initially add my XBee module in XCTU, but then was able to set it to 115000 in the configuration settings.

Like @AlecM and @ArstenA the S2 is part of the XBP24-ZB family, so I first update the firmware to XBP24-ZB > ZigBee Router API > 23A7 (Newest) and then manually change the config settings by opening up @adam_walker’s file in the “Firmware Explorer” and replicating all the changed values (indicated with green triangles).

It should be pointed out that the encryption key is actually the default Zigbee HA (Home Automation) trust center link key, and should work for almost any HA ZigBee hub.

I’m use quite a lot of Xiaomi devices, but I haven’t started experimenting with getting them to connect through the XBee or the one other router device I just got, a Securifi Peanut Plug. But that was the reason I got the Xbee, so I can report back my findings, if anyone is interested, in another thread.

I’ve notice some back and forth on this thread about how to use an XBee both as a mesh mapping tool and also serving as a router, and I have a question on this:

Will the ZigBee Router API function set allow the XBee to serve as a ZigBee router when used standalone (i.e., just connected to USB power rather than to host computer, etc.)

My thought is if an XBee can act as a router without a host connected, then I might be able to use an inexpensive powered USB hub to supply power at whatever location I decide to install it, but then plug in my laptop when I need to examine the mesh map.

Hello Keith @veeceeoh,

@adam_walker has been able to use his xbee(s) as router(s) for xiaomi devices and have them stick and keep working. I haven’t, even after using his settings and many variations of them. My xiaomi devices connect and work initially, then drop after like they would with any other router that’s not the hub/coordinator. There’s an x factor we haven’t been able to identify. I use mine for mapping and as router for a few of my other zigbee devices - in particular some of my Quirky Trippers - which does help with keeping a few of the 32 slots open. They do work beautifully for mapping! (And when they do work as routers work fine w/o being connected to laptop).

Alec

1 Like

All good to know, @AlecM, thanks!

My goal is to get my Xiaomi devices working with my Hubitat, and since it also has a 32 device limit, I’m going to need at least one or two repeaters. Having the XBee will make it a lot easier to find out if the Xiaomi devices will “play” well with my Peanut Plug and/or the XBee itself, and if not, then I’ll have to come up with another game plan (which might mean connecting less “time-sensitive” Xiaomi devices to my ST hub so as to avoid hitting the 32 device limit.) Fortunately distance / mesh strength doesn’t appear to be an issue with my home being relatively small.

I’ve had great luck using a powered USB hub with my synthesizer setup acting as a standalone power source to which I sometimes connect my laptop for host control, so hopefully that will also work with the XBee and then I won’t have to unplug it whenever I need to use it for mapping.

@AlecM Have you tried adjusting the SN and SP parameters on the XBee? I haven’t tried this myself but I’d suggest setting SP to the max value of 0xAF0 and SP to something like 130. That should be more than enough to keep the XBee from thinking the Xiaomi device has left the network.

1 Like

Well done @tpmanley I was going to suggest the same thing, after a few weeks of trying various profiles, I stumbled across some literature relating to those two values, I increased them, and no issues since. It relates to a “sleep” value.

2 Likes

Out of curiosity, do the SN and SP parameters relate to the potential issue that Xiaomi devices have with End Device Aging, as you described last year in this post? Or are they for another kind of time out?

EDIT: I did some poking around to try to answer my own question and it appears that the SN (Number of Sleep periods) and SP (Sleep Period) parameters are not related to End Device Aging~ EDIT: Tom has confirmed they are related to End Device Aging (see two posts down for more).

Here’s a few bits of info from the XBee SDK Documentation Programming Guide:

In cyclic sleep mode there are several parameters that can be configured in the power management component:

  • Sleep Option (SO): Defaults to short sleep. This setting should not be changed to cope with the examples and procedures described in this guide.

  • Sleep Period (SP): Defaults to 5000; ranges from 320 to 28000 mS. It Sets the number of milliseconds that the radio will sleep before it awakens again to poll the coordinator for packets. It is likely that you will customize this parameter for cyclic sleep mode.

  • Time before sleep (ST): Defaults to 500; ranges from 1 to 65535. It Sets the number of milliseconds of inactivity (no serial or RF data is sent or received) before going to sleep.

  • Number of sleep periods (SN): Defaults to 65535; ranges from 1 to 65535. If SN is 1 when the sleep option (SO) is configured to short sleep, the On Sleep pin will be asserted during every sleep period. Otherwise, the On Sleep pin will be asserted when a package is received or when the number of SN cycles has been consumed. This configuration should not be modified. The high default value prevents the radio from disturbing the CPU if there are no packets pending to receive.

If the SP parameter within the power management component is set to 5000, meaning 5000 mS or 5 seconds, the SP parameter within the coordinator must be set to 5000 / 10 = 500 = 0x1F4 → 1F4.

EDIT: Note that the above information pertains to end devices, not routers (repeaters), or hubs (coordinators) as Tom M explains a couple posts below.

1 Like

I did a little research on the model of XBee I bought to see if it’s programmable, and thought it may help to share a little insight on the model designations.

Mine which is silkscreened “S2” is not programmable. The units which are programmable would be silkscreened S2B or S2C. Programmable means that it has it’s own CPU and supports development of applications without a host developer board. Both the programmable and non-programmable variants allow for firmware changes / upgrades.

The full model of my particular XBEE is XB24-Z7WIT-004. Here’s how to break down the full model designation:

Series 1 (802.15.4) or Series 2 (ZigBee) XBees
XB24- = non-Pro version
XBP24- = Pro version (higher transmission power)

Shipped Firmware type
A : 802.15.4 (for series 1)
DM : Digimesh (for series 1)
B + something other than Z7 : ZNet2.5 (obsolete firmware for series 2)
Z7 : Zigbee (for series 2)
BZ7 : Zigbee (series 2B module)
CZ7 : Zigbee (series 2C module)
DZ7 : Zigbee, thread-ready (series 2D module)

Type of Antenna
CI : on board ceramic chip
PI : PCB (trace)
RI : RF pad
SI : RPSMA connector
UI : U.FL connector
WI : wire whip

PCB Type
T : Thru-hole
S : Surface Mount (SMT)

-001: series 1 module
B003: series 2 programmable module
-004: series 2 module

The above breakdown doesn’t include the new XBee 3. Keep in mind that for each different original firmware type there’s a different set of firmware updates. That’s why Adam’s config profile which includes a firmware file for his Series 2B Pro programmable module XBP24-BZ7 comes up as incompatible with my Series S2 XB24-Z7.

1 Like

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.

2 Likes

As it happens, we were just discussing exactly this process in a different thread earlier today. :sunglasses: The following is a good article on the distinction between parent behavior and child behavior when the handshake doesn’t complete.

1 Like

I’ll be trying that today! Thanks Tom! @tpmanley!

1 Like

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).

So far, this is amazing Tom - @tpmanley you rock!

(I thought I’d looked at every variable but apparently not at these two).

heads up @ArstenA if it sticks - it might be the solution to the 32-device limit for Xiaomis.

I’ll keep on reporting… cautiously optimistic, here!

1 Like

Great explanation, Keith @veeceeoh these can be so confusing!

I checked my settings… i have played with the settings as described by tom, so that may explain my success.

word of caution … if i take my ikea tradfris out the mesh, i still loose a sensor fairly randomly.

Xbees + tradfris i have been stable for months, loosing only a sensor in my parcel box outside, which is marginal range at best.

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.

1 Like

@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?

Just out of curiosity - the original or the aqara temp sensor? And was the sensor connected to hub or to xbee?

The aqara. Doesn’t matter what it was connected to ( tried both), i had issues. As I said, could have been a coincidence…but I suspect not.

Has anyone figured out a way to get the Xbee to report back events etc so we can confirm its connected and working within the app