This page last changed on Oct 19, 2009 by juha.
Another discussion thread I want to move out on the public forum is regarding ZigBee integration via FreakLabs OSS ZigBee stack (by Akiba).
We've shared some initial thoughts about how an integration would work and thought a simple way to start is to have a serial module interpret commands and translate them to ZigBee RF protocol.
Additional opinions and ZB feedback welcome...
I think the initial version would just be an open source module that
connects via USB and looks like a COM port to Linux. I'll implement a
command parser inside the module that will interpret simple serial commands
like "on", "off", "dim 30" (dim 30%), etc. For an initial version, something
like that should be enough to get people to try it out and then make
suggestions/recommendations for other features.
I already have some test hardware that can be used to try it out or people
can use the Atmel AVR Raven USB stick (USB stick with 802.15.4 radio) which
is about $40 at Digikey.
I guess we can discuss further on the forums with everyone else
FreakLabs Open Source Zigbee Project
> > So far the protocol integrations we have are through IP, serial via
> > RS-232 for X10 and IR via lircd daemon which does lib-usb internally.
> > This leaves it pretty open as far as I'm concerned regarding options. I
> > think eventually once on our side we understand zigbee better I could
> > put together more precise opinions. At the moment anything from
> > standalone native process we execute from Java, integration via standard
> > i/o streams or even a hard-linked C library API (I can wrap it with
> > TCP/IP daemon for runtime integration purposes) would be an ok option
> > from my point of view.
> > Open for input from your side where is the path of least resistance.
> > Quick and dirty to get things started and in the hands of community is
> > just fine with me right now (we can iterate towards higher quality
> > production solutions once we get some basic integration done).
> > – Juha
Just wanted to introduce myself. I'm Akiba and run the FreakLabs Open Source Zigbee Project and am also an active participant in the Open Hardware community. I talked with Juha and will be putting together some Zigbee Home Automation hardware and software for Open Remote. Of course everything will be open source so I'll be releasing schematics and the source code can always be found on Sourceforge (the link is on my site). I'm thinking to start off easy for the moment and am planning some simple on/off and dimmer switches/controllers that have a simple serial interface. The interface would be implemented via USB CDC (Communications Device Class) and would emulate a serial port. The hardware would have a command parser so you would just need to send a plaintext command through the serial port such as "on <address>" or "off <address>" to control a particular node.
I'll keep Juha updated on the progress, but since November is going to be really busy for me, I'm targeting having something working around December. I'm also open to suggestions, comments, criticism of Zigbee, and of course questions about the Zigbee protocol or low power wireless in general.
Hope I can put something together for OR that really kicks ass
FreakLabs Open Source Zigbee Project
Posted by freaklabs at Oct 19, 2009 17:03
Thank God, a hardware person! These software people scare me.
May I suggest that you use <address> off and <address> on instead as the uC can then ignore the rest of the packet immediately? I'll read this further later as I'm a little short for time.
Oh, I like the AVR also, they're one of my favorite uCs (and I've use a lot).
Posted by linuxha at Oct 20, 2009 16:03
Thanks for the suggestion. The command parser I'll be implementing is still flexible at this stage so your suggestion will come in handy. As for the AVR, I'm pretty much microcontroller agnostic, but I have been taking a liking to the AVR recently due to the low cost emulators for their smaller MCUs. It seems that Atmel is going out of their way to attract indie developers which always gets kudos from me. I'll be posting more details soon on the project. I've also discussed with the Tokyo Hackerspace and it looks like we're going to try and set up an Open Remote testbed inside the hackerspace house. Sounds like they might have more fun than me in playing with it.
Posted by freaklabs at Oct 20, 2009 17:48
I've also discussed with the Tokyo Hackerspace and it looks like we're going to try and set up an Open Remote testbed inside the hackerspace house. Sounds like they might have more fun than me in playing with it.
Let me know if you guys need any assistance/support with this.
Posted by juha at Oct 21, 2009 08:03
Ha ha...I'll definitely let you know if I have problems. Should go pretty smooth I hope. Its a house full of geeks.
Posted by freaklabs at Oct 21, 2009 08:35
I'm just thinking out out here, so bear with me.
Not to rain on anyone's parade (and hard work), but what about 6LoPAN? 6LoPAN is basically IPv6 over low power wireless networks. There are several stacks (contiki, arch rock) already. In fact, the ZigBee alliance has proposed extending zigbee and adding IP. Then you don't need any serial->zigbee gateway devices. The command packets are generated by the BOSS and just fired off to the proper IP end device (light dimmer) for example.
There still is complexity with device discovery (i.e. how does the BOSS know what light switches are out there?). Maybe when a new light device comes online, it sends a broadcast packet (or packets) alerting the BOSS about it's self. Then the BOSS master control panel could inform the user that a new device has arrived on the network and ask for info on location and other parameters. Kind of like how an iPhone automatically asks you to join a wireless network when it detects one.
Posted by yzf600 at Oct 21, 2009 14:55
Actually, I use Contiki in my stack and am a fan of 6LoWPAN but the problem is that its just a compression scheme for IP packets to fit into 802.15.4 frames. Hence 6LoWPAN is basically TCP/IP, which in itself is not a bad thing. The problem with using TCP/IP at this point is that there is no application layer standardized for devices. Device and service discovery are still being worked out in 6LoWAPP and there are no standardized profiles, ie: Home Automation profile. Without interoperability, it won't make much sense for home automation which requires multiple vendors to work together.
As an example, take TCP/IP for PC communications. Above TCP/IP, it still requires a standardized protocol (HTTP) so that devices (client PCs) can communicate with other devices (servers). On top of that, other protocols are required to decipher the raw data, such as HTML, CSS, etc... which were standardized by the W3C before browser compatibility could be achieved. All of these needed to exist before real communications could take place. IPSO (IP for Smart Objects) is working on device compatibility and using TCP/IP and 6LoWPAN and there are a lot of draft specs for the IETF. Once things become standardized, then device to device communications using 6LoWPAN and TCP/IP or UDP/IP will probably take off.
For Zigbee/IP, there is currently an effort underway to combine it with 6LoWAPP for smart energy applications. Most likely, it will end up with Zigbee standardizing on 6LoWPAN for all their profiles, but from my experience with the Alliance, it will take time. I have more information on my website about the efforts to combine Zigbee/IP with 6LoWAPP. Here's the link:
Posted by freaklabs at Oct 21, 2009 15:14
Good point and agreed on the need on profiles and app level protocols. Datalink and transport only get you so far. But once they are in place at least it becomes feasible to start planning, implementing and experimenting with various higher level protocols – that's where the fun starts.
Too bad we're still stuck in the proprietary rut.
Posted by juha at Oct 22, 2009 20:53