The key is finding an Ethernet solution which has a dev side and a volume side. I need to get prototyping VERY quickly and easily, but I also need a path to low-cost volume production.  Here is a survey of some of the highly integrated solutions out there. Read more

Jennic now offers a reduced-complexity network stack called Jen-Net, which has about a third of the memory overhead of Zigbee. Their microcontrollers and modules have both stacks in ROM, and applications can run either. This is something I need to study carefully for the aiosphere, which Jennic looks good for anyway. Here is a cursory overview of Zigbee dev kits, which favors Jennic’s offering. Reading their support forums, though, sugests that all will not be smooth sailing if I select this platform for development. Next stop, Ember.

eSense and similar initiatives aim at integrating local, personal sensory information, such as your heart rate while you are snowboarding, and delivering it through your cell phone to your friends, a kind of ambient extension of twitter, facebook, myspace.

The key here is the idea of the cell phone as the gateway, and the realization that there must eventually be standard infrastructural mechanisms for connecting sensor networks to the global information network.

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.