[ale] Z-Wave or ZigBee

[Alex Carver]

On 2015-08-05 13:51, Chris Fowler wrote:
> ----- Original Message -----
> 
>> From: "Alex Carver" <agcarver+ale at acarver.net> To: ale at ale.org 
>> Sent: Wednesday, August 5, 2015 10:29:10 AM Subject: Re: [ale]
>> Z-Wave or ZigBee
> 
>> On 2015-08-05 06:06, Chris Fowler wrote:
>>> ----- Original Message -----
>>> 
>>>> From: "Alex Carver" <agcarver+ale at acarver.net> To: ale at ale.org 
>>>> Sent: Tuesday, August 4, 2015 8:08:09 PM Subject: Re: [ale]
>>>> Z-Wave or ZigBee
>>> 
>>>> Yep, same idea as the Spark Fun versions of the board.
>>>> However, remember there's a TTL UART already on the IO header
>>>> of the RasPi if you haven't used it already. You can wire that
>>>> right to an XBee.
>>> 
>>> I have plenty of Pis and BeagleBone Blacks. Okay, ZigBee is
>>> simply architecture for IoT that can do automation. I had known
>>> about IoT, but I am confusing ZigBee for only being for
>>> automation. Automation is just a sample application of IoT. I
>>> found some outlet plugs on eBay that support it.
>>> 
>>> I like the idea of the ethernet gateway. The ZB devices can
>>> simply be on their own subnet. Are there any support for this
>>> gateway architecture in Linux, or am I restricted to a device
>>> like what Digi has created?
>>> 
>>> Chris
> 
>> Yes, Zigbee is all about local networks for a variety of tasks not
>> just home automation. You could put sensors, controls, or
>> communication bridges in the Zigbee network (e.g. a very low speed
>> wireless serial link between two devices). Since it is a mesh or
>> star topology it is slow so the data frames are kept small. It's
>> great for passing around tiny packets of data (a sensor reading, a
>> switch command) and a little less for serial data but still
>> possible (e.g. reprogramming settings in a microcontroller device
>> like a thermostat)
> 
>> The gateway is pure TCP/IP so it's going to be OS agnostic. You
>> talk to the gateway over its Ethernet port and the gateway connects
>> to the Zigbee mesh on its RF port and provides you an in-road to
>> the Zigbee network. Zigbee meshes are not normal networks so
>> there's no subnet. It is based on 802.15.4 at Layer 1 (Zigbee is
>> Layer 2 and above) so it is a MAC/serial number based mesh network,
>> no IP addresses.
> 
>> If you use a dongle instead of the gateway you achieve the same
>> goal, it's an inroad to the mesh network but in both cases it
>> requires the assistance of the dongle or gateway which can act like
>> a master node (the "Coordinator"). The Coordinator collects
>> information about the state of the network (what nodes have
>> advertised their presence, first hop to any particular node, etc.)
>> It must run a specialized version of firmware to give it the
>> coordinator status. The rest of the devices use use lower
>> capability firmware (Full Function Device or Reduced Function 
>> Device) and learn what is around them and build up their own
>> routing tables. An FFD can do a packet store and forward and can
>> act as a middle node in the mesh but an RFD can only be an end
>> node. RFDs use less power than FFDs because an RFD can sleep
>> frequently. FFDs must be awake almost constantly to handle routing
>> of packets between more distant nodes.
> 
> What would be the best way to experiment? Maybe get two dongles and
> then use two Raspberry Pis to communicate? Or, one dongle and an some
> Arduino goodies and write code for it to communicate?

Just get a a dongle and some devices.  You don't have to do two Pis, you
could do a Pi and a destkop dongle, toss in a couple more modules (like
a plug-in electrical outlet or similar) so you have an actual mesh
network (you really need to experiment with more than two to understand
how identification, searching and addressing works in a large network)
and then just play.  You can later toss in a gateway device to add to
the experience.

> My next goal would be to control just one outlet. I guess I need to
> be careful about 'Pro' vs non-pro. Only stick to one type?

Yes and no.  You can buy just about any outlet that's Zigbee enabled
(and I would suggest doing that as one of the devices as I mention
above).  Pro and non-Pro work together as endpoint devices.  The
limitation is how the meshing works.  If you have a majority of one
type, the opposite type can not participate in the network as a routing
element (in the middle of the mesh).  It will only work as an end or
edge device.  For your experiments, everything will be initially within
direct range of the controller module so you don't have a routing issue
right away.  This only becomes important if you have devices spread
across your house where some devices are too far away to communicate
directly with the controller and must relay through a device somewhere
in between (hence the mesh network).  You won't notice the pro/non-pro
difference until this happens.

> 
> The outlet control would go like this:
> 
> SOAP on Pi2 -> SOAP on desktop -> USB dongle via some code (maybe I
> write this using APIs?) -> Outlet. Outlet says "I got it!" and that
> is reported back to the user interface as a return from the SOAP
> method. The Pi2 can't do the ZigBee because it will travel and move
> around. I have Pis and Pi2, and BBB so I could create a "gateway".
> Remove my desktop from the picture. Just write a SOAP interface on
> that device to interface with the ZigBee hardware. Then who knows
> where those nodes may be :) To expand X10 buttons on my interface I
> spend about 5 hours abstracting all that in JQuery/JS in the app. Now
> all I do to add a room, X10 outlet, etc is just add rows to a SQLite
> database on my Pi2. It then shows up in the web app.
> 
> As long as I can do it in Linux via either a command line program or
> an API then I can code whatever it is I need to work. If it only
> worked in Windows then forget it. I'm not going through that trouble
> (yet).

You're thinking too hard.  Zigbee is agnostic to OS, it's too low level.
 All it cares about is slinging bits around.  It talks to a computer
with two wires, TX and RX (a serial port).  If your OS can handle a
serial port it can speak Zigbee.  Keep in mind that the physical Zigbee
module uses TTL data not RS232 levels.  If you plug into anything other
than the digital I/O of a microcontroller (Arduino, Raspi IO pins, PIC,
etc.) then you need a level converter at minimum (and a full UART if you
want to use a USB connection).  Other than that you send appropriately
formatted binary messages to the Zigbee controller module and the
network (and end device of interest) does its thing.  You then get a
binary message in response to your initial message (depending on the
message).  It's up to you to encode and decode those messages.  The spec
is open and people have built libraries for doing it.  You could also
write your own library if you wanted to really understand Zigbee and,
more importantly, to understand and control your expectations on what
will happen during any communication.

A dongle/module on top of a Pi/BBB/board of your choice is a fine way to
make an intelligent gateway (and reasonably low power, too).  The Digi
gateway has some intelligence in it but it still behaves like a bridge
so you put the higher level functions elsewhere.