Radio addressing

Use the mesh networking capabilities of the Zigbee radio, but use some proprietary protocol so I don’t have interoperability requirements with Zigbee devices and networks.  Second key advantage: no need to buy a block of addresses from the Zigbee people.  Finally, I can create my own addressing system, and can sell blocks or individual addresses to experimenters wanting to make their own devices for the network.

Ethernet addressing

I don’t see any way around this.   I think I am simply going to have to buy a block.  I have two interesting options if I do: first, as I don’t plan to interoperate with Zigbee, and if I end up putting ethernet on every device, I can use the MAC address for the radio system.  Second, I can sell MAC addresses to other people who want to make aiosphere-compatible devices to sell.

I don’t know whether a computer can “reach” a gadget on iGoogle.

The basic Gadgets test concept is to make a gadget that gathers (weather or) data and formats it for display on an aio.  Poll this gadget (if possible) from the aio (in the test case represented by my PC).

If it isn’t possible to poll a gadget from another computer, then I could have the gadget periodically write to a text file on my own server.  This text file could be titled 465782ED49009F0B, or whatever the MAC address is of the aio.  The aio could request its own file from the server.  The file would contain only the most recent command, or could be a string of commands.

Next, how would the aio confirm receipt?  I guess by deleting the file, or deleting the contents of the file.

Now, how about if data needs to go the other way?  What if I wanted to make a gadget that passed data between two objects?  Then do files need to have input and output sections?  Or do there need to be two files?

And, is FTP harder than HTTP?

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.

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.