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

Devices & Integrations
1

Prelude and Background

As I’m a new member and this is my first topic, a bit of background is in order. I have fiddled with HA for a while - starting with X10 based stuff and a Mac driven Hub running Indigo Domotics. Over the years I’ve tried and tested too many to name different systems and solutions as well as built my own based on the actual need. I’ve always been impressed by what SmartThings was and tried to achieve so I decided to quit lurking around and bought one to drive some Z-wave devices. It seems like a great Hub that suits well for different type of commercial devices as well as allowing the DIY crowd integrate their own masterpieces with the system. Another reason for me to choose the SmartThings hub, was the awesome community around it! :wink:

Thus far, things seem to work great - I love it. :smile: As I have a custom XBee network running with devices, I started to look into the ZigBee device handlers and saw that there seems to be some interest in the community to integrate these DIY modules to work with SmartThings.

Couple of topics I’ve seen covering this:

  • Do myOwnThing - Connect my XBee Radio to the Hub?
  • XBee S2C with Arduino & SmartThings

So some work has already been made to integrate XBee based systems with ST. This is great! :sunglasses:

I made this topic about connecting/integrating Programmable XBees with SmartThings in hopes that there are others interested in this topic besides myself.

Programmable XBees

There is a special breed of Digi XBee modules that come with a HCS08 CPU alongside the EM357 tranceiver. These modules cost ~3€ more than the standard S2C Pro radios and what this potentially means, is that you can have the ST Hub and the XBee module working together without any additional Arduino, Raspberry or some other developer board connected to it for application logic.

  • It overall reduces cost for the project
  • It can substantially reduce the footprint of device
  • It can save power (the added HCS08 is a low consumption 8bit CPU)

I’ve written a longer blog post about these modules and how to get started if anyone is interested. But official documentation is available from Digi.

PXBee Trigger

In 2016 I was looking to automate my swing-gate that unfortunately is a “dumb” device. Like all such previous-generation automatons, it has a pin out for operating it using an external impulse switch or a device. Meaning, you can short-circuit 2 pins to operate the gate either to open it or close it. Thus, the Trigger project was born. I used a Programmale XBee module connected to a relay to connect the pins for 125ms and in general it works great. :sunglasses:

Now, I’ve updated the code for it to work with SmartThings with the default ZigBee device handler that can be created via the Web IDE.

Some of the goals:

  • Use the default ST device handler for ZigBee HA profile (ZigBee Switch)
  • Implement HA profile 0x1004 Cluster 0x0006 (On/Off switch)

Trigger does not stay in “On” state, it currently only shortly operates the relay (125ms) and returns to “Off” state. but the code can be easily changed for it to operate as standard relay switch.

fingerprint profileId: "0104", inClusters: "0000, 0006", manufacturer: "PXBee", model: "Trigger", deviceJoinName: "PXBee Trigger"

As of now it’s a working prototype. I do have a problem that when you turn “On” the device from SmartThings app it stays in “TurningOn” state. I haven’t figured out the proper signalling ST expects to report the state change. However, if you refresh the mobile app GUI the state is read back successfully and it doesn’t affect operating the device.

If you feel interested, try it out. Feel free to use the project code as an example how to pair with the ST Hub and how to implement other HA Clusters for other device types. Even more importantly you can look into the Programmable XBees for all kinds of project logic so you can free up all those Arduinos and other boards currently connected to the radios :wink:

Cheers! :beers:

NB! As I’m a new user, I was limited only having 2 links in this post. Sorry about that!

11 Likes
2

This commit fixes the above described problem: Reporting back proper state changes · exsilium/pxbee-trigger@77311cb · GitHub

For future reference, when On command is given via the mobile app and the state is transitioned to turningOn, SmartThings strongly expects back “On” confirmation. Because my project works as a trigger and always returns back to Off state, this report was not accepted by SmartThings and the state was stuck to “TurningOn” until GUI was refreshed. The solution is to send back both state transitions with a small 1 second delay in between.

  1. Issue “On” command from mobile app
  • SmartThings fires the command and updates the App GUI to “Turning On”
  • Trigger is activated and Attribute Report (0x0a) is fired back stating that the switch state is “On”
  • SmartThings App GUI changes device to “On”
  • Trigger delays for 1 second and fires another Attribute Report (0x0a) stating that the switch state is “Off”
  • SmartThings App updates the GUI immediately to “Off”
1 Like
4

Hi! Glad that you like the project and I’m super excited to know that there are others like yourself who are also working with the Programmable XBees - I hope we can share and learn from each other! :wink:

In short to answer your question - I’m not sending the 0x13 (Device announce). If you have an unknown device that has joined the same network (You have the radio settings done correct and the device has already established and joined the PAN), the Active Endpoint Request (0x05) gets sent when you select “Add a thing” from the Smartthings mobile app without ever announcing the device to begin with.

Although now that you mention it, if that would be the correct way of doing it - i have to look into it more. Does this mean that the device can announce itself to the Hub without going into the “Add a thing” mode?

Majority of the ZDO stack is handled by the XBee SDK (apart from the device announce), are you sure you are not receiving 0x05 from the ST Hub? Have you enabled logging from the Xbee side or how are you capturing the packets? Also make sure that the the radios AO parameter is set to 3, otherwise the ZDO packets will not be passed on to the HCS08 CPU but handled by the XBee radio instead.

If you haven’t already, I suggest you enable ZIGBEE_ZDO_VERBOSE when compiling the project, this outputs the ZDO frames to the serial console.

This is one example of the packets in the ZDO layer I received when I click the “Add a thing” from ST:

  • received ZDO clust=0x0005 (Active Endpoint Request) (Programmable XBee might ignore the request on the first time when the my address is unknown)
  • received ZDO clust=0x8001 (IEEE (64-bit) Address Response 0x8001
    ) (XBee SDK seemed to ignore this as unsupported)
  • received ZDO clust=0x0005 (Active Endpoint Request) (Programmable XBee sends back the cluster endpoints)
  • received ZDO clust=0x0004 (Simple Descriptor Request) (This gets received to each active endpoint that was previously sent back to ST)

After this the messaging goes to ZCL layer.

Let me know how your project progresses and consider sharing the code for it! :beers:

5

Hi

I’m a UK based super newbie so please go easy on me. I am trying to extend my Zigbee range (smartthings router is in the middle of our house) to reach the shed at the end of my 40ft garden so I can use Smartthings sensors in it. Ive tried putting a smartthings plug in outlet by the door to the garden (it connects to the smartthings router fine here) to boost signal, but had no luck.

The shed has power and wifi but I don’t think that’s going to help so prob not relevant.

I know I could put another router in there but I’d like everything to be in the same smartthings location so that wont work.

Anyway. I’ve bought a 3 pin plug in to the wall Digi XBee 888-XR-Z14-CW1P3 extender in the hopes that it will do the trick of extending the network.

Can anyone advise if I need to do anything special to it to get it to work?

6

Hi @Milomolly!

It’s not helpful if you keep cross-posting your question to all available threads in hopes of getting help. But the mentioned wall router acts as a standard XBee Pro and is meant to extend XBee networks. Although technically you can use it to extend the network range of SmartThings’ ZigBee network, you’d need to first configure it accordingly. With the default settings that are on the device, that is not going to work. To configure your wall router, you’d need to have a XBee device connected to your computer because the wall router doesn’t have any other wired interface options.

I don’t own a wall router like that but to my understanding you’d roughly need to go through the following steps:

  1. Get an Xstick or XBee module with an USB shield connected to your computer.
  2. Using XCTU, create a new unencrypted XBee network.
  3. Commission your wall router to join this new network.
  4. Using XCTU, configure settings on the remote wall router that would make it work with SmartThings. - I think this blog post covers this topic in great detail. You don’t need to have a device driver from the ST side nor announce the device. As long as you are able to set the basic parameters for the radio so it is able to join the same network, ST adds the router as an “Unknown” device. It’s enough for it to act as a router in the same network.

The good news is that there are others who have used the said wall router to extend the range of an encrypted ZigBee network. The bad news is that you need a computer interfacing XBee to be able to configure that router. It also looks like (based on the Digi forum) that If you don’t mind losing the warranty, there seems to be a standard socketed XBee in that wall router, so one option would be to use an USB interface to set the configuration directly.

If you don’t want the challenge, you might consider just getting a ZigBee HA smart plug that usually also acts as a router.

On a side note, In the past I’ve purchased some drop-in XBee sensors from Digi and apart from the nice outer shell I was not impressed.

Cheers! :beers:

7

Thank you for your super helpful reply. Im going to peruse in detail in a sec but just wanted to Ask:

You mention getting a 'ZigBee HA smart plug isn’t that the same as the smartthings outlet I mentioned I already tried, or do other makes of them work better as extenders?

Also I think you propose I might be able to open up my wall plug and use something to connect it straight to my computer in order to configure it. Doyou know what I’d need to buy to do this?

Thanks again for your help

8

Also, if I buy an xstick I guess I get the 804. 15.4 version https://www.digi.com/products/models/xu-a11to match the router, rather than this version https://www.digi.com/products/models/xu-z11?

9

Yeah, I guess my point with that was to find a model that has a better antenna/transmission power that would cover the range you need. They all do perform differently. Maybe there’s one that has an external antenna for better range.

If the forums is to be believed and there’s a standard XBee module in there, you’d just need something like this

You definitely would need the ZigBee version. The 804.15.4 Xstick is used for the older XBee Series 1 radios and they are not compatible with XBee-PRO / Series 2 / ZigBee stack.

10

Thanks.

Ok so you are saying I need this xstick : https://www.digi.com/products/models/xu-z11

And that will definitely work with my xbee wall extender : http://www.mouser.com/search/ProductDetail.aspx?r=888-XR-Z14-CW1P3

Even though the extender says 804.15.4 on it?

11

Yes, don’t forget to send a thank you card to Digi for making their product line super-confusing. Still, if you open the datasheet for XU-Z11 it states that:

Two versions are available. The XStick 802.15.4 version is compatible with Digi XBee and Digi XBee-PRO® 802.15.4 devices and uses a fast multipoint network. The XStick ZB version is compatible with Digi XBee or Digi XBee-PRO ZB devices and utilizes the ZigBee PRO Feature Set for robust mesh networks.

If you open the datasheet for your wall router you will notice that you have the latter - Xbee-Pro ZB. The series 1 or non ZB variant is incompatible and would not work with SmartThings.

Sparkfun also has an outdated buyer’s guide when it comes to XBee variants if you want to confuse yourself even further :dragon:

Cheers! :beers:

12

I am super glad I found this thread and I am interested in just this type of thing. I also have to say +1 for your compiling inside a docker container, so much more reproducible. I have ordered my S2C chips now that I know this is out there.

Have you done any exploratory work with XCTU and the S2C chip to have it join the ST network? I was playing around and just can’t seem to figure out the right combination of knobs to make it work like the falco.nz blog post that other people reference. If you have would you mind sharing your configuration file?

1 Like
13

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:

14

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

1 Like
15

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.

16

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
17

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
18

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.

2017-11-01_13-14-16
2017-11-01_13-14-16.png650×613 27.7 KB

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.

2017-11-01_13-18-15
2017-11-01_13-18-15.png654×596 17.2 KB

The sensors were both talking to the hub as is evident by the reports in my activity log.
testmotion
testmotion.png1080×1920 220 KB
shedmotion
shedmotion.png1080×1920 210 KB

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.

2017-11-01_14-29-31
2017-11-01_14-29-31.png668×580 23.1 KB

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.

5 Likes
19

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:

2 Likes
20

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.

57 PM
Screen Shot 2017-11-09 at 9.00.57 PM.png1008×1116 112 KB

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

2 Likes
21

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:

Cheers!