One of the transport layers we want to support for Verdant is XBee. @ ransomhall et al did some excellent work on GBee and there’s no real reason to reinvent that wheel. GBee is currently only supported for 4.1 and 4.2. I am planning to update it for 4.3 and Win 10 IoT UWP, but first I thought I would ask : a) has anybody else already done that work and I just failed to notice?; and b) are there any other asks while I have the hood up?
[Edited to be more concise]
Not my department. 
You’ll have to ask the hardware guy.
So far, XBee, the Molecule RFPipe (whatever that was based on), and maybe some wifi and ethernet are what’s on the plan (with heavy emphasis on the XBee and RFPipe stuff, because 4.4 will probably bring more or less full AllJoyn citizenship with it for IP-capable devices).
All of this is really just meant to be a quick way to get up and through the Device Bridge Service so that everything else can happen over AllJoyn protocols and services and get to a Gateway Agent and cloud services as fast as possible. As a result, there’s a lot of emphasis on implementing broadly and thinly until we have a demoable end-to-end story, from Orac devices, through the air, into a DBS, through AllJoyn, through a Gateway Agent, and into the cloud. Then we can back-fill with more breadth over devices.
@ mcalsyn - it’s been forked a few times, but nothing has been merged back to the main branch. I can make you a contributor on codeplex if you want. Now would probably be a good time to transition it to git/github, as I’m not sure if many folks are using mercurial anymore. I did this on codeplex for another project (mercurial -> git), so @ dukenukem could update my GPS module code to 4.3. It was a PITA - I had to make a special request to codeplex support, delete and re-add everything,loosing history, etc… hence the idea to move to github.
I can help with any questions, but @ gralin did most of the coding. we don’t see him around here much these days. I’ve got plenty of XBees to help test on 4.3 when you’re ready (assuming i don’t need to be ‘verdant-ized’ to do so )
Yeah, I’m definitely not interested in installing Mercurial - nothing against it, just don’t need it for anything else.
No verdantification required - the GBee code will stay pure to it’s original intent. Everything Verdant lives in layers above that, and in separate repos. I have forked the code into github, within the VerdantAutomation organization (GitHub - VerdantAutomation/GBee: Update and Port of the GBee support libraries for XBee/Zigbee devices) only for lack of a better org to put it under.
I plan to change as little as possible (no gratuitous changes in namespaces or anything like that) - just bring it up to date (4.3) and add Win 10 IoT support.
If you have another org or account you want it under, we can always do an org-transfer at any time. Those are pretty easy on github. Or I can just add you as an admin - whatever you prefer.
A pre-release of the 4.3-compatible GBee library for XBee modules (Gadgeteer and ‘plain’) is available at [url]https://github.com/VerdantAutomation/GBee/releases/tag/v1.1-pre1[/url]
This is a pre-release and extremely minimally tested (e.g., it built and installed)
Key changes are:
[ul]Support for .Net Micro Framework 4.3
Support for Gadgeteer in 4.3
Change from linked source files to shared-source projects
Updated build to work in VS2013 and VS2015
Updated installer to WiX 3.10
[/ul]
If you have XBee modules (and particularly with Gadgeteer adapters) any feedback would be much appreciated. I don’t have any XBee Gadgeteer adapters at the moment, but I am testing with Cerb Bee and hand-wired adapters. I will also be testing primarily on 4.3 as that’s what I mostly care about right now.
I will move this to a full release once we get some testing mileage on it.
Thanks again to @ ransomhall et al for the original code
I recently picked up a SmartThings Hub V2 (just been launched in the UK) and discovered that it supports both ZigBee and Zwave. As the Xbee S2 supports zigbee I was hoping to use a couple of my Xbees to hook up a lamp that I’m building for my wife. It doesn’t look trivial and the SmartThings hub uses the Zigbee HA profiles. Not sure if this lib will serve my purpose though.
I did find this site [url]http://www.falco.co.nz/electronic-projects/xbee-to-smartthings/[/url] which provides some useful info but looking at the source I’m unsure how to proceed. I understand that I need to get the Xbee registered with the Smartthings controller and create a device type at that end, its the NETMF side that’s evading me. I looked at the hydra sample to try and get started but not getting anywhere. Been away from all this stuff for too long 
I am hesitant to give you a definitive ‘yes’, because I haven’t tried it myself, but I think all the pieces are there. You just have a fair amount of code to write, even with the libs, before it is all going to work.
You also seem to have the right approach - use XCTU to go through the steps manually to onboard your xbee device. Then use netmf code to communicate with the network you just joined. So in theory, everything is there, but not having a SmartThingy device to test with, it’s hard for me to say anything more concrete. Generally comms stuff is fiddly to get right, and exponentially more fiddly the worse the protocol documentation is.
@ HughB - Where did you find yours? If you found a unit with UK plugs, I am interested in seeing if I can find a unit with Euro plugs.
We (as in Samsung) launched it in the UK about 4 weeks ago with a few Smartthigns addons. 3 pin UK plug power sockets, multi purpose sensor, presence sensor, motion and moisture. oAuth for IFTTT etc is very broken and the forum is filling up with moans because of this but they will fix it. There seems to be some mess up with there being servers for the USA and servers for the UK which have a different address graph.api.smarthings.com is the us side and graph-eu01-euwest1.api.smartthings.com for the UK (and EU probably)
I’ve got mine hooked up to a Philips Hue Bridge and i can control the Hue from the smart things app. Aeotec are bringing out a new Zwave 3 pin dimmer soon too. Also i discovered that the Hub V2 has a BLE module in it but that will get enabled later 
I have to say its a great bit of kit and once they have oAuth working again it will be awesome. The only home automation product that supports oAuth as far as I can tell.
From what I hear in the office once the UK roll out is smoothed out the rest of Europe will come next. I will dig around and find out more for you.
Using Xctu i can get the hub to at least spot that there is a new “thing” so I know it has the potential to work. I am determined to get a NETMF device hooked up to SmartThings with a real world working example to show off.
Can you give some more details how you got something hooked up to a hue bridge not being a hue … if I’m understanding this correctly …
I’ve got loads of (well, kind of) Zigbees laying around here and I’d like to hook them up to the hue but got nothing to work … I found nothing about but controlling just lights …
The alternative is to make my own mesh network and since the hue api is documented properly (http://www.developers.meethue.com/) I can write again the logic and combine my mesh via a UWP on PI2 but I’d rather prefer not to.
Any suggestions, links ?
TIA
The Hue uses the zigbee light link protocol which the xbee does not support. The Smartthings hub has a software bridge between the smartthings cloud and the Hue cloud. That’s how it works. However the Zigbee HA stack supports setting colour and brightness. All i really need to do is to get that data to my netmf device and set some neopixels to the specified colour.
Haven’t had any time to get on this other than getting an xbee s2 to be seen by my smartthings hub and set the device type in smartthings. haven’t got anywhere with the GBee drive yet 
not enough time.
@ HughB - Ah, that way, the smartthings is not avail in Germany, yet. :wall:
Since I’d like this to be controlled from fruit devices there is maybe another way by bridging to home kit but that’s a far fetch …
now that philips hue has closed a cap in their firmware where one could include some not certified devs …
I guess I’ll have to take the long road … :’(
@ HughB - How about going the AllJoyn route?
@ HughB, any progress lately? I mean you did promise this: “I am determined to get a NETMF device hooked up to SmartThings with a real world working example to show off” ;D
On a side note, Samsung sells a SmartThings Ardunio shield they call the ThingShield that is fully supported and documented. They also provide the driver source code as open source.
To get started connecting any GHI controller to a SmartThings hub, might it be easier to buy the ThingShield, use it with one of the *duino GHI boards and rewrite the driver code into /NETMF?
-or-
is it still theoretically easier to go the Xbee S2 route?
Adding to my last post - unfortunately it seems that the ThingShield is either no longer being sold or has been out of stock for nearly half a year. I’ve scoured every possible link on the interwebs and they are not being sold anywhere at this time.
But, the ThingShield is based on the EM357 meshconnect SOCs. So in addition to pursuing Xbee connectivity to the SmartThings hub, we may also have a path of building an EM357 based interface.