So, assuming for the moment that I take the technically simpler route of asking everyone to buy two objects, a gateway and their desired device.

What will this gateway look like? Will it be a functional device too? Or just a black box? I would much prefer it to be a device. However, this would mean either that everyone is forced to own a single type of device (say an orb or similar) in addition to the device they actually wanted, or I have to offer every device in both gateway and plain form.

Erica suggests some sort of modular system, either internal, allowing all devices to be either gateways or end devices, or external, allowing the modular element to plug into the device.

In the latter scenario, one could, for example, have a little box which has a power connector, an ethernet jack, and one or more mini USB jacks. And all standard devices have a mini-USB connector. So they can either be connected to the PC directly, or to the gateway hub, or to a simple power supply with a mini USB connector, like a cell phone works.

I see that here too I have the same type of problem: how does a device know whether it is a router or a coordinator? How do multiple devices on the USB bus, for example, decide which should be the coordinator for any radio traffic? How does the main system find directly connected devices on the USB bus?

I think this is all far too expensive and complicated. I think that I can fairly easily support both local and global systems, if I simply design around a gateway.

OK. So next, what does this gateway look like? Is it pretty? One idea I had was a white plastic cartoon cloud, like a lamp in the kid’s dept. at Ikea. And it has a single high-brightness RGB LED in it. And it has a knob, which allows the user to configure it. Or it doesn’t have a knob, and the user must configure it from the internet or wherever their control system lives.

Lamp

If it has a knob, perhaps it has the features of the RGB lamp I designed some time ago: the knob is the sole input device to the system. The system can be used as either a simple lamp, or as a network feedback device. In lamp mode, the knob is used to set the rate at which colors cycle through the display. This allows the user to speed up the rate until the desired color comes around, then turn the rate down to zero to freeze that color. The knob might have a detent switch too, which allows the user to turn the lamp off. This is a nice system but it has the basic problem that it controls color, not intensity. Also, in my initial configurations I didn’t include white, which this lamp should somewhere in the spectrum.

Wall lamp

I imagine that this device could hang on the wall behind your desk, for best radio function, or could also sit on your desk. So I guess it is pretty 3D, and has a fairly small footprint. Or, it is shaped such that though flat, for good wall hanging, when on a desk it sits upright still. Some combo shape.

Prox sensitive

I could pull in my PSI lamp idea, and use the Sharp sensor(s) to create proximity control. I could use PIR. I could use simple reflective IR instead of the complex Sharp systems. I could use multiple points of IR reflection, so that the user controls the system by hand placement. Or, all this is too complicated. Maybe the system just gets configured through the network. But isn’t this against one of the basic principles of the aiosphere?

Multiple RGB points

Another idea I had was, instead of being a lamp, the cloud-shaped device has multiple (say ten) RGB LEDs. These could be controlled programmatically from the network. Such a system could be used to display a clock (by using one color for hours and one for minutes and optionally a third for five-second increments), but might also be used to display basic network information. If there were an RGB LED in the middle as well, then the system could use that LED to represent the gateway, and the others to represent wireless nodes. Colors could change to represent data passing through the system. But do people care about such a visualization? Not sure. But does it matter? It is possible that the system could simply present an array of LEDs, and the user could select a driver which makes it function as they desire.

But I think possibly this an aio, not a gateway. Maybe I will make the gateway much simpler. Maybe it has no UI features at all, save a single RGB LED which can be used to show network traffic, but can also be turned off by the user if they don’t want blinking. OK, then maybe the minimum gateway object is an orb? Or maybe the minimum object is nothing but a reasoably good-looking totemic object, like a green pyramid or something. Maybe it is just about shape, not light or interesting function.

I suppose that, instead of creating an Ethernet-Zigbee gateway device and a bunch of Zigbee devices, one could also just make WiFi devices, if the chipsets and firmware support infrastructures are developed out enough yet so the costs compare favorably. But a quick survey suggests that WiFi still isn’t there yet. Lantronix makes the WiPort, an embeddable module which is sort of easy to use, and Mouser distributes it for $120/1, $100/10. DataHunter makes a G device called the Radion, which is $80/1 Nanoradio, and similar vendors make chipsets and modules which come way down in volume, but these are hard to get, hard to find dat for, and I believe don’t provide the TCP/IP stack etc. So, from my perspective, that of a glorified hobbyist, WiFi is still far too complex and expensive.

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).