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.
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 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!
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
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:
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)
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?
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:
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?
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.
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.
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.
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.
Just thought to share that XBee S2C is now considered a Legacy Digi product succeeded by XBee 3 The good news is that all of the modules seem to have HCS08 on board, making all of them programmable. That’s awesome!
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.
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)
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:
You can write MicroPython directly via XCTU, there’s a special MicroPython terminal included.
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.
Code is executed directly on the EFM32 chip
HCS08 is not in the picture when it comes to MicroPython
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)