Zigbee Bind Questions with Xbee modules and the ST Hub

I’ve been writing an arduino program using the Xbee Pro S2C modules to integrate with the ST platform. I Have to say thanks to @JohnR for posting his previous propellar code as that has helped tremendously! I have most of it working, endpoints, attributes, things are turning on and off etc. but I’m having trouble understanding the Bind portion of things (in relationship to the ST hub and how it should interact with the arduino firmware for the application?) The Digi documentation for the modules has me slightly confused too because they kind of describe a binding table the each module has. Does this mean the ST Hub sends a bind command to the xbee module (I’m assuming for ZDO cluster end device bind 0x0020, and/or ZDO bind on cluster 00x21.) So it it possible that Digi module takes care of the bind table, or does the application have to take care of the binding?. Just wondering if @JohnR or anyone else had time to explain what they may have found with the Xbee modules or if anyone has a portion of code I could review to see items that take place for bind/unbind in the application firmware?

Binding is where you really see the difference in the various versions of Digi’s xBees. Binding is supported on the xBee SMT (surface mount) version as the older though hole versions don’t have the processor / memory to support binding. I always use the SMT version of the xBee in all my projects. I solder pins to the outside of it making it pin compatible to the through hole version so it just plugs into the same socket.

Once you have the correct xBee to setup binding is a bit unique compared to the other ZDO packets. The xBee SMT takes care of most of the binding commands. Your SmartThigns device handler should send bind commands during the initial join process and they are often held in the configure method. Here is the configure method from my CoopBoss.com device handler. The configure method is called when the device is configured during the join process. In the following example you can see I’m binding 2 clusters on 3 end points. When the xBee SMT receives these commands it creates a binding table automatically. Your microcontroller doesn’t have to do a thing. The xBee does not pass the binding commands through to the serial port like it does with most ZDO commands.

def configure() {
    log.debug "Binding SEP 0x38 DEP 0x01 Cluster 0x0101 Lock cluster to hub"  
    log.debug "Binding SEP 0x39 DEP 0x01 Cluster 0x0402 Temperature cluster to hub"      
    log.debug "Binding SEP 0x40 DEP 0x01 Cluster 0x0402 Temperature cluster to hub"      
    def cmd = []
    cmd << "zdo bind 0x${device.deviceNetworkId} 0x38 0x01 0x0101 {${device.zigbeeId}} {}"			// Bind to end point 0x38 and the lock cluster
    cmd << "delay 150"
    cmd << "zdo bind 0x${device.deviceNetworkId} 0x39 0x01 0x0402 {${device.zigbeeId}} {}"    		// Bind to end point 0x39 and the temperature cluster
    cmd << "delay 150"
    cmd << "zdo bind 0x${device.deviceNetworkId} 0x40 0x01 0x0402 {${device.zigbeeId}} {}"    		// Bind to end point 0x40 and the temperature cluster
    cmd << "delay 1500"    
    log.info "Sending ZigBee Configuration Commands to Coop Control"
    return cmd + refresh()

Now that you have your xBee bound to the hub your microcontroller can send to the bound device by using the xBee’s indirect addressing. Since you have been working form my Propeller code maybe this screen shot will help. In it you can see I’m reporting a 32 bit unsigned Int Value to the addresses bound to end point 0x38 and cluster 0x0101. The code doesn’t have to worry about the destination IEEE address or the network address as that is all taken care of in the xBee’s binding table.

Once you have all this working it adds some extremely powerful features to your device. For example your device can be bound to multiple ZigBee devices and your code still just sends one command to send to all those devices at one time. This can be used to bind a switch directly to a light without relying on the SmartThings hub. Very fast response!!

Hope this helps!!

1 Like

Thank you very much @JohnR. That helped a bunch on clearing things up with the Xbee Module and the ST Hub. I was curious why the Xbee didn’t pass that through, but now it makes much more sense. Especially along with the indirect addressesing method.

One last question, do you ever have to worry about an “UnBind” command? Not sure if ST even has that, but I believe Digi has the “&X” Command which states that it clears the binding table on the module.

I will work this new information in and test it out! Much appreciated…

When you instruct your xBee to leave the ZigBee network it will erase the binding table. So I haven’t had to fool around with removing any bound devices.

One cool thing to note on binding. Up to this point we have been talking about binding a device to the hub with a bind command from the device type in the cloud. Did you know there is also a way to bind two devices together without any custom code required in the cloud?? The xBee SMT supports this type of end device initiated binding and I have used it in the past with my SmartThings hub. Basically if you have two devices that have compatible clusters they can be bound together by simply pushing a button on each device in the proper sequence. The SmartThings hub really is doing the binding but nothing is required from the cloud. So lets say your device supports the switch client cluster (battery powered push button) and you want it to be directly bound to a switch server cluster (power outlet) you can do this by putting both devices into end device bind mode. The SmartThngs hub listens to these request and will send the bind commands to each device to bind them together if their clusters match. So freaking cool and very rarely used or talked about!!

Oh yes on the leave the network, that would make sense. I did read about the end to end Bind, but haven’t had a chance to experiment with that yet. But it does sound very fun! I did get the code put in there (thanks for letting me see) as I was wondering if it was suppose to use the Command 0x0A for reporting (From Zigbee spec). It does appear to be working as I can see the data coming in through live logging. I experimented by sending a “&X” to the module while running, and behold, no more data was being logged in the ST debugger. However I got a question for you, the only thing coming in the logger (when it is binded) is = “1st parse description: temperature: XX” [With XX being the value sent at that time]

However I noticed if i do an attribure read on that cluster i then get a "SmartShield(clusterId: 0x0402, command: 0x01, data: [0x00, 0x00, 0x00, 0x29, 0x12, 0x00], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0x0104, senderShortId: 0x9e4c, sourceEndpoint: 0x38, text: null) Data Frame. (which is very useful for parsing data and getting it back for display)

Is the 1 line description parsed with just the temperature normal for what is sent in your experience when an endpoint is bound or do I have something messed up in my parse. Thanks in advance

I think what your seeing is normal operation based on how SmartThings handles some ZigBee reports:
For some clusters (the temperature cluster is one of them) SmartThings intercepts the report packet and re-formats it before passing it to the parse method. When they do this they strip out the source endpoint so if you have multiple temperature probes on unique endpoints you don’t know where the report is coming from. This is a known issue and the ZigBee guys at SmartThings have it on the list to fix last I heard. Its a bit frustrating they were trying to make it easy for developers but sure stripped away a lot of good information!!. If you only have one temperature probe per device you will be fine. In my case I had two and had to implement a workaround of only reporting one probe and polling the other with a read attribute command.

Thank you for that insight. I might have been pulling what’s left of my hair out if I didn’t know that! Because I wouldn’t have known what the problem may have been. (It sometimes gets difficult when you are doing firmware on one side, and the whole “Groovy” language is new to me anyway for the other side). I will keep that in mind when parsing the data moving forward. Regardless, I still love the ST Platform, it makes it really easy to develop new things and gives you great access into items and the flow of information. I’m sure it will continue to get better. I must say, you’ve been extremely helpful and I much appreciate the information and help on these matters. Thanks!

1 Like

I wanted to post a little update on “Attribute Reporting” from what I found last night testing. If you do send an Attribute Report Frame Back with Indirect Addressing for the Xbee, and if you change the Zigbee Command from 0x0A to 0x01, then ST Hub does display all the packet and cluster information (which is useful for parsing) At least that way I can tell which cluster id came from. Maybe a good interim fix until they get that fixed. @JohnR I wanted to also ask you what you would suggest using for a cluster ID that reports back items like “Door open/close” switches or spare inputs that detect on/off transitions (i.e. inputs to micro that then get sent back to the ST Hub) Do you use something like that on your system that you can advise on?

When my device has data or commands that don’t fit into an existing cluster definition I often will use one of the reserved attributes for vendor specific data of the main cluster. For example if your device uses the On/Off cluster there are attribute numbers in the spec that are reserved for “vendor specific attributes”. Just pick one of those attribute numbers and the correct data type and you will be good to go.

I realize this is 6 months old, but I just wanted to say that I have a through hole XBee and it appears to support binding just fine. Specifically, I have this one: https://www.digikey.com/product-detail/en/digi-international/XB24CZ7PIT-004/602-1557-ND/5322371 I was going to go with an SMT one but realized it actually doesn’t save any space on a board, and with the through hole I can put components under it. I may eventually go with one, anyway.

I’m working on an Arduino/XBee ZHA library, and had initially set up the attribute reporting to just broadcast until I had written up a binding table. Found this thread, and switched the transmit to indirect and changed the addresses to invalid ones, and the attribute reporting still works.

Thanks for the info here! (And in lots of other zigbee threads here. You’ve really helped me make sense of what’s required.)

1 Like