Identifying Devices for the Internet Of Things
Identifying Devices for the Internet Of Things
The purpose of this page is to create a set of taxonomies for connected devices - despite the flippant name, it's a serious topic.
I am aware of the following classifications, no doubt there are more:
| Classification | Description | Examples |
|---|---|---|
| Processor | The CPU for the device | ATmega328, NRF51822 |
| Board | The board name from the manufacturer | Arduino, Nordic Semiconductor development board, Guan 8051 |
| Connectivity | How this Thing communicates - include manufacturer specifics if appropriate | Wifi, 6LowPan, BLE, 315mHz, XBee (ZB) |
| Operating System | Optional, what OS is running, if any | Linux 3.2, Android, FreeRTOS |
| Appliance Type | The actual purpose of the Thing | Lamp, Beer Brewing, Power Strip |
| Appliance Details | Implementation-specifics that may be important | Voltages and warnings, Consumables needed, etc. |
Guidelines
When creating devices I try to avoid binary communication formats, to make debugging easier.
I also like to include a help function that describes the basic commands this device accepts.
Proposals
The ultimate purpose of this is to catalog Things as they are created, and be able to tell at a glance how they might work.
In addition, I have a fairly ambitious idea, to enable IPV6 connectivity for all things through a gateway specification. Users could ssh into any device, regardless of connectivity, and be able to talk to it directly, or create communication libraries that are agnostic of how it's talked to.
The magic would be accomplished through a manager daemon, which would be the 'shell' for the connection user. The daemon would poll connected devices and instantiate virtual network adapters for each. Different devices would be cataloged via the IPV6 address bits, which will be more than adequate for classification.
For example, if the classification for XBee devices was 1234, and the XBee address desired was [00:13:a2:00:40:8c:56:9c]!, the IPV6 address/80 might be 2604:2000:1085:1234:0013:a200:408c:569c. The manager would have already created this virtual interface after doing an XBee node discovery, and have opened a server socket to it.
The manager daemon would accept connections on all these virtual devices, and check the IPV6 address for the device type and device address. It would delegate the device address to the appropriate connection daemon, which would send and receive data to the device.
Finally, a username, e.g. 'iot' is set up, and its 'shell' is a client that connects to the manager daemon and sends its IP address to it, then establishes a two-way connection through the manager.
This has the benefits of
- secure communication to devices
- enabling connectivity-agnostic device connections
- ability to filter access to devices with router firewall rules
