We want to provide a system that is extensible enough to include anything and everything that can be manipulated by electomechanical contraptions. While most interaction with the automated devices will be done through simple reading and writing of blocks of data, each device's descriptor will contain the information needed by the master node to identify the device and how to communicate with it. So far, we have a large and growing list of device classes that can be used not only for this project, but for future development as well, both by us and by the community:

- Lamps (colored or white with color temperature, brightness)

- Occupancy sensors (motion sensors, entry/exit sensors, anything that can detect a person or a movement)

- User input devices (switches, sliders, buttons, touch/touchless controls)

- User feedback devices (lights, buzzers, alphanumerical and graphical displays)

- HVAC control and detectors for smoke, CO2, radon, etc.

- Smart outlets

- Physical access (doors, locks, windows, intrusion detection, access control devices)

- Clock, alarm clock (can be integrated with occupancy sensors)

- Home entertainment integration (your music or video can follow you as you move through the house)

- Security camera or video conferencing device

- Plant watering and monitoring devices

- Doorbell notification

- Automatic pet feeding devices

- Kitchen appliances that can be both automated and unplugged for safety when the kitchen is not in use

- Collecting personal fitness, exercise, or other biometric data

In addition to the device classes we are defining, which can be used by anyone, we are also reserving a private use space in the protocol that will work similarly to 192.168.x.x and 10.x.x.x in the IP address space. This will allow anyone to develop their own device classes to be used in their automation system without conflicting with any future standardized devices.