Steampunk / mechanical hit counters are a fun idea for ambient/desk gadgets. Electromechanical counters, which make a satisfying click. Ringing a bell, playing a chime, or a small robotic or electromechanical element which makes a signature movement. Lots of interesting alert possibilities out there, all dirt simple to do with the aiosphere.

Many simple output devices, LED and text, could make interesting clocks. I like the idea of a little text display which is made into a clock by the network driver. As well as the LED ideas I have talked about before.  I also like the idea, strange or not, of a generic system which is turned into a clock by software somewhere on the network.  Check out PC Mag’s collection of geeky clocks.

Application endpoints

Reading Jennic’s primer, I see that the network addressing concept is extended down into the node firmware itself.  A node in a Zigbee network can have multiple applications running on it, and each of these applications can send and receive messages as if it were a physical node. I think they can communicate with each other, and also across the network. The mechanism supports logical endpoints 1-240, zero which is a zigbee layer, and 255 which is a broadcast. They give the example of a node which measures both temp and humidity, and say that each app is its own endpoint. Might I use such a mechanism to address multiple LEDs?

Application profiles

I would need to create my own, private, profile, as I do not want my network to interact with other public profiles or devices, lighting control etc.

Device Descriptions

“in each Application Profile a number of Device Descriptions are defined, describing the types of devices the profile supports. For the HCL profile, devices such as a Switch Remote Control (a switch), Light Sensor Monochromatic, Dimmer Remote Control, Occupancy Sensor, Switching Load Controller and Dimming Load Controller are available. Each device in an Application Profile has a Device Identifier associated with it.”

So do I need to define these things? I don’t want to limit the possibilities of my system, but I do want to determine some basic types. Maybe this is good enough, and I can extend the set of basic types later.

Input and Output Data

“As well as defining the device types supported, the Application Profile also specifies the information that a device can generate as output and can use as input, together with the format this information takes. The individual pieces of information are called attributes, and their possible values and format or type (e.g. 8- or 16-bit integer, time value, etc) are defined as part of the Device Descriptions in the profile. Attributes are grouped together into clusters for the device, which can be either inputs or outputs.”

Again, this is something that I maybe should do. Need to read more about it.

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.