One thing that Ed pointed out was that I have yet to lock down the basic restrictions of the network. In other words, Zigbee supports up to 250kbps data rate, but what does this mean? Does it mean that any device may process data this fast? Or if one is, then others can do nothing? And is this a raw data rate or real-world throughput?

Here is Jennic’s nice Zigbee primer.

One idea I have been thinking about for some time now is the notion that other protocols support high data rates. Bluetooth, for example. Zigbee, on the other hand, is designed for command and control. So multimedia apps are better served by other networks. Which means that my device ideas should work with some practical range, which would be enforced by the whole system, the hardware and software alike.

I am thinking that I should design devices such that they do any complex data processing on the client (device) side or the master (network) side, but not rely on volumes of raw data to and fro. For example, a video display is not at all appropriate. Streaming audio is not. It may be that the system could support the transmission and display of images, or the playing of sounds, but as downloads and save, rather than streams.

It might also be that the network doesn’t try to even support those uses. That it strictly enforces command and control uses.

Let’s look at some examples to try and suss this out.

No-brainers acceptable uses:

• Push puppet whose attitude is determined by a value periodically sent to it.
• Display screen, fixed or scrolling, whose text content is periodically updated.
• LED whose color and/or intensity is periodically updated.

More problematic, possibly not acceptable:

• LED animation in real time (as opposed to stored and replayed scripts).
• Continuous text display updates.
• Streaming audio or video.

So how can I define the data bandwidth of the aiosphere? I could say one transmission per minute per device maximum. This would be a good starting point. But then, how much data can be in one transmission? Zigbee has a 200 byte packet limit I think. So if I said one packet per minute, then the systems are limited to whatever behavior they could wring out of 200 bytes per minute. Which precludes basically all except the most rudimentary scripting.

I could try something else, such as four packets per minute per device. This would mean that, assuming 250kbps is a real max network throughput, and realizing that all messaging in my system must go through the coordinator/gateway node, so the whole network is limited to that data rate.

So ten devices operating more or less continuously would each see an average max of 25kbps. This is about 2.5k bytes per sec. Packet overhead and negotiation must reduce this a lot. 2k bytes? Let’s try 1k bytes per sec. This is four packets 200byte packets per sec, which is plenty of data for most things I could see doing. Could even support audio, if there were not too many other devices on the net taking bandwidth.

Assuming I have a flexible bandwidth arrangement, so that a user could have one high-bandwidth device, or many low-bandwidth devices.  Would it be better to not restrict, but just let the network decide? This might, though, give erratic functioning on devices in different configs.  So be it.

So I can either have this device be a separate device, or I can build this capability into all devices, which would raise the cost of each considerably. I am trying to figure out the correct balance between maximum flexibility and ease of use for everyone, and hardware cost and simplicity.

On a most basic level, the gateway is different than the other devices. So it would make all the other devices vastly more complicated if they had to also perform gateway functions. And it would make the system itself much more complex, as each element of the system would need to dynamically figure out what its role is. For ex, with Zigbee, a device is a coordinator or a router or an end device. In my basic concept, all devices are routers. But if I build gateway functionality into all devices, then…

Scenarios

1. Single Ethernet device: when a device is the only device, it is connected to the network (local or global) through a router, and uses Ethernet only. Radio is unused? No, device probably thinks it is a Zigbee gateway and Zigbee coordinator, and passes data into the local radio space.
2. Two (or more) devices, one connected to Ethernet and one (or more) out in the aiosphere: I believe this is simple and straightforward, and the device which is connected via Ethernet assumes correctly that it is the sole bridge, gateway and coordinator. And the devices which receives connection via radio knows it is a router/end device.
3. Two devices, both connected via Ethernet: this is tricky, in that it asks the devices, or the controlling system, or the user, to tell them what is going on. As they would both default to Zigbee coordinator roles, there would be problems. Unless the Zigbee system I choose has some automatic negotiation for such a system. Somehow one of the devices must be both a gateway and a coordinator, and the other must be an end device (then does it get its data through Ethernet, or radio? Who decides, and how?)

Solution A

1. Make a fixed gateway device,
2. Require that only one of these devices be present in a system,
3. Make all other devices radio only.

Solution B

1. Make all devices have both Ethernet and radio links
2. Make all devices capable of gateway, coordinator and router/end device functions.
3. Come up with some arbitration scheme where all scenarios can easily be resolved into a single functioning network with one gateway, one coordinator, and the rest of the devices router/end devices.

Advantages of solution B

• User simply buys devices and plugs them in, not worrying about anything, and they just work.
• All devices are functional, there are no ugly black boxes that don’t provide aiosphere end device functionality.
• There are no network setup steps, no multiple types of devices, no rules abut what goes where for the user to follow.

Disadvantages of solution B

• All devices have gateway, coordinator and router functionality.
• All devices have both radio and Ethernet hardware.
• All devices have Ethernet and power jacks.
• All devices are much more complex and much more expensive.
• Small end-device devices, such as battery operated devices, don’t follow this model. So even with this model, the user still eventually needs to deal with the concept of different types of devices?

I think there are just a few simple classes of inputs and outputs.

Inputs to an aio from the network

• Ascii text packets. They have commands in them, and/or they have textual data.
• Commands: commands for simple immediate changes in output. Light, sound, movement
• Scripting commands: series of commands and a time base, or commands which represent fixed complex behaviors.
• Text: for output on some sort of text display mechanism.

Inputs to an aio from the environment

• Light
• Button press
• Sound
• Movement (potentiometer, etc).
• The result is usually communication to the network, but could also be only local responses.

Output from an aio to the environment

• Text: on a display of some kind.
• A binary action: motor, light, buzzer etc. on or off.
• A ratiometric action: change a value to effect some change in the system, color or position or size or sound level etc.
• A sequence of events over time: playing a tune, other sequential events (scripted or canned).

Is a gateway just a gateway, or can it be used as a standalone a device? If the latter, are all devices Ethernet-enabled? This would be a waste of hardware, right? If not, are the devices with Ethernet also devices on their own, allowing someone to have just one device? Would they ever have just one device?

And if they did, would this be better than a USB device? It would work even with the computer down, right?

I can see that I should do some fundamental architecture decisionmaking. I need to rank all the desired features, and see what is the best solution both short and long term.

Desired features, advantages and disadvantages

1. plug and play, no drivers: Ethernet, or USB as flash drive
2. USB: no power conn needed
3. Ethernet: no USB; power conn needed
4. radio: all devices have
5. local computer control (no internet needed): USB or Ethernet
6. Ethernet-internet control (no local computer needed): Ethernet

Proposed architecture

1. Ethernet
2. Simple power conn (switching supply for efficiency)
3. Radio

Could all devices have both ethernet and radio? This would mean, from a both Zigbee and an aiosphere network perspective, that they should be able to be both net master/gateway.

I know from looking at some of the common Zigbee modules that this is not as easy as simply having fixed roles. So, for my first system draft, I think I will take the easy route and have some devices, which cost more, which are gateways, and others which are simple radio devices.

Next decision: do I make the gateway be a device, itself? On the one hand, this is attractive, as in my system there are no ugly appliances, only interesting and useful objects. On the other, it would mean that I would either need to force all users to have one particular type of device as their gateway device, or offer a range of devices with gateway capability.

To have a single gateway, which does nothing else, would tend to help avoid a situation where a user would plug more than one gateway in (because they both have desired features). Which would avoid my having to have some complex negotiation between two gateways, to decide which would act as a gateway and which would act as a simple device, ignoring its gateway capability.