I want to use smart things but customise it according to my needs
Maybe you should take a step back and clearly write down what your wanting to do. To me you seem to be all over the place with your questions. I’m sure its just because I haven’t seen your big picture. You may be trying to do things that simply wont work. For example you can’t have two active coordinators on the same ZigBee network.
To start from basics, I want to make deRfmega 256 as the coordinator and communicate through it with other end devices and use python to send or recieve messages, from coordinator to end devices for this at the moment i have a RaspBee (deRfmega 256) as coordinator and the end devices in the network are Series 2 xbee modules. Now please help to get the messages sent and delivered from the coordinator.
I just want to understand can i send remote at commands using RaspBee to a series2 xbee module. If so how can i do that
This is the image of network created using the above configuration as seen from xctu terminal now what do i do to send messages/ commands from coordinator to the stick. In the image RaspBee attached to raspberry pi is the coordinator and xbee stick is attached to the com port of the laptop.
I don’t think you can do it. If you can its going to be difficult at best and you will probably need a sniffer to see how two xBees do it. On page 149 of the xBee manual it tells you how to format a packet that will do exactly what your asking for. But, the problem your going to run into is Digi’s remote AT commands are intended for use between two xBees. When xBees send remote AT commands to each other that communications is proprietary to Digi. In your case your Coordinator doesn’t appear to be an xBee (I can tell by its IEEE address) so it is not going to have the API commands allowing you to send Digi’s proprietary remote AT commands.
I’m guessing your wanting to send a remote AT command to either control one of the xBee’s pins or read it? If you had an all xBee network you could do this with the remote AT command but since you have mixed vendors in the loop you are going to need your radios to talk over a common standard. That is what ZigBee clusters are all about!
Here is an article of mine in Nuts and Volts that talks about how to send ZigBee standard cluster commands from SmartThings to a microcontroller connected to an xBee. The article has a kit for a xBee and sample code for a Parallax Propeller microcontroller if you want to follow along.
John,
I tried this as you described and purchased the xStick2. Downloaded the XML Config file and attempted to update the firmware and configurations. End result, the xStick2 firmware became corrupt and now I have to send it in to have it reset. Here is what support was saying…
The article you are referring to is not supported or written by Digi. It is also referring to using a USB dongle and XBee module that support changing the firmware via the COM port instead of the XStick which needs to have it done over the air.
I’m just trying to understand, is your article performing an update to the firmware via COM port? I appreciate any suggestions that you may have.
J
Yep via the com port, works fine. When you plug in the xStick to your USB port it uses a Com port for communications. The COM port is how the XCTU program will discover and communicate with your xStick.
Before you send it back have you tried the xBee recover tool under the utilities menu in the XCTU program?
Did you pick the ZigBee Router API Firmware version 23A7? If you did and it still bricked it I wonder if Digi is shipping newer radio hardware and that firmware version is outdated??
When you get it back and if you still want to give it another try ping me and I will be happy to help.
PS I updated the top article to caution that this kind of thing can happen. Sorry you are having problems with my steps if you do get it working and one of my steps needs to be changed please let me know I will go back and update them. I do know several people have got this to work but hardware changes and I may need to update something.
I will attempt to recover the xStick using XCTU program tonight. Since this is new hardware, I may follow Digi’s recommendation and purchase additional hardware so I can update the xStick OTA. I’ll keep you posted. Thank you!
Humm well if it is bricked (non responsive) I don’t know how they think you will be able talk to it wirelessly? Keep us posted on your success!!
For starters, i got the xstick to join my zigbee network and did a complete discovery (multiple time for kicks and giggles). I simply used the configuration file to initiate the firmware change on the xstick; skipping the step of manually setting the firmware as indicated in your instructions. XCTU prompted if I wanted to update the firmware to meet the configuration file. The results, in the screenshot, I did confirm the installation of two zig bee switches did bridge the gap nicely between the front of the house (AD82) and the back of the house (8AE0); between these two switches is a clear line-of-sight. Lastly, the items in a column on the left are all devices that communicate 1-way only; LIGHTIFY and/or WEMO! Although these are AC powered devices and configured as a Router, they do not truly relay commands. Overall, the xstick has helped me to fine tune my understanding of how all of my zigbee devices are interacting. THANK YOU!
Awesome! Keep in mind that a router with week signal straighten will not be picked to route traffic if there is another router with better signal strength close by. That is normal they are basically on standby if something goes wrong.
Glad its working for you!!
FYI, I just got an xStick and was able to use your instructions (and config file) to update the firmware and get it to connect. Got a bit of a scare when the F/W update failed the first time, but was able to get it installed through the recover tool. After that everything worked just fine. Thanks!
A quick question while I’m here. I’ve paired this with my ST hub so that I can take a look at that mesh. I also have a pretty extensive set of bulbs on my Hue hub. Is it possible to reset the xStick and pair it with that hub, too? If so, do you know how to do that?
Yes I’m guessing it is possible but I haven’t done. Hues use the ZigBee Light Link profile and the key to join that network is unique per manufacture. There isn’t a publicly key like the Home Automation profile.
Glad its working for you!!
Forgive the naive question, but the maps here show multiple paths between devices (hubs and repeaters). Whereas this blog post suggests that a ‘thing’ will only talk to a single parent, and that throwing a repeater into an existing network won’t make devices start to use it.
Am I right in thinking there’s a conflict between these two bits of information?
Paul, battery powered devices (child devices) have a single parent that is a router or hub/router. Their parents (the routers) do the routing for them and the traffic may have multiple paths to travel. That is why you see multiple routes between routers. You wont see a child device connected to multiple routers, they only have one parent. However, a child device can re-home its-self to another router if that router is down and another one is available.
So if your “thing” is a battery powered device its traffic will be handled by a router that can take advantage of multiple routes. It is a little confusing because a “thing” in the SmartThings cloud can be a child device or a router.
Thanks @JohnR. I must be going blind because I could swear I’d seen a map with a battery device routed through multiple paths back to the hub, but of course you’re right.
Anyone know the timings of a child device deciding to pick a new parent? Does it happen fairly instantly on the first fail?
And can the reverse happen? If a child is moved from the range of one parent to another, can the new parent initiate the relationship, or do you have to wait for the child to ‘call home’ and find the original parent missing?
I know in most cases ‘things’ don’t move, but Presence Sensors do, and I’m trying to understand some strange behaviour here. (Well, other than the fact that presence sensors are a bit rubbish - I have one where the battery level is 1% one minute, then 45% the next!).
In addition to @JohnR 's excellent explanation, if you are adding a new zigbee repeater and you really want to get a specific battery powered device to use it as its parent, after adding the repeater you can then remove the battery-powered device, factory reset it, and re-add it to your network. Now it will look for its best parent from all the candidates (including the new repeater) and likely choose the one with the best signal strength. But that’s a lot more work and isn’t usually necessary.
If only there was an easy way to do that in ST, without first removing the device from all of your smart apps, then adding it back in again afterwards.
What we need is a RE-connect option for existing devices.
P.
@JDRoberts I will let you respond to this. -smile-
Oh, thanks! 
I suspect what John is alluding to here is that different devices have different behaviors in this circumstance. But since each zigbee device has its own permanent ID, it’s usually quite possible to simply reset the device and then re-add it without telling the network that you reset it. That way you don’t have to change any of your smartapps ( which use the network ID to identify the device). In most cases for a battery powered zigbee device this will cause it to choose a new parent if the selection of repeaters is different then the first time it joined.
(Note that this does NOT work for zwave devices, because their network ID is assigned by the hub when they join. For Z wave, you would use the “replace” utility in a similar situation. But you don’t need that utility for zigbee because the device’s ID is always the same anyway. )
People do this a lot for GE Link bulbs since those have a firmware flaw which can cause them to lose contact. The point here is simply that it’s very easy to reset them and add them a second time without making any smart app changes and everything will work just fine.
John can add more details if I’ve left something out for a SmartThings network.