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

I didn’t see anything obviously wrong with your code. I would triple check (in XCTU bypass mode) that setting “AP” to 1 took hold. When running your own code, dumping out “MY” is a good indication that you have joined the network (if it changes from 0xFFFE). I’d be interested if you see any timeouts retrieving “OP” or otherwise.

Regarding the commissioning pins etc. being commented out, that shouldn’t make a difference. I did resort to enabling them and grounding the pin to no effect.

@exile is likely to update pxbee-trigger to use the local device handler shortly.

1 Like

What do you mean by default values? If the additional value settings don’t work then there most probably is some mismatch between the values. Setting XBee radio settings to default via XCTU should not work, because the encryption settings, ZS stack and other such are not compatible with ST.

Can you also try setting the XBEE_ATCMD_PARAM_ID to the PAN your ST is operating in xbee_config.h?

Firstly, I’d like to give a big shout-out :clap: to @gazor for the local processing patch and additional testing effort that he made based on my speculation how SmartThings might do device handler matching based on the fingerprints in the hopes of not having to spoof the identifier. Thank you, that was awesome! :bowing_man:

Still, in the end, to gain compatibility for local processing means abandoning custom device handler and for that, we must spoof the device identification, which is not perhaps the most right thing to do, but hey, this is for the DIY crowd :man_shrugging:

The Trigger project was updated. For the local processing to work, set the ZCL_MANUFACTURER and ZCL_MODEL defines prior to compilation in custom.h as described in the comment block:

Cheers! :beers:

Hiya - thanks much for this - just used your list of parameters to tweak a profile for an xbp24-zb and it suddenly started working and mapping- yay! (my first time - so a nice feeling)

2 Likes

I have checked in XTCU that AP is 1. The only param that I can check is the key value. AO is set to 3. Do you also have lots of options for AO?
39 AM

Is this what you see and what you selected?

@exile In addition the encryption is off in xtcu and it will join the network as you can see in the next screen shot the device has joined the PAN but without encryption:
24 PM

Sorry about the delay. I wasn’t sure what you meant by only be able to check the key value. I have exactly the same options as you for param AO.

It’s interesting that you were able to join the network but that encryption is not enabled (EE and EO must be 1 and KY must be 5a6967426565416c6c69616e63653039). Are you actually able to “Scan” in the “Network working mode” and see other SmartThings devices on the network?

Here are some of my settings:

settings

2 Likes

Likewise to @gazor, I’m baffled you are able to join the PAN without encryption - it’s required by the ZigBee HA profile. The current settings are way off.

#define XBEE_PARAM_ZS       2
#define XBEE_PARAM_NJ       0x5A
#define XBEE_PARAM_NH       0x1E
#define XBEE_PARAM_NO       3
#define XBEE_PARAM_AP       1
#define XBEE_PARAM_EE       1
#define XBEE_PARAM_EO       1
#define XBEE_PARAM_KY       "5A6967426565416C6C69616E63653039"

Everything besides the KY parameter you can check via XCTU that they are the same. Besides the encryption, ZS stack profile needs to match up with SmartThings (2).

Altough not required, I’d recommend turning on JV (Channel Verification). If you are constantly resetting the Xbee radio, it makes sure that the channel used is the same as the one coordinator (SmartThings) uses.

1 Like

OMG… I spend a decent amount of time debugging this today and finally figured out what it was after trying lots of stuff you pointed me in the direction. I had taken this line out of the console reader in my code:

My guess is it was in a loop of some kind. I thought h was for help, so embarrassing.

1 Like

Does anyone have an example of broadcasting the “on/off” state when it isn’t in response to a command. Like a normal switch would send that state when it was turned on or off at the device and not from a ZCL command.

I looked through the SDK, but didn’t see anything obvious.

You still send a ZCL_CMD_REPORT_ATTRIB command even if the event was triggered externally.

Thanks! The command name with “response” in it made me think it was only
for direct requests.

Just thought to share that XBee S2C is now considered a Legacy Digi product succeeded by XBee 3 :vulcan_salute: The good news is that all of the modules seem to have HCS08 on board, making all of them programmable. That’s awesome! :sun_with_face:

BAse on what I see that is only a chip. What would you need to but, for the US, to put this in play as a ZigBee repeater

They still offer the XBee3 in TH and SMT configurations for easy migrations from S2C. Similarly to S2C, one would just need to configure it as a Router, join the ST network and it should also work as a repeater in the network. I need to order couple of them to make sure the interoperability is still there… it’s exciting as it has been a while since Digi introduced any new XBee modules.

I’ve raised the interoperability question with ZigBee HA networks via Digi forums. :crossed_fingers:

It also appears that you can do micropython right in the chip. Which is
much nicer.

Digi.com is really thin on the details though. Although the MicroPython promise seems interesting, it’s something I’d expect to be running on the EFM32 chip, not HCS08. I guess we’ll hear more on the Embedded World 2018 event (27 February - 1 March)

I bought the items in this list, you may not need or want all that. It’s an old list too, so possibly better choices available.

I have posted in this thread and the thread I linked to about my adventures creating a repeater out of the parts I ordered.

I have one in my shed and it has worked well.

For anyone interested, here is more info about MicroPython in Digi’s products (Programming Guide). It also includes plenty of examples.

There’s also a blog post about it.

Within the guide, they are referring to their Cellular Modem products, but there’s no doubt that the XBee3 ZigBee radios will function similarly and provide the same overall development experience.

Some quick takeaways based on that:

  1. You can write MicroPython directly via XCTU, there’s a special MicroPython terminal included.
  2. There’s a special AP mode 4 which puts the radio to MicroPython REPL mode. (Read–Eval–Print Loop), evaluating the code as you type. But there are other modes like flash mode where a block of code gets flashed to the device right away.
  3. Code is executed directly on the EFM32 chip
  4. HCS08 is not in the picture when it comes to MicroPython
  5. The documentation does not indicate if the MicroPython code can be updated remotely. All the examples are for local execution only (radio must be attached via serial to the computer running XCTU)

I ordered one to play with, should be here soon!

1 Like

Which model did you end up getting and from where? Can you add a link to the site?