DIY Programmable XBee (S2B,S2C) ZigBee integration with SmartThings

Hi @tgsoverly! Nice to meet you - i’m super glad that you are super glad and I’m looking forward to your experiences when playing with these chips. Be sure to let me know how it goes and all the code and learnings are welcome on the subject! I’m here to help whichever way I can because I know that the entry barrier to programming these excellent devices in a home setting is higher than your usual hobbyist boards.

Nowadays all my XBee devices are coordinated by ST, the non programmable variants are just appearing as a “Thing” but act as a range extenders to the network. Additional benefit for having more range is that the devices themselves can also send ZigBee compliant signals to the network so in the example of The Trigger, it can be operated both via SmartThings GUI as well as via HomeBridge/HomeKit/iOS devices.

If you have an XBee radio that supports the ZigBee-Pro stack (have the parameter ZS available via XCTU) it shouldn’t be a problem getting the radios paired with ST. Look at the following XBEE_PARAM_* definitions I’m setting in the Trigger project. Just set the same ones using your non-programmable variant via XCTU:

Also, perhaps obvious but worth to note, if you have more than one PAN running simultaneously in your house (or you are at the range of another PAN) make sure you hardcode the PAN to the one ST is running. Sometimes issues can arise by the end device trying to join another network, pulling your hair for nothing :wink: .

Cheers! :beers:

That config file is perfect! Your tip about the network strikes a cord, We
have zigbee power meters in my area.

1 Like

Well I don’t know how I missed this thread, but I did?

I have been having success with the regular XBee Pro s2c (I think that’s what I have, not near it right now)

I have been able to get it to join smartthings using various methods while in repeater mode.
I have 1 issue you might have an idea about, and 1 obvious question.

Question 1st, so once the XBee is joined to smartthings PAN, will it repeat / relay any radio traffic it receives or does it only dump the data out of the Output pin? It is not the programmable one you reference just the radio.

Okay now my stumbling block. I have been editing and communicating to the chip using the 32400 SUB interface board and my PC. When the chip is in the adapter board and plugged into the PC they radio will associate and join the PAN. If I use a regular 5v wall wart for power. The associate light stays solid blue. (Radio not associating) any ideas??

You can see my post in this thread where I posted more details

Hope to hear from you. You are obviously much smarter than me and my self education.

Hi @TN_Oldman!

Thanks! You are way too generous with your comments :bowing_man:

So I quickly glanced over the thread you linked and if I understood your goal correctly, you just want to use the XBee module as a range extender to your motion sensor end device and that’s it? If so, you just have to make sure to join a Router in ST as a “Thing”.

Your device based on the picture - a Non-Programmable XBee ZB SMT S2C XB24CZ7UIS-004 (ZigBee PRO 2007, HA-Ready with support for binding/multicasting) should be up to the task. Btw, if range and link quality is of importance, the Pro radios offer better range, altough the network graph shows that the link to the neighbouring router seems solid. But just for future shopping reference…

Router role will act as a valid router to all valid traffic within the PAN. I assume you are operating the module in API mode. The output of the radio depends on the AO parameter that is set on the radio but based on the direction of your question, the output of the radio will only be about traffic that is destined to that specific radio, you will not see other traffic being routed in the PAN in the output if that is what your question was about.

This does not make any sense, unless you have some sleep settings on the router that don’t kick in when connected to the computer via adapter. The radio should and must operate independently, it only requires 3.3V solid power and that is it. Speaking of which, would bee good to see your XBee’s XCTU settings.

If you have sleep setting set properly to 0, solid On associate LED indicates that The device has power and is operating properly

From the docs: “The Associate pin indicates the synchronization status of a sleep compatible XBee/XBee-PRO DigiMesh 2.4. If a device is not sleep compatible, the pin functions as a power indicator.”

Just out of curiosity, any particular reason you opted for the SMT module instead of the TH version?

1 Like

Only reason is because they were using that in the other thread, and I was lost in the sea of choices.

Thank you for all the information, I believe the 32400 USB adapter is the source of my connection / association issues.

My weekend project is to wire power straight to the radio out of the USB adapter. It should work.

I am confused about the associate pin. All this time I thought blinking meant it had associated to the PAN, different rates of flashing depending if it was the controller or repeater/endpoint. Of course my led is on the suspect USB adapter. So unless I wire a led circuit I’ll have no indication.

Thanks again for the reply, and your help.

I’ll let you know what I self educate and figure out this weekend, or I’ll be back with more questions.

1 Like

Had some time today, So here is an update of what I learned / figured out. I am making a few assumptions becasue I don’t understand the Xbee radio enough yet to know for sure.

Today I configured a new radio to connect to Smartthings to use as a way to monitor the status of the other radio I had previously configured. My first issue was the normal getting it to show up in smartthings as a thing all by itself with no interaction on my part. After tinkering with it I figured out my error. I had Parameter AO set wrong for my firmware. The correct setting was option 7 Explicit+ZDO. I knew that was the noun name of what I wanted but for some reason I got stuck on the settings I saw others using and selected the wrong one. After correcting that the radio would join smartthings as a thing all by itself. Soooo progress made!

Issue number 2 was the problem when I would plug the USB adapter the radio was mounted in into a standard USB power supply. The radio would never associate itself to smartthings and join the mesh. My associate led on the adapter would stay solid blue. The fix for this was yet another parameter set wrong. I had parameter D6 set to option 1 (Rts flow control) The correct option is the default of 0 (disabled). When this is set right the radio will connect like it is supposed to as soon as you power it up.

Here is a list of the settings I changed from the default. Most of them have been shown in previous discussions in various threads.

ZS = 2
NJ = 5A
NI = whatever you want to call the device I used Xbee1 and Xbee2
NO = 3
EE = 1 (Enabled)
EO = 1
KY = 5A6967426565416C6C69616E63653039
AP = 2 (API enabled with escaping)
AO = 7 (Exlicit+ZDO)
D8 = 0 (Disabled)

Be aware these numbers are going to move around and be in different places depending on the firmware you use. So connect to your radio in XCTU, update to latest firmware, and change your settings.

So after that I placed the repeater in my shed and let my current iris motion sensor connect to it. You can see it here in the XCTU scan. The XBee radio is green and the Iris motion sensor is blue.

I watched for activity repports in smartthings to make sure everything was talking. So far so good so I decided to see if my path to the coordinator (smartthings hub) was good by adding a second Iris motion sensor while I was in the shed.
It connected fine and was found by the hub fairly quickly. You can see it in this XCTU scan. The new sensor is blue the repeater is green. The original motion sensor is right below the new one in the scan.

The sensors were both talking to the hub as is evident by the reports in my activity log.

The only thing I yet don’t understand and it really doesn’t matter is when I do an XCTU scan from the XBee in the house it doesn’t show the 2 Iris sensors connected to the Xbee radio in the shed? The green item is the Xbee in the house and the blue item is the Xbee in the shed. Notice it shows no endpoints connected to it. When you do the scan from the Xbee in the shed it does show the endpoints as evidenced in the image I posted above.

Another interesting item is the radio in the shed chooses to connect to an Iris wall plug that is upstairs (directly above) my repeater. Even if I join them to the hub in the house they almost always pick the repeaters in the upstairs of my house vice the hub. My assumption is the signal strength is slightly better to that repeater as my upstairs is wood and drywall. Downstairs there is an extra layer of brick and possibly 1 extra wall.

Possibly if you need to get your signal outside, depending on house construction, it might help to put a repeater upstairs if outside is not available?

So there you go, I am going to continue to monitor the motion sensors for activity and see if my connection stays active. I’ll post an update in a week or so about if it keeps working or not.


Hi! Thanks for the update, seems you’ve made progress!

AO = 3 should also be fine as outlined by this Digi Support Article

The ND reports active neighbors it can find. I haven’t worked with ZigBee/XBee motion sensors but one possible explanation to this is that when you are doing the discovery in the shed, you are also triggering the motion sensors and the end devices will keep the connection up. When you run your discovery in the house the motion sensors stay sleeping. One way to test this theory is to keep the discovery going in the house and go have a walk in the shed…

Also a thing to note is that the time the base node waits for responses from it’s neighbors (which to report back) is controlled by the NT parameter value (default is 6 seconds). The base NT value is used from the module from which the ND (Discovery) is being run. The same value gets propagated throughout the network during the discovery. This means that if you have the NT value set as default to 6 seconds, every base node that gets the request to report back it’s list of neighbors only wait up to 6 seconds to hear back before timeout occurs. Remote devices wait a random time, but less than the NT, before sending their response. This safety mechanism is there to provide protection against transmission storms in large networks.

Absolutely, the signal propagation heavily depends on the materials around it.

This is beyond ST and ZigBee but it’s worth while to mention parameter JV - Channel Verification. This essentially ensures that the Router will stay on the same channel than the coordinator. If you keep this at default 0 and the coordinator for whatever reason appears on a new channel, the router will become isolated. My recommendation would be to set it to 1.

Cheers! :beers:


I also had time to play, I was able to use your very nice js flash utility and get my programmable SMT S2C blinking up a storm today.

If anyone else wants to know here is the header information difference from his blog above if you have a Grove Board.

I will be trying out your Zigbee HA program next! So awesome.


Hi @tgsoverly! Congrats on the blink storm, that’s awesome! Be sure to let us know what else you are working on… Just to clarify, which Grove board are you using? Is it one of the new XBee Grove Development Boards by Digi in cooperation with Seeed? I have one of those for the TH model but still haven’t managed to open the package… :wink:


That is indeed what I have. Those pins are for the build in LED. This tool
chain is so much easier than piecing together multiple other components.

1 Like

I see in your trigger script many print statements. How do you go about reading those with this tool chain? Do you have to hook up a different tool? Does that print over the serial interface?

Also, any chance I bricked my module? It was programming fine, but now simply won’t respond when I reset before programming.

Thanks! You are the best!

This is an update to this post.

Its been 11 days and the sensors connected to my XBee radio havent missed a beat. So today i went one step further with the experiment.

I took my XBee and stuffed it inside a solor charging light. I didn’t take any assembly pictures. I did grab one of the finished project.

I checked after it was mounted back up and it is back onto my zigbee mesh, and my motion sensor connected through it.

I’ll monitor it for awhile and see if it keeps working. If so I’ll post some pictures of what I did to put it together.

1 Like

Hi guys reading this thread with interest.

I have been trying to extend the range of my smartthings hub using an Xbee wall plug router.

I think it is now on the network as you’ll see from the last few posts in this thread Xbee extending .

But yet it seems to have made absolutely no difference to the range of my hub which is strange.

I just wondered if anyone could help ?

See the post here Xbee extending

I have read your thread before. Both of those members in that thread offered great advice.

As was stated in your thread, both devices (the plug and the sensor) have radios. Just cause the plug can reach out farther does not mean your sensor can reachback the same distance to talk to plug in module.

As was suggested in your thread, the normal fix is a plug in device close to the hub, and another plug in device next to your sensor. The signals then flow between the 2 powered devices (stronger radios) to bridge the gap from sensor to hub.
– OR –
A powered device next to your (low power) sensor that can reach the hub or another repeater in the house.

Hope that helps you.

If you’ve read and followed what I am experimenting with it might be a possible fix for your desire you expeessed in your original thread. I’m not really ready to share a step by step, because I am not sure it is going to work.
You could try something similar on your own. Pretty much everything I have tried and experimented with is in this and another thread that should be linked.

Hope that helps or that you do find an answer to your desire soon.

Hi @tgsoverly!

They are indeed printed to the serial console. If you are on Linux/Mac you can use the screen command to connect easily:

screen /dev/cu.whatever-the-grove-devicenode 115200

As much as I have tried, I’ve failed to brick mine. The reason for it being that updating via XMODEM upload, the Bootloader memory space is protected and not written to. Even if the upload does not complete, the bootloader and it’s code stays operational.

One thing to check is the baudrate you are running the command with. If you are using the Trigger code, it sets the module speed to 115200. If you are connecting using 9600 baudrate, the tooling is unable to properly communicate with the module and might not be able to get to the bootloader correctly.

I tried all the different baud rates and the same result. It is behaving
more like the reset button isn’t doing anything anymore. In XTCU it doesn’t
trigger the next step in reset either. Odd.

I also like that you have “tried” to brick it. Try harder! :slight_smile:

To be honest, I always had difficult times using XCTU to get to the bypass mode to be able to configure the radio. It simply was difficult to get to. So i’d still would retry with fwup.js to get to the bootloader menu:

./fwup.js -d /dev/cu.yourdevice -b 115200

If you are trying this repeatedly but fail to get the bootloader menu to show up, perhaps you still have the code that you were able to flash as the final payload to the module? I could then “try harder” :slight_smile:

And make sure the reset button is actually working! :slight_smile: If everything else fails, reprogramming needs to be performed using P&E debugger or a USB BDM multilink. But still… it’s just difficult to imagine you’ve outperformed me in bricking a module :smiley:

1 Like

Thanks @TN_Oldman so I left the Xbee Router plug near the smartthings hub (in the house) then plugged in a smartthings outlet plug near the sensor in the shed (about 55ft away)

But still not working. What am I missing ? :frowning:

You need to post your questions in your original thread vice hijacking this thread,

I already kinda hijacked it some. Hence just updates to the op so he can folliw my progress if hes interested.

I have no idea why its not working. I’ll read everything in your thread again and see if i can come up with something. I’ll post there if I do.

1 Like

Yea, I have tried that command many times different baud rates. I also had trouble getting the XTCU to work with these modules. It never worked totally, but did at least respond at various steps I have tried a different Grove board as well (to make sure the reset is working.

perhaps you still have the code that you were able to flash as the final payload to the module?

I did a git diff and the changes were what I posted above in the image, just a few header config changes.

The only other change (and I am not sure if it made it on the unit or not) but I was going to put a simple printf("here we are\n") statement in the period task to test the console out. Other than that is the same code. I don’t think it did make it on because screen isn’t showing anything.

You have any specific ones of these that you have found work on OS X?

You are extremely helpful and I really don’t want to be so needy, yet here I am! I promise to pay it forward and help field some of these questions when I figure all this out.

The only thing I can think that might have happened is maybe I killed (CTRL-C) the upload by accident. It is a habit of my and I am not sure if I did . . .