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

exile · January 1, 2018, 7:48pm

A bug found and squashed! Thanks @gazor for taking the time to test this out thoroughly. The interactive menu option for setting additional XBee settings was incorrectly setting AP to 2, instead of 1. Fixed in https://github.com/exsilium/pxbee-trigger/commit/94ebc21fb5e3b027a581d49607d81013b77a601b

Cheers!

tgsoverly · January 11, 2018, 2:49pm

Gazor,

I ran into the very same issue. Could you paste the code that you got working for confirmation?

Thanks!

gazor · January 11, 2018, 6:53pm

@exile is probably your best bet for troubleshooting but I’ll try help.

Adding a device is a rather finicky process, part of my problem was the radio settings. My settings were based from the trigger code option [2] (“AP” was wrong, it must be 1).

I’m a little weary to post the device handler because of the copyright notice. I’ll describe the steps though. Under graph.api.smartthings.com, navigate to the hub, and then “My Device Handlers”. Click on “Create New Device Handler”, “From Template” and select “ZigBee Switch”. Under the metadata definition remove “, runLocally: true”. Then add a new fingerprint line:

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

You should then be able to “Create” the handler. I’ll also message you the code.

I have modified the trigger code to print out the Network Address “MY” (rather than “OP”) as an indication of having joined the SmartThings network. The join process is:

Check the SmartThings app and remove device if added previously (as a “Thing”);
Turn on the XBee and open up a serial connection;
Press [0] to reset the network;
Observe the “MY” parameter whilst adding a device in the SmartThings app. It should change from 0xFFFE to an assigned (random) number (provided your parameters are correct);
The XBee should then appear in the SmartThings app.

As an addendum, I was experiencing pretty high latencies (1 min) when triggering my XBee from a SmartThings motion sensor. Due to the use of a custom device handler running in the cloud rather than locally. I have since modified the trigger to support inClusters “0000, 0003, 0004, 0005, 0006” and use the device name “Leviton ZSS-10”; removing the requirement to add a custom device handler and allowing local switching.

tgsoverly · January 11, 2018, 7:01pm

Thanks for the reply.

I am in the process of upgrading firmware, so I am on the same version as you too.

If I understand correctly this means that you are using a build in type which allows it to run locally because it has been approved and and included on the device. That correct?

When you say you are using the name “Leviton ZSS-10”, where is that done? I assume that some kind of handler is responding with that name on the device.

Is it possible to share your code? I really do appreciate your help.

gazor · January 11, 2018, 7:40pm

You should be fine with slightly older firmware.

The changes are effectively spoofing the fingerprint in the inbuilt, local, ZigBee Switch device handler. I only made some minor changes to the trigger code, the part where the basic cluster handler returns the manufacturer name and model identifier, as well as the custom_ep_clusters table to add dummy handlers for the other inClusters.

I never had latency issues triggering the device directly from the SmartThings app and perhaps the problems were due to temporary connectivity or service issues. It’s worth trying with the custom device handler as the current trigger code has been tested much longer.

Happy to share my changes but let me talk to @exile first, there’s probably a good reason why an existing fingerprint isn’t used.

tgsoverly · January 12, 2018, 8:24pm

I have gotten stuck at the same place gazor has gotten stuck.

Here is my code that I have been working on: https://github.com/Root-App/pxbee-open-close/tree/join-network

note the branch is join-network

The main difference between the original trigger code is:

It has been broken into different files.
It is converted to the SMT version of the chip with its different PIN outs.
We read an open/close sensor to then correspondingly turn on/off the LED (this works).

Couple Notes:

If I reset the ZigBee module to the defaults (using XCTU) it basically immediately joins the network. I can then open a serial connection and confirm that it has joined the network.
If I write the additional values, it won’t join the network and always remains on default values.
I have tried AO 1 and 3.

I never seem to get the default handler/rx handler/or transparent handler are never triggered, just like @gazor said above. I have also included the device handler right in the repository and that should show some information on things I am trying.

I get the same response with the original trigger code that I changed the pins to SMT.

I am not sure why certain pins in the original trigger code are disabled and what that does. I am not sure what else to look at but any pointers would be so nice.

I have mostly just copied and poked around: I have found this link which I think @exile did as well (you are great) https://www.digi.com/support/forum/46911/how-to-use-built-in-xbee-programmable-zdo-zcl-support .

The part that sets up the response handlers is kind of confusing, not sure why it is in the “custom” section, and some of it is in the main.c. The documentation seems thin from the SDK.

gazor · January 13, 2018, 6:16am

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.

exile · January 16, 2018, 8:32pm

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?

exile · January 20, 2018, 7:34pm

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:

github.com

exsilium/pxbee-trigger/blob/9c90a7972bd4b36040c0f1d27d39095ae1c1e8f3/include/custom.h#L22


      
          #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"
          
          /* Reported manufacturer and model in basic cluster
           *
           * For SmartThings local execution without custom device handler, set the following:
           * - ZCL_MANUFACTURER "Leviton"
           * - ZCL_MODEL        "ZSS-10"
           */
          #define ZCL_MANUFACTURER    "PXBee"
          #define ZCL_MODEL           "Trigger"
          
          /* Ignore On command received via Broadcast message */
          #define PXBEE_TRIGGER_IGNORE_BROADCAST
          
          /* Settings END */

Cheers!

AlecM · January 20, 2018, 9:29pm

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)

tgsoverly · January 28, 2018, 4:39pm

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

gazor · January 30, 2018, 3:26am

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

exile · January 30, 2018, 8:53am

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.

tgsoverly · February 3, 2018, 6:30pm

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:

github.com

exsilium/pxbee-trigger/blob/master/src/main.c#L548


  xbee_cmd_execute(&xdev, "WR", NULL, 0);
  printf("Done!\n\n");
}
else if(option == 48) { /* 0 */
  printf("\n Resetting Network\n");
  xbee_cmd_simple(&xdev, "NR", 0);
}
else if(option == 98 || option == 66) { /* b || B */
  sys_app_banner();
}
else if(option == 104 || option == 72) { /* h || H */


}
else {
  puts("-------------------------------------");
  puts("|              H E L P              |");
  puts("-------------------------------------");
  puts("[1] - Print Operating PAN ID");
  puts("[2] - Init additional radio settings");
  puts("[0] - Local network reset");
  puts("");

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

tgsoverly · February 4, 2018, 1:39pm

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.

exile · February 4, 2018, 3:43pm

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

github.com

exsilium/pxbee-trigger/blob/2573c08c45ed26d318066fa75e1fb5bb1953326e/src/main.c#L304


    printf("Toggle command received\n");
    break;


  default:
    printf("Unknown command received\n");
    break;
}


delay_ticks(HZ); // wait for 1 second prior to reporting Off state


response.header.command = ZCL_CMD_REPORT_ATTRIB;
response.header.sequence++;
response.header.u.std.frame_control = ZCL_FRAME_TYPE_PROFILE | ZCL_FRAME_SERVER_TO_CLIENT;


start_response = (uint8_t *)&response + 2;
end_response = response.buffer;


*end_response++ = 0x00;
*end_response++ = 0x00;
*end_response++ = ZCL_TYPE_LOGICAL_BOOLEAN;
*end_response++ = 0x00; // Report Off state

tgsoverly · February 5, 2018, 8:59pm

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

exile · February 7, 2018, 10:41am

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!

mckenph · February 7, 2018, 2:20pm

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

exile · February 7, 2018, 2:38pm

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.

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

Customers

Developers

Download the SmartThings App