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

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

Sad to hear you’re having trouble. Where are you from btw? I’d be willing to buy this b0rken module off for some further study :slight_smile: I don’t think I have any solid advice I’d be able to give you based on the information provided. Programming the modules without a dev-board relies on a working bootloader. It’s hard to say what may have happened that rendered the bootloader inoperable.

However, if you want to take the red pill and see how deep the rabbit hole goes, your best bet is to purchase a P&E debugger from eBay and use it via Parallels/Windows/Codewarrior to reflash the bootloader :slight_smile: Best to my knowledge there are no native OS X tools in place for that… You should be able to accomplish programming without the actual XBee dev-board. Just see this schematic on how the programming header is connected to the XBee.

Or well, take the easy way out and order some more XBee modules :smile:

1 Like

Yea, I am probably just going to bye some more modules! I am totally going to take the easy way out. I might also get a PR for your loader to ask if you really want to terminate the process, to keep me from doing this in the future! I bet that is what I did … somehow.

I am in the Ohio, USA so probably not worth the shipping to Estonia? I saw that on github I think.

You have that right… Slipping the module in a bubblewrap envelope via airmail shouldn’t be much. Let ne know if you’re up to it via PM. I can pay via PayPal.

Waiting for that PR, blocking termination once upload has started is a good idea! :wink: I’ll also put some extra information together how to program the modules with a BDM without using the Dev board. :+1:

Has anyone else managed to get pxbee-trigger going with a programmable XBee (XBP24CZ7WITB003) (pxbee-fwup.js to flash the image)?

The radio is configured according to all the linked guidance but (according to the serial output) the RX callback xbee_transparent_rx() and custom endpoint (custom_ep_default_cluster(), custom_ep_rx_cluster()) are never triggered.

The XBee starts with OI value 0xFFF and Device Network Id (MY) value 0xFFFE. After initiating “Add a Thing” from the hub (via the iOS app). I get a joined to network notification (after adding the define ENABLE_XBEE_HANDLE_MODEM_STATUS_FRAMES), and a valid Network Id (MY) value is set.

Note: For whatever reason reading the operating PAN ID (OP) always times out “ATOP (timed out)”.

I’ve created a device handler in the SmartThings WebUI (as I can’t seem to just add one from a fingerprint). I’ve also added a New Device under “My Devices” using the handler and specifying the “MY” network address. After this I can send ON/OFF requests via the iOS app which trigger the RX status light on the XBee. However, no RX or endpoint callbacks are called.

Sorry for the rambling post, but I just can’t seem to get this going. Any advice would be appreciated.

Hi @gazor!

You need to add the correct fingerprint prior to joining the module to the network (Zigbee Switch device handler). Do not add the device manually, just set the handler prior join:

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

This ensures that the correct capabilities of the trigger will be read during join and that the ON/OFF signals are actually sent to the correct endpoint/cluster. If it’s correctly set then during the join, it should show right away that a new “PXBee Trigger” device has been found.

You can rejoin by:

  1. Deleting the “Thing” from the SmartThings
  2. Resetting the network settings on the Xbee. Having connected via serial, pressing 0 - (Local network reset)
  3. Add a thing via SmartThings again.

Let me know if that helps. Cheers!

Thanks so much for the prompt response and for all of your work!

I’ve tried following the steps and still have the same results sadly.

In more detail:

I created the device handlers on graph.api.smartthings.com and navigating to the hub.

(i) Creating the device from the “From ZigBee Device Fingerprint” tab, filling in the values your values under the application profile “ZigBee Home Automation (HA)” and ZigBee Device “ZigBee Switch”. This gives the error message:

Org.springframework.security.access.AccessDeniedException: Run Locally Permission not allowed for DeviceType: ca273472-1826-4fa1-b85e-7c8987364309

(ii) So I resorted to create the device handler “From Template” based on “ZigBee Switch” I’ve changed the definition (removing executeCommandsLocally and adding the fingerprint). I can export and paste the code if it needs verification.

Ultimately, the ZigBee joins the network but no devices appear in the iOS app.

I’m surprised I’m not seeing any output from building with “#define ZIGBEE_ZDO_VERBOSE”.

Hi! Can you possibly post the full device handler code that gets created? I can compare this to mine.

It’s odd that you don’t see more messages after the set define… can you perhaps get the module to bypass mode and check that the AO parameter is set to 3 to passthrough all the ZDO messages to the HCS08 CPU?

It’s a bit of a mystery, AO is 3 (from XCTU in bypass mode, and checking within the modified trigger code). It does seem as if a parameter is wrong, my firmware ZIGBEE TH PRO version 4060 is different, or somehow the config isn’t taking.

I’ll private message a link to the device handler. Thanks again!

Hmm, I’m still on 405E, I need to upgrade to 4060, to see if that has any impact when joining SmartThings network.